Skip to content

Latest commit

 

History

History
27 lines (22 loc) · 1.99 KB

CONTRIBUTING.md

File metadata and controls

27 lines (22 loc) · 1.99 KB

Contributing

Any contribution to this repository is welcome, provided that it aligns with the goals/direction of the project.

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note that we have a code of conduct, which is expected to be followed in all interactions with the project: CODE_OF_CONDUCT.md

Pull Request Process

  1. Fork the repo.
  2. Make your change to the code across as many commits as you would like. Squash merges are used to combine commits on a branch into a single commit when merged to master, so there is no need to rewrite history and force push your working branch. It can make PRs easier for reviewers to read if changes are split into separate smaller commits.
  3. Ensure that your change has full coverage, to a reasonable extent. A common example which may not be reasonable to have full coverage, includes errors returned by the standard library, which are handled in a simple enough manner that the expected behaviour of the code is certain.
  4. Ensure that your change is well documented, e.g. any new flags are added to the table of supported flags in README.md and any code that is not self-explanatory has comments and even unit tests that make the expected behaviour clear.
  5. Add your name and GitHub link to AUTHORS.md if you would like.
  6. Open a pull request from your fork to master, and ensure that all GitHub Actions are passing.
  7. Notify a contributor or the owners of this repository about your change so that a review can take place.
  8. Your PR will be merged once it has been signed-off of by at least one other developer.
  9. A new release can be tagged and pushed to master by authorized contributors or the owners of the repository. A changelog is automatically generated by Goreleaser and attached to the release in GitHub. The versioning scheme we use is SemVer.