I prefer that we communicate before you start working. I value your time, and it would be a shame if you spent time working on something that should be done another way, or is not aligned with the projects goals.
That said, if you do blindly send a pull request, I will consider it. In this case it is best to keep your contribution small, like fixing spelling mistakes or improving documentation.
Contributions are welcome even if you consider yourself a beginner at open source, or even programming in general. Everyone has to start somewhere!
If you talk to me first (either via comments on the issue or by email), I will guarantee that your contribution is accepted.
- Pick an existing issue you would like to fix, or create a new issue describing the feature you would like to add.
- Fork the repo (Fork A Repo @ GitHub docs)
- Clone your fork to your local machine (Cloning A Repository @ GitHub docs)
- Make changes to your local copy in either main or a new branch off main
- Commit the changes to your local copy (e.g.
git commit -am"bam!!!11"
- check this out for more info) - Push your local changes to your fork (Pushing To A Remote @ GitHub docs)
- Create a Pull Request (Using Pull Requests @ GitHub docs)
The PR will show the changes, which we can then review and discuss.
If the review determines additional changes are necessary, you can continue to work on your local copy and then push them to your fork. The push updates the existing pull request with the changes which will then be reviewed and discussed. This step can be repeated as many times as needed.
When we agree the code is complete, I accept your PR by merging it into main, and you instantly gain a dozen fake internet points! Well done, and thank you for your contribution!
- Your Pull Request (PR) must consist of only one topic. It is better to split Pull Requests with more than one feature or bug fix in separate Pull Requests
- First fork the repository and clone your fork locally to make your changes. (The main repository is protected and does not accept direct commits.)
- You should work on a separate branch with a descriptive name.
- You must include tests when your Pull Requests alters any logic. This ensures that your feature/fix will not break in the future under changes from other contributors.
- All tests must pass. When you push, they will be executed on the CI server, and you will receive a test report by email. You can (and should!) also execute tests locally for quicker feedback.
- If changes are committed in the main branch, you should either merge the main branch (upstream) or rebase your branch onto it.
- Before working on a large change it is recommended to first open an issue to discuss it with others
- If your Pull Request is still in progress, convert it to a draft Pull Request.