|
| 1 | +# Contributing Guide |
| 2 | + |
| 3 | +We welcome and encourage community contributions to go-tuf. |
| 4 | + |
| 5 | +Please familiarize yourself with these Contribution Guidelines before contributing. |
| 6 | + |
| 7 | +There are many ways to help go-tuf besides contributing code: |
| 8 | + |
| 9 | +- Fix bugs or file issues. |
| 10 | +- Provide feedback on the CLI experience or suggest feature enhancements. |
| 11 | +- Improve documentation. |
| 12 | + |
| 13 | +Please follow the [code of conduct](CODE_OF_CONDUCT.md) when contributing to this project. |
| 14 | + |
| 15 | +## Contributing Code |
| 16 | + |
| 17 | +Unless you are fixing a known bug, we strongly recommend discussing it with the community via a GitHub issue or Slack (see [Communication](#communication) below for details) before getting started to ensure that your work is consistent with TUF's specification. |
| 18 | + |
| 19 | +All contributions are made via pull request. All patches from all contributors get reviewed. See the [Pull Request procedure](#pull-request-procedure). |
| 20 | + |
| 21 | + |
| 22 | +## Pull Request Procedure |
| 23 | + |
| 24 | +To make a pull request, you will need a GitHub account. See GitHub's documentation on [forking](https://help.github.com/articles/fork-a-repo) and [pull requests](https://help.github.com/articles/using-pull-requests). |
| 25 | + |
| 26 | +Pull requests should be targeted at the `master` branch. Before creating a pull request, go through this checklist: |
| 27 | + |
| 28 | +1. Create a feature branch off of `master` so that changes do not get mixed up. |
| 29 | +2. If your PR adds new code, it should include tests covering the new code. If your PR fixes a bug, it should include a regression test. |
| 30 | +3. PRs that change user-facing behavior or the command-line interface must have associated documentation. |
| 31 | +4. All code comments and documentation are expected to have proper English grammar and punctuation. |
| 32 | +5. [Rebase](http://git-scm.com/book/en/Git-Branching-Rebasing) your local changes against the `master` branch. |
| 33 | +6. Run the full project test suite with the `go test ./...` command and confirm that it passes (see [TESTING.md](TESTING.md) for details). |
| 34 | +7. Run `go fmt ./...`. |
| 35 | + |
| 36 | +When creating a PR: |
| 37 | + |
| 38 | +1. Your PR title should be descriptive, and follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification (start with `fix:`, `feat:`, or similar). |
| 39 | +2. Your PR commit message will be used as the commit message when your PR is merged. Update this field if your PR diverges during review. |
| 40 | +3. Your PR description should have details on what the PR does. If it fixes an existing issue, include a line like "Fixes #XXXX". |
| 41 | + |
| 42 | +When all of the tests are passing, maintainer(s) will be assigned to review and merge the PR. If you're having trouble getting tests to pass, feel free to tag in [MAINTAINERS](MAINTAINERS) for help, or ask in Slack (see [Communication](#communication) below). |
| 43 | + |
| 44 | + |
| 45 | +## Communication |
| 46 | + |
| 47 | +We use the [#tuf](https://cloud-native.slack.com/archives/C8NMD3QJ3) and [#go-tuf](https://cloud-native.slack.com/archives/C02D577GX54) channel on [CNCF Slack](https://slack.cncf.io/). You are welcome to drop in and ask questions, discuss bugs, etc. |
| 48 | + |
| 49 | +You might also be interested in the TUF community beyond go-tuf; good places to start include: |
| 50 | + |
| 51 | +- [TUF mailing list](https://groups.google.com/g/theupdateframework) |
| 52 | +- TUF community meetings (monthly; join the mailing list or watch the Slack channel to see invitations) |
| 53 | + |
| 54 | + |
| 55 | +## Pull Request Review Policy |
| 56 | + |
| 57 | +* Anyone is welcome to review any PR, whether they are a maintainer or not! |
| 58 | +* Maintainers should aim to turn around reviews within five business days; feel free to ping, or tag in specific maintainers if a PR is taking longer than that. |
| 59 | +* See [MAINTAINERS](MAINTAINERS) for the current list of maintainers. |
| 60 | + |
| 61 | +Maintainers should look in [MAINTAINERS.md](MAINTAINERS.md) for detailed quidelines. |
0 commit comments