| 12 | 12 | 2. Fork this repository under your account. |
| 13 | 13 | 3. Clone the fork onto your machine. |
| 14 | 14 | 4. Open the cloned repository in the code editor. |
| 15 | | -5. Create a git branch (recommended). |
| 15 | +5. Create a git branch (recommended), review the [git book](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) if you haven't. |
| 16 | 16 | 6. Make your changes and test them locally. |
| 17 | 17 | 7. Commit the changes and push the branch to the remote repo. |
| 18 | 18 | 8. Go to GitHub, and open a pull request, targeting the appropriate upstream branch. |
| 19 | 19 | |
| 20 | 20 | ## Contribution guidelines |
| 21 | 21 | |
| 22 | | -1. Our standards are pretty low, but make sure the code is not too ugly: |
| 22 | +### Maintain code quality |
| 23 | + |
| 24 | +Our standards are pretty low, but make sure the code is not too ugly: |
| 25 | + |
| 23 | 26 | - Run VS Code's autoformat when you're done. |
| 24 | 27 | - Check with ESLint by running `npm run lint`, then fix the errors. |
| 25 | 28 | - Use common sense and follow existing naming conventions. |
| 26 | | -2. Create pull requests for the staging branch, 99% of contributions should go there. That way people could test your code before the next stable release. |
| 29 | + |
| 27 | | -3. You can still send a pull request for release in the following scenarios: |
| 30 | +### Use the correct target branch |
| 31 | + |
| 32 | +Create pull requests for the `staging` branch, 99% of contributions should go there. That way people could test your code before the next stable release. |
| 33 | + |
| 34 | +You can still send a pull request for `release` in the following scenarios: |
| 35 | + |
| 28 | 36 | - Updating README. |
| 29 | 37 | - Updating GitHub Actions. |
| 30 | 38 | - Hotfixing a critical bug. |
| 31 | | -4. Project maintainers will test and can change your code before merging. To keep our workflow smooth, please ensure the following: |
| 39 | + |
| 40 | +Project maintainers will test and can change your code before merging. To keep our workflow smooth, please ensure the following: |
| 41 | + |
| 32 | 42 | - The "Allow edits from maintainers" option is checked. |
| 33 | 43 | - Avoid force-pushing your branch once the PR is out of draft state. |
| 34 | | -5. To make sure that your contribution remains testable and reviewable, try not to exceed a soft limit of **200 lines of code** (both additions and deletions) per pull request. If you have more to contribute, split it into multiple pull requests. We can also consider creating a separate feature branch for more substantial changes, but please discuss it with the maintainers first. |
| 44 | + |
| 35 | | -6. Write at least somewhat meaningful PR descriptions and commit messages. There's no "right" way to do it, but the following may help with outlining a general structure: |
| 45 | +### Make contributions small and testable |
| 46 | + |
| 47 | +To make sure that your contribution remains testable and reviewable, try not to exceed a soft limit of **200 lines of code** (both additions and deletions) per pull request. If you have more to contribute, split it into multiple pull requests. |
| 48 | + |
| 49 | +We can also consider creating a separate feature branch for more substantial changes, but please discuss it with the maintainers first. For example: |
| 50 | + |
| 51 | +- Leave the main larger PR as a draft so it can be used to discuss the implementation. |
| 52 | +- Split each group of functions or features into a ~200 line PR so it can be properly reviewed and merged to staging or a feature branch. |
| 53 | +- If there are large codependent changes that cannot be split, start with the most utilized dependencies and stub dependent functions. |
| 54 | +- Each will be reviewed and tested one by one, merging into the feature branch as they're ready. |
| 55 | +- Do not create all branches in advance, as subsequent changes made in previous commits as a result of test/review may create a lot of merge conflicts. |
| 56 | + |
| 57 | +### Provide clear descriptions of your changes |
| 58 | + |
| 59 | +Write at least somewhat meaningful PR descriptions and commit messages. There's no "right" way to do it, but the following may help with outlining a general structure: |
| 60 | + |
| 36 | 61 | - What is the reason for a change? |
| 37 | 62 | - What did you do to achieve this? |
| 38 | 63 | - How would a reviewer test the change? |
| 39 | | -7. English is the primary language of communication in this project. Please use only English when writing commit messages, PR descriptions, comments and other text. This does not apply to contributions to localization files. |
| 64 | + |
| 40 | | -8. Mind the license. Your contributions will be licensed under the GNU Affero General Public License. If you don't know what that implies, consult your lawyer. |
| 65 | +### We (likely) don't speak your language |
| 66 | + |
| 67 | +English is the primary language of communication in this project. Please use only English when writing commit messages, PR descriptions, comments and other text. This does not apply to contributions to localization files. |
| 68 | + |
| 69 | +### Legal stuff |
| 70 | + |
| 71 | +Mind the license. Your contributions will be licensed under the GNU Affero General Public License. If you don't know what that implies, consult your lawyer. |
| 41 | 72 | |
| 42 | 73 | ## Use of AI coding assistance tools ("Vibe Coding") |
| 43 | 74 | |