1# go-tuf maintainer guidelines
2
3These 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
7Speedy 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
17Versioning:
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 before 1.0).
21- Releases should be tagged in this repository as usual in Go (e.g. `v0.3.1`; see [Publishing a module](https://go.dev/doc/modules/publishing)).
22 - All maintainers should have permissions to push an appropriately-named `tag`, which will trigger the full release process.
23 - A patch release can happen at any point, but give the other maintainers 1 day's notice via Slack or GitHub first.
24 - For a minor release, see the "Project management" tag below.
25 - We may revisit this policy post-1.0.
26
27Project management:
28
29- Try to keep issues up-to-date with status updates!
30 - Feel free to ping open issues to check on them.
31 - Use the "assignee" field to indicate when you are working on an issue.
32 - 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).
33- Before publishing a new minor release, there should be an associated [GitHub project](https://github.com/theupdateframework/go-tuf/projects?type=beta) to track issues.
34- We will develop more process around project management after we get through the v0.4.0 release.
35
36## Review checklist
37
38Code review:
39
40- [ ] Tests pass (enforced by CI).
41- [ ] There should be tests for any new functionality, and regression tests for any bugs.
42- [ ] Any user-facing functionality changes/additions (public APIs, command-line interface) should be documented.
43- [ ] Changes should be compliant with the [TUF specification](https://theupdateframework.github.io/specification/latest/).
44
45Pre-merge (check everything again before hitting the merge button!):
46
47- [ ] Approvals from two different organizations.
48 - This is *not* currently enforced by CI, though PRs must have at least 2 approvals.
49 - This may be waived for PRs which only update docs or comments, or trivial changes to tests.
50- Make sure that the PR title, commit message, and description are updated if the PR changes significantly during review.
51
52New version of the TUF specification:
53
54- There's an automated workflow which monitors and opens an issue in case there's newer version of the [TUF specification](https://theupdateframework.github.io/specification/latest/)
55- Closing the issue should happen after completing the following steps:
56 - Review the changes to the specification and make sure they're addressed (possibly requires breaking out a few relevant issues).
57 - Bump the `tuf-version` in the `.github/workflows/specification-version-check.yml` workflow.
View as plain text