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]. &sect;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