The following guidelines must be followed by all contributors to this repository. Please review them carefully and do not hesitate to ask for help.
- Review and test your code before submitting a pull request.
- Be kind and professional. Avoid assumptions; oversights happen.
- Be clear and concise when documenting code; focus on value.
- Don't commit commented code to the main repo (stash locally, if needed).
See our code of conduct for more details.
- Fork the Parrot repository, open a PR to
main
, and follow the guidelines outlined in this document.
-
Keep PRs small, there should be one change per pull request.
-
All pull requests must have descriptions and a link to corresponding issue(s) if applicable.
-
Keep commit history clean. Follow commit message guidelines (see below) and squash commits as needed to keep a clean history. Remember that your git commit history should tell a story that should be easy to follow for anyone in the future.
-
Before making substantial changes or changes to core functionality and/or architecture open up an issue to propose and discuss the changes.
-
Be patient. The review process will be thorough. It must be kept in mind that changes to our repos are platform wide and thus are not taken lightly. Be prepared to defend every single line of code in your pull request. Attempting to rush changes in will not work.
We follow precise rules for git commit message formatting. These rules make it easier to review commit logs and improve contextual understanding of code changes. This also allows us to auto-generate the CHANGELOG from commit messages and automatically version Parrot during releases.
For more information on the commit message guidelines we follow see conventional commits.