From f40e86ef0b139ddca6821e485b26c3d8577599e4 Mon Sep 17 00:00:00 2001
From: SHtress <stas.butrin1331@gmail.com>
Date: Sun, 28 Jan 2024 13:42:21 +0300
Subject: [PATCH 1/2] [docs] Add CONTRIBUTING.md

---
 CONTRIBUTING.md | 123 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..1c496a2
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,123 @@
+This page describes rules to contribute changes and features by Pull Requests creating.
+
+## Initialize
+
+To initialize your repo do:
+
+* Make fork from `https://github.com/ostis-ai/scp-machine`.
+* Clone your fork to your machine and prepare (see [Readme](https://github.com/ostis-ai/scp-machine)).
+
+```sh
+git clone git@github.com:yourlogin/scp-machine.git
+cd scp-machine
+git remote add upstream git@github.com:ostis-ai/scp-machine.git
+```
+
+* To update your `main` from `upstream` use:
+
+```sh
+git fetch upstream
+git checkout upstream/main
+```
+
+* Use `git rebase` instead of `merge`. [More documentation about this command](https://git-scm.com/docs/git-rebase)
+just try to apply your commits (from current branch to commits in specified branch). To rebase your branch to main use:
+
+```sh
+git checkout <yourbranch>
+git rebase upstream/main
+```
+
+* If you have any problems, then redo:
+
+```sh
+git rebase --abort
+```
+
+* Or ask in [Element](https://app.element.io/index.html#/room/#ostis_tech_support:matrix.org).
+
+## Commits message format
+
+Each commit message should be formed as: `[tag1]...[tagN] Message text (#issue)`.
+
+Message text should start from an upper case letter. If commit doesn't fix or implement any #issue, then it shouldn't 
+be pointed in commit message.
+
+Examples:
+<pre>
+[cpp] Colored log output
+[cpp][test] Add unit test for ScEvent class
+</pre>
+
+Possible tags:
+
+  * `[scp]` - changes in tests;
+  * `[kb]` - changes in tests;
+  * `[tests]` or `[test]` - changes in tests;
+  * `[config]` - commits with changes in configuration;
+  * `[review]` - commits with review fixes;
+  * `[refactor]` - commits with some code refactoring;
+  * `[changelog]` - use when you update changelog;
+  * `[docs]` or `[doc]` - use when you update documentation;
+  * `[scripts]` - updates in the `sc-machine/scripts` files
+  * `[ci]` - changes in `ci` configuration or scripts;
+  * `[git]` - changes in `git` configuration;
+
+Each commit in Pull Request should be an atomic. Another word implement or fix one feature. For example:
+<pre>
+Last commit
+...
+[cpp] Colored log output
+[cpp] Add class to work with console
+...
+Init commit
+</pre>
+
+In this example we add class to work with console (where implemented colored output), then in another commit we had 
+implementation of colored log output.
+
+***
+Each commit should have not much differences excluding cases, with:
+
+  * CodeStyle changes; 
+  * Renames; 
+  * Code formatting.
+
+**Do atomic commits for each changes.** For example if you rename some members in `ClassX` and `ClassY`, then do two commits:
+<pre>
+[refactor] Rename members in ClassX according to codestyle
+[refactor] Rename members in ClassY according to codestyle
+</pre>
+
+**Do not mix codestyle changes and any logical fixes in one commit.**
+
+All commit, that not applies to this rules, should be split by this rules. Another way they will be rejected with Pull request.
+
+***
+## Pull request
+
+Each pull request with many changes, that not possible to review (excluding codestyle, rename changes), will be rejected.
+
+_**All commit, that not applies to these rules, should be split by these rules. Another way they will be rejected with Pull request.**_
+
+### Pull Request Preparation
+
+ - Read rules to create PR in documentation;
+ - Update changelog;
+ - Update documentation;
+ - Cover new functionality by tests;
+ - Your code should be written according to a codestyle like in sc-machine.
+
+### Pull Request creation
+
+ - Create PR on GitHub;
+ - Check that CI checks were passed successfully;
+
+### Pull Request Review
+
+ - Reviewer should test code from PR if CI don't do it;
+ - Reviewer submit review as set of conversations;
+ - Author make review fixes at `Review fixes` commits;
+ - Author re-request review;
+ - Reviewer resolve conversations if they were fixed and approve PR.
+

From 9e2110b1723613ed0700dcff0c145c297560959b Mon Sep 17 00:00:00 2001
From: Daniil Shunkevich <shunkevichdv@gmail.com>
Date: Tue, 12 Mar 2024 21:17:33 +0300
Subject: [PATCH 2/2] Update CONTRIBUTING.md

Co-authored-by: Nikita Zotov <nikita.zotov.belarus@gmail.com>
---
 CONTRIBUTING.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 1c496a2..2c4589b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -59,7 +59,7 @@ Possible tags:
   * `[refactor]` - commits with some code refactoring;
   * `[changelog]` - use when you update changelog;
   * `[docs]` or `[doc]` - use when you update documentation;
-  * `[scripts]` - updates in the `sc-machine/scripts` files
+  * `[scripts]` - updates in the `scp-machine/scripts` files
   * `[ci]` - changes in `ci` configuration or scripts;
   * `[git]` - changes in `git` configuration;