|
| 1 | +# Governance |
| 2 | + |
| 3 | +## Project Roles |
| 4 | + |
| 5 | +### Contributors |
| 6 | + |
| 7 | +Individuals who want to contribute ideas to the TUF specification. Cleanups and |
| 8 | +clarifications are discussed in [GitHub Issues]( |
| 9 | +https://github.com/theupdateframework/specification/issues) |
| 10 | +and submitted as [GitHub Pull Requests]( |
| 11 | +https://github.com/theupdateframework/specification/pulls). |
| 12 | + |
| 13 | +New ideas and enhancements to the specification are submitted through the [TUF |
| 14 | +Augmentation Proposal (TAP) process]( |
| 15 | +https://github.com/theupdateframework/taps/blob/master/tap1.md). |
| 16 | + |
| 17 | +### Consensus Builder |
| 18 | + |
| 19 | +Ultimate authority for changes to the TUF specification, including changes |
| 20 | +proposed through the [TAP process]( |
| 21 | +https://github.com/theupdateframework/taps/blob/master/tap1.md), falls to the |
| 22 | +specification's Consensus Builder. |
| 23 | + |
| 24 | +### TAP Editors |
| 25 | + |
| 26 | +The TAP Editors are a team of core contributors to the TUF project who are |
| 27 | +responsible for reviewing and approving, or rejecting, any proposed |
| 28 | +[TAPs](https://github.com/theupdateframework/taps), and changes to the |
| 29 | +specification. |
| 30 | + |
| 31 | + |
| 32 | +## Change Review Process |
| 33 | + |
| 34 | +__All changes must be submitted as a GitHub Pull Request (PR)__ |
| 35 | + |
| 36 | +The submitter of the PR is responsible for responding to feedback from |
| 37 | +reviewers and maintainers. While the PR remains open the submitter is also |
| 38 | +responsible for ensuring the change is always in a state where it can be |
| 39 | +merged. That is, the Pull Request does not have any unresolved conflicts, |
| 40 | +and has incremented the version number and last modified date as described |
| 41 | +in the Versioning section of the README file. |
| 42 | + |
| 43 | +__All minor changes must be approved by at least two (2) other TAP editors__ |
| 44 | + |
| 45 | +Obvious language correctness (grammar and typo fixes), or other changes that |
| 46 | +do not significantly alter the specification must be approved by at least two |
| 47 | +(2) TAP Editors. These minor changes do not require a contemplation period. |
| 48 | + |
| 49 | +__All major changes must be approved by at least two (2) other TAP editors, |
| 50 | +and merged no sooner than one (1) week after submission__ |
| 51 | + |
| 52 | +In order to ensure the security properties of TUF are maintained it is |
| 53 | +necessary to contemplate how any changes to the specification may affect those |
| 54 | +security properties. Therefore, all PRs containing non-minor changes will |
| 55 | +remain open for at least one (1) week to allow all interested TAP Editors time |
| 56 | +to review the submission. |
| 57 | + |
| 58 | +A TAP editor may request longer to consider the changes, so long as that |
| 59 | +request is made within the initial one (1) week contemplation period. |
| 60 | + |
| 61 | +Non-minor changes to the specification require two (2) TAP editor approvals. |
| 62 | + |
| 63 | +Major changes should not be merged when there are outstanding changes |
| 64 | +requested. In cases where the requested changes are not agreeable to the |
| 65 | +submitter, and therefore will not be made, the request for changes should be |
| 66 | +revoked by the requesting TAP editor. |
| 67 | +When consensus can not be agreed between submitter and TAP editors, |
| 68 | +the Consensus Builder holds ultimate authority on whether to accept the |
| 69 | +proposed change. |
0 commit comments