Skip to content

Commit 1684c68

Browse files
znewman01asraa
andauthored
docs: Update CONTRIBUTING.md, add MAINTAINERS.md (#309)
* add contrbuting guidelines Signed-off-by: Asra Ali <[email protected]> * Update CONTRIBUTING.md, add MAINTAINERS.md Follow-up from #190 (thanks @asraa!). I did not add a DCO requirement at this point, as that was controversial in #190. I filed #308 to track that. I tried to address all *other* feedback in #190. Fixes #212. Fixes #306. * Move docs into a "docs" folder. Fixes #303. * Whitespace fixes * Address PR comments - TODO for testing instructions - Remove obsolete TODO * Full URL in testing * Fix @joshuagl suggestions Co-authored-by: Asra Ali <[email protected]>
1 parent e24b175 commit 1684c68

File tree

7 files changed

+119
-2
lines changed

7 files changed

+119
-2
lines changed

CONTRIBUTING.md

Lines changed: 0 additions & 1 deletion
This file was deleted.

README.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -605,7 +605,7 @@ For the client package, see https://godoc.org/github.com/theupdateframework/go-t
605605

606606
For the client CLI, see https://github.com/theupdateframework/go-tuf/tree/master/cmd/tuf-client.
607607

608-
## Development
608+
## Contributing and Development
609609

610610
For local development, `go-tuf` requires Go version 1.16 or 1.17.
611611

@@ -614,3 +614,5 @@ The [Python interoperability tests](client/python_interop/) require Python 3
614614
package](https://github.com/theupdateframework/python-tuf) installed (`pip
615615
install tuf`). To update the data for these tests requires Docker and make (see
616616
test data [README.md](client/python_interop/testdata/README.md) for details).
617+
618+
Please see [CONTRIBUTING.md](CONTRIBUTING.md) for contribution guidelines before making your first contribution!

docs/CODE_OF_CONDUCT.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
## The Update Framework Community Code of Conduct
2+
3+
The Update Framework follows the [CNCF Code of
4+
Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)

docs/CONTRIBUTING.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
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.
File renamed without changes.

docs/MAINTAINERS.md

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
# go-tuf maintainer guidelines
2+
3+
These are expectations for the [MAINTAINERS](MAINTAINERS) of go-tuf; if you are not able to meet these requirements, please remove yourself from the list of maintainers.
4+
5+
## Process
6+
7+
Speedy communication makes contributors happy!
8+
9+
- You should get notifications for all activity in this repository (using the "Watch" feature) and quickly triage each issue/PR as it comes in.
10+
- (non-draft) PRs should have assigned reviewers.
11+
- Important bugs and questions should have assignees.
12+
- If you are assigned to review a PR, please try to *acknowledge* it within one business day (no need if you are OOO).
13+
- Please review all PRs within five business days (of course, it's okay if you're OOO).
14+
- Please use the review checklist below.
15+
- We should make sure there's an assigned reviewer for every PR which has passing tests.
16+
17+
Versioning:
18+
19+
- go-tuf releases follow [SemVer](https://semver.org/) with the following modification:
20+
- While go-tuf is pre-1.0, increment the minor version for any breaking changes (in SemVer, there are no guarantees about API stability).
21+
- Releases should be tagged in this repository as usual in Go ([Publishing a module](https://go.dev/doc/modules/publishing)).
22+
23+
Project management:
24+
25+
- Try to keep issues up-to-date with status updates!
26+
- Feel free to ping open issues to check on them.
27+
- Use the "assignee" field to indicate when you are working on an issue.
28+
- Use GitHub issue labels to describe the issue (exact labels are still changing, so just look through and add those that seem like a good fit).
29+
- Before publishing a new release, there should be an associated [GitHub project](https://github.com/theupdateframework/go-tuf/projects?type=beta) to track issues.
30+
- We will develop more process around project management after we get through the v0.4.0 release.
31+
32+
## Review checklist
33+
34+
Code review:
35+
36+
- [ ] Tests pass (enforced by CI).
37+
- [ ] There should be tests for any new functionality, and regression tests for any bugs.
38+
- [ ] Any user-facing functionality changes/additions (public APIs, command-line interface) should be documented.
39+
- [ ] Changes should be compliant with the [TUF specification](https://theupdateframework.github.io/specification/latest/).
40+
41+
Pre-merge (check everything again before hitting the merge button!):
42+
43+
- [ ] Approvals from two different organizations.
44+
- This is *not* currently enforced by CI, though PRs must have at least 2 approvals.
45+
- This may be waived for PRs which only update docs or comments, or trivial changes to tests.
46+
- Make sure that the PR title, commit message, and description are updated if the PR changes significantly during review.
47+
48+

docs/TESTING.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
# Testing
2+
3+
TODO([#301](https://github.com/theupdateframework/go-tuf/issues/301))

0 commit comments

Comments
 (0)