1.9 KiB
Contribution Guidelines
Thank you for taking time to contribute to this Ansible role.
There are a number of ways that you can contribute to this project, not all of them requiring you to be able to write code. Below is a list of suggested contributions welcomed by the community:
- Submit bug reports in GitHub issues
- Comment on bug reports with futher information or suggestions
- Suggest new features
- Create Pull Requests fixing bugs or adding new features
- Update and improve documentation
- Review the role on Ansible Galaxy
- Write a blog post reviewing the role
- Sponsor me.
Issue guidelines
Issues are the best way to capture an bug in the role, or suggest new features. This is due to issues being visible to the entire community and allows for other contributors to pick up the work, so is a better communication medium than email.
A good bug issue will include as much information as possible about the environment Ansible is running in, as well as the role configuration. If there are any relevant pieces of documentation from upstream projects, this should be included.
New feature requests are also best captured in issues, these should include as much relevant information as possible and if possible include a "user story" (don't sweat if you don't know how to write one). If there are any relevant pieces of documentation from upstream projects, this should be included.
Pull request guidelines
PRs should only contain 1 issue fix at a time to limit the scope of testing required. The smaller the scope of the PR, the easier it is for it to be reviewed.
PRs should include the keyword Fixes before an issue number if the PR will
completely close the issue. This is because automation will close the issue
once the PR is merged.
PRs are preferred to be merged in as a single commit, so rebasing before pushing is recommended, however this isn't a strict rule.