github.com/opencontainers/umoci@v0.4.8-0.20240508124516-656e4836fb0d/GOVERNANCE.md (about) 1 <!-- 2 +++ 3 # Hugo Front-matter 4 title = "Governance" 5 aliases = ["/GOVERNANCE.md"] 6 +++ 7 --> 8 9 ## Governance Model ## 10 11 umoci is an OCI project, and is thus governed under the [OCI 12 Charter][oci-charter]. §5(b)(viii) of the Charter tasks the maintainers of 13 each OCI Project with: 14 15 > Creating, maintaining and enforcing governance guidelines for the TDC [of 16 > that OCI Project], approved by the maintainers, and which shall be posted 17 > visibly for the TDC [of that OCI Project]. 18 19 This document describes the governance rules for umoci, and is the 20 authortiative document that describes the governance procedure for umoci. Any 21 change to this document requires a motion and vote (as described below) in 22 order to be a valid modification of this governance document. 23 24 If there are any perceived or real conflicts between this document and the OCI 25 Charter, the OCI Charter takes precedence. 26 27 [oci-charter]: https://github.com/opencontainers/tob/blob/master/CHARTER.md 28 29 ### Code of Conduct ### 30 31 The conduct of all members of the umoci TDC MUST abide by the Open Containers 32 Initative's [Code of Conduct][oci-coc]. 33 34 [oci-coc]: https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md 35 36 ### Code Changes ### 37 38 Any code or documentation changes to the umoci codebase will be made via [pull 39 requests][umoci-pr]. All proposed changes MUST contain a "Signed-off-by" line, 40 indicating that the contribution abides by the [Developer Certificate of 41 Origin][dco]. 42 43 In order for a change to be accepted into the umoci codebase, it MUST be 44 reviewed and accepted by two (2) maintainers (individuals who are listed in the 45 `MAINTAINERS` file at the root of the umoci repository). Maintainers indicate 46 their approval through the use of an "LGTM" comment. Maintainers MAY formally 47 reject a comment by posting "NACK", but this is only an indication to other 48 maintainers of their view and has no impact on the two-LGTM rule. If a 49 contribution was authored by a maintainer, they MAY approve their own change 50 (meaning that only one (1) additional maintainer need review and approve it). 51 Merge commits SHOULD include information about which maintainers approved the 52 change. 53 54 The above review procedure MAY be done in private for patches fixing security 55 issues, but the set of maintainers which approved the patches MUST be publicly 56 known after the patch has been merged into the repository (such as listing them 57 in the merge commit). All private reviews MUST be done via email, with the 58 <security@opencontainers.org> mailing list in Cc to ensure that this system is 59 not being abused. 60 61 Recommendations for contributors may be found in 62 [`CONTRIBUTING.md`][contributing]. 63 64 [umoci-pr]: https://github.com/opencontainers/umoci/compare 65 [dco]: https://developercertificate.org/ 66 [contributing]: /CONTRIBUTING.md 67 68 ### Releases ### 69 70 umoci uses [Semantic Versioning][semver], and all releases MUST follow the 71 SemVer definition of major, minor, and patch releases. The general procedure 72 for preparing a new release is described in [`RELEASES.md`][releases], but all 73 releases MUST have a specific commit which will be tagged as the release. 74 75 A pull request is opened by the individual proposing a release, and then voting 76 is conducted on the release. There are two procedures depending on which part 77 of the version number is being proposed to change: 78 79 * If the major number is being changed from the previous release, a formal 80 vote as described below is required. Due to their disruptive nature, major 81 updates SHOULD be done only in exceptional circumstances after umoci `1.0.0` 82 has been released, and SHOULD be done after significant discussion and 83 agremeent between all umoci maintainers and the umoci TDC. 84 85 * If the minor or patch number (but not the major number) are being changed, 86 then the release MAY be approved by the simplified two-LGTM requirement as 87 required by ordinary code changes. 88 89 All releases SHOULD be announced on the <dev@opencontainers.org> mailing list, 90 and the release artefacts SHOULD be made available as soon as possible. 91 92 [semver]: https://semver.org/ 93 [releases]: /RELEASES.md 94 95 ### Other Changes ### 96 97 All other changes to the umoci project (such as the modification of this 98 document or the addition or removal of maintainers) require a formal voting 99 procedure. Any individual MAY propose a motion (either by creating an issue in 100 the project's issue tracker, or posting a message on the 101 <dev@opencontainers.org> mailing list) but only maintainers' votes on the 102 motion are considered. Any motion which involves merging a change into the 103 codebase (such as motions to change this document, or change the major version 104 number of umoci) MUST include the specific commit which is being proposed for 105 merging. 106 107 All votes MUST have a reasonable deadline (two (2) weeks is most common) listed 108 when the motion is first posted, and the deadline is chosen by the initiator of 109 the motion. 110 111 If the motion is posted to the mailing list, the subject line SHOULD be: 112 113 ``` 114 [umoci VOTE] {motion description} (closes {deadline}) 115 ``` 116 117 But if the motion is posted as an issue, then the subject SHOULD begin with the 118 prefix `[VOTE]`. 119 120 In order for a motion to pass, a qualified super-majority (at least two-thirds, 121 with abstain and non-votes counting as votes *against* the motion) of the 122 project's maintainers MUST vote in favour of the motion. Votes MUST be 123 indicated as follows: 124 125 * Votes in favour with "LGTM" or "+1". 126 * Votes against with "NACK", "REJECT", or "-1". 127 * Abstain votes with "ABSTAIN". 128 129 Maintainers MAY vote multiple times, with their final vote (at the close of the 130 voting period) being treated as their decision. 131 132 Once a vote has completed, the vote totals and a brief description of the 133 motion MUST be posted on the <dev@opencontainers.org> mailing list. The subject 134 line of the vote tally SHOULD be: 135 136 ``` 137 [umoci {ACCEPTED|REJECTED}] {motion description} (+{LGTMs} -{REJECTs} #{ABSTAINs}) 138 ``` 139 140 [oci-ml]: mailto:dev@opencontainers.org