This contributing guide is specfic to the tarkov-dev repo but many of its practices are shared with other repos in the-hideout
- Do not open up a GitHub issue if the bug is a security vulnerability, and instead to refer to our security policy
- Ensure the bug was not already reported by searching on GitHub under Issues
- If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring (if possible)
If you have a fix for a bug or a feature request, follow the flow below to purpose your change
If you are new to creating pull requests from a repository fork, check out this guide
If you don't want to read the detailed section below (you should), here is a TL;DR for our PR process:
- Open a PR with changes
- A team member will run CI, review, and deploy (first to dev, then prod)
- If all looks good, we merge the PR
- Fork the tarkov-dev repo
- Clone your forked repo
- Make your changes and ensure they work locally
- Push your changes to your forked repo
- Open a pull request on GitHub with the
tarkov-dev
repo and themain
branch as the target - Ensure your pull request has a meaningful title, description, and links to any related issues
Hooray! You have opened a PR with your changes. Now a member from the-hideout/reviewers will step in and follow the process below:
- A the-hideout/reviewers member will review your PR
- They will run the GitHub Actions CI suite on your PR
- If CI is passing, they will comment
.deploy to development
to ship your changes to our development environment - At this point, the reviewer will review the changes live in development. You should also test your changes as well in this environment to ensure they are working as expected
- If all looks good, the reviewer will run
.deploy
to ship your changes to our production environment - If nothing goes wrong, the reviewer will merge the PR
- 🎉