| 1 | +# How to contribute to SillyTavern |
| 2 | + |
| 3 | +## Setting up the dev environment |
| 4 | + |
| 5 | +1. Required software: git and node. |
| 6 | +2. Recommended editor: Visual Studio Code. |
| 7 | +3. You can also use GitHub Codespaces which sets up everything for you. |
| 8 | + |
| 9 | +## Getting the code ready |
| 10 | + |
| 11 | +1. Register a GitHub account. |
| 12 | +2. Fork this repository under your account. |
| 13 | +3. Clone the fork onto your machine. |
| 14 | +4. Open the cloned repository in the code editor. |
| 15 | +5. Create a git branch (recommended). |
| 16 | +6. Make your changes and test them locally. |
| 17 | +7. Commit the changes and push the branch to the remote repo. |
| 18 | +8. Go to GitHub, and open a pull request, targeting the upstream branch. |
| 19 | + |
| 20 | +## Contribution guidelines |
| 21 | + |
| 22 | +1. Our standards are pretty low, but make sure the code is not too ugly: |
| 23 | + - Run VS Code's autoformat when you're done. |
| 24 | + - Check with ESLint by running `npm run lint`, then fix the errors. |
| 25 | + - 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. |
| 27 | +3. You can still send a pull request for release in the following scenarios: |
| 28 | + - Updating README. |
| 29 | + - Updating GitHub Actions. |
| 30 | + - Hotfixing a critical bug. |
| 31 | +4. Project maintainers will test and can change your code before merging. |
| 32 | +5. 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. |