chore: CONTRIBUTING.md now tell to use branches for members, not the forks

LeonidElkin · LeonidElkin · commit 50ba5fef4d73 · 2025-11-14T19:08:23.000+03:00
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -2,7 +2,8 @@
 
 Thank you very much if you have decided to contribute to our project.
 We follow very simple and clear open-source research community accepted guidelines for contributing.
-The guideline instructions divided into sections depending on the part of the project you want to contribute.
+The guideline instructions divided into sections depending on the part of the project you want to
+contribute.
 
 ## Rules for adding commits
 
@@ -18,41 +19,49 @@ The `<type>` field must take one of these values:
 * `fix` to fix a bug in the project
 * `refactor` for code refactoring, such as renaming a variable
 * `test` to add tests, refactor them
-* `struct` for changes related to a change in the structure of the project (BUT NOT CODE), for example, changing
-  folder locations
+* `struct` for changes related to a change in the structure of the project (BUT NOT CODE), for
+  example, changing folder locations
 * `ci` for various ci/cd tasks
 * `docs` for changes in documentation
 * `chore` for changes outside the code, for example, gitignore and reamde updates
 
-The `<body>` field contains the gist of the changes in the present imperative in English without the dot in at the end,
+The `<body>` field contains the gist of the changes in the present imperative in English without the
+dot in at the end,
 the first word is a verb with a small letter.
 
 Examples:
 
 * Good: "feat: add module for future scrubber implementations"
 * Bad: "Added module for future scrubber implementations."
 
-## Source code developers guide
+## Source code developers guide (members of PySATL)
 
-1. Fork this repository using your GitHub account.
-2. Install `git` and clone your forked copy of the `repo`.
-3. Build project following build instructions in [README.md](./README.md) file, make sure everything is ok.
-4. Run tests following instructions in [README.md](./README.md) file, make sure all tests passing.
+1. Install `git` and clone this repo.
+2. Build project following build instructions in [README.md](./README.md) file, make sure everything
+   is ok.
+3. Run tests following instructions in [README.md](./README.md) file, make sure all checks passing.
+4. Create new branch from main using branch naming rules.
 5. Implement new feature or fix existing one in the source code.
-6. Commit your changes.
-7. Open a pull-request.
-8. Wait for review from developers of the project.
-9. Fix major and minor issues if presented.
-10. Get your work merged into `main`!
+6. Run pre-commit and tests.
+7. Commit your changes.
+8. Open a pull-request.
+9. Wait for review from developers of the project.
+10. Fix major and minor issues if presented.
+11. Get your work merged into `main`!
 
 ## Rules for collaborators
 
-### Basic Tips
+Use the instructions for PySATL members, but use forks instead of branches. You probably won't have
+access to create branches in the original repository.
+
+## Basic Tips
 
 1. Don't use merge, only rebase (to keep a linear commit history)
 2. Do not change other people's branches unless absolutely necessary
 3. Recheck your commit history before creating a pull request
-4. **Check you're on the right branch**, never commit directly in main
+4. Do not use small "fix" commit if you messed up in previous ones. Use `git commit --fixup` and
+   `git rebase -i --autosquash` or `git commit --amend` if bad commit is the last one. "fix" commits
+   stand for bugs that has been already in master.
 
 ### Rules for pull requests
 
@@ -62,8 +71,9 @@ Each pull request must be reviewed by one of the maintainers
 
 * Mikhal Mikhailov ([desiment](https://github.com/desiment))
 * Vladimir Kutuev ([vkutuev](https://github.com/vkutuev))
+* Leonid Elkin ([LeonidElkin](https://github.com/LeonidElkin))
 
 If you click on the green button, then **make sure** that it says `REBASE AND MERGE`!
 
-The review takes place in the form of comments to pull requests, discussions in the team chat and personal
-communication.
+The review takes place in the form of comments to pull requests, discussions in the team chat and
+personal communication. Be polite and don't flood the discussions.
