ansible-role-k3s/CONTRIBUTING.md

# 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.