| | 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. |