- Make sure there's an issue for the feature, bugfix, or other improvement you want to make.
- Make sure it's something that the project maintainers want. We can discuss it and assign the issue to you.
- Make sure work isn't already being done on the issue.
Some contribution guidelines can vary project-to-project, so make sure to also read the DEVELOPING.md
file in the project repository if it exists.
Commit messages should be descriptive and mention issues that they fix ("fixes #123") or contain progress on ("progress on #123"). Make commits as needed, but try to keep it reasonable. If there are too many, your contribution may be squashed when merged. You may want to squash your commits locally yourself:
git reset --soft [commit before your changes]
git commit
Make sure to document your code as you go using comments, and external documentation as needed (markdown files in /dev-notes/
).
This is especially important if you introduce a new development process, internal API, or other major internal change.
If your code doesn't work, it's not ready for merging. Make sure you not only test intended behaviour, but also edge cases and error cases.
If you're making a user-facing change, put a quick summary in CHANGELOG.md
under the [Unreleased]
heading.
Follow the Keep a Changelog format.
- When you have finished working on your contribution, create a pull request from your fork's branch into the master branch of the project. Creation of draft pull requests is also allowed, but your contribution must be ready before changing the status of the PR to ready.
- Read through and complete the pull request template. If the checklist is not complete, your contribution will not be merged.
- Your pull request will get reviewed by at least one maintainer.
- If approved, another maintainer may merge the pull request if everything looks good.