Please read this document in its entirety.
- Be nice and respectful of maintainers and contributors time and viewpoints
- Be as descriptive as possible! More info is always better than not enough
- Be patient, there may be a lot of in-flight work even across projects
- Have fun!
Contributing comes in many forms! We're incredibly grateful to anyone who can do any of the following:
- Add new features
- Fix bugs
- Fix typos
- Improve docs
- Triage issues
- Review pull requests
- Share opinions and viewpoints on issues
- Before opening a new issue, check for existing issues that are related including closed ones
- Provide as much information as possible about the issue, how to reproduce the problem, and the expected behavior
- Don't needlessly bump issues
- Pull Requests should be accompanied first by an issue describing the reason a PR may be needed
- Don't make unrelated changes in your Pull Requests
- Pull Requests should be as small as possible
- Don't open a Pull Request if you don't plan to see it through, PRs submitted by individuals that cannot complete additional work to get a PR merged may have it closed
- Adhere to the existing code style of the repo, even if it differs from your personal preference
- When applicable, add tests that provide ample coverage of the logic added or changed
- Pull Requests should come from branches and never the default
mainormasterbranch - When applicable, pull requests must pass CI including linting and testing
- Pull Requests must go through code review before they can be merged to the main branch
- Do not include "version bump" changes in the same PR as your code changes, these will be handled as a separate PR and releasing process
- Be as descriptive as possible in your PR description as to why these changes are being made and what the changes contain
- Make sure the
Allow edits from maintainerscheckbox is checked. That way we can make certain minor changes myself, allowing your pull request to be merged sooner.