As an open source project, pyCA welcomes contributions of many forms. Examples of contributions include:
- Code patches
- Documentation improvements
- Bug reports and patch reviews
If you need more information about how to create a fork or a pull request, check out this first contributions guide or simply ask questions.
For every rule, there is an exception. If you find that there is a good reason one of the following rules does not apply to you, please bring it up and explain why. We like to be pragmatic if necessary instead of blindly follow rules.
If you provide a patch, please also provide an explanation of the reasoning behind this patch. It is much easier to understand and review code if you know its intention upfront. If a pull request relates to an existing issue, please also link that issue.
If you want to make us happy, please also provide this reasoning as part of your git commit messages.
PyCA comes with a set of tests which are run automatically on our CI system. Passing these tests is a requirement for all contributions.
If the CI tests on your pull request fail and you are sure it is not caused by your patch, please complain. Errors happen and we can easily trigger a new build. Your patch cannot be merged without these tests passing.
If necessary, say for instance you modify the API, please also provide the documentation for your change as part of your pull request. Once a pull request is merged, the documentation should match that code.
A reviewer will be assigned to your pull request to ensure that there are no issues. Once everything is fine, the reviewer will merge the pull request. Please communicate with the reviewer to address any issues.
Please remember that reviewers are only human as well.
We prefer to rebase and merge pull requests if the contribution has a sane commit history or to squash and merge your pull request commits if they have not. This is meant to keep the overall commit history as clean as possible. If you prefer a specific merge mode for any reason, please indicate that on the pull request.
- Pull request closes an accompanying issue if one exists
- Pull request has a proper title and description
- Appropriate documentation is included
- Code passes automatic tests
- The pull request has a clean commit history
- Commits have a proper commit message (title and body)
This project was started and is watched over by Lars Kiesow. Decisions are usually made as part of the community discussion and contributions are highly appreciated. But in case of conflicts, the project lead may make the final decision.