47 lines
1.9 KiB
Markdown
47 lines
1.9 KiB
Markdown
|
# 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.
|