opencontainers · wking · May 3, 2016 · May 3, 2016 · May 3, 2016 · May 3, 2016
@@ -24,9 +24,13 @@ Fork the repo and make changes on your fork in a feature branch:
 - If it's a feature branch, create an enhancement issue to announce your
   intentions, and name it XXX-something where XXX is the number of the issue.
 
-Submit unit tests for your changes.  Go has a great test framework built in; use
-it! Take a look at existing tests for inspiration. Run the full test suite on
-your branch before submitting a pull request.
+Small changes or changes that have been discussed on the project mailing list
+may be submitted without a leader issue, in which case you are free to name
+your branch however you like.
+
+If the project has a test suite, submit unit tests for your changes. Take a
+look at existing tests for inspiration. Run the full test suite on your branch
+before submitting a pull request.
 
 Update the documentation when creating or modifying features. Test
 your documentation changes for clarity, concision, and correctness, as
@@ -40,10 +44,8 @@ committing your changes. Most editors have plugins that do this automatically.
 Pull requests descriptions should be as clear as possible and include a
 reference to all the issues that they address.
 
-Pull requests must not contain commits from other users or branches.
-
-Commit messages must start with a capitalized and short summary (max. 50
-chars) written in the imperative, followed by an optional, more detailed
+Commit messages must start with a capitalized and short summary
+written in the imperative, followed by an optional, more detailed
 explanatory text which is separated from the summary by an empty line.
 
 Code review comments may be added to your pull request. Discuss, then make the
@@ -54,8 +56,9 @@ comment.
 
 Before the pull request is merged, make sure that you squash your commits into
 logical units of work using `git rebase -i` and `git push -f`. After every
-commit the test suite should be passing. Include documentation changes in the
-same commit so that a revert would remove all traces of the feature or fix.
+commit the test suite (if any) should be passing. Include documentation changes
+in the same commit so that a revert would remove all traces of the feature or
+fix.
 
 Commits that fix or close an issue should include a reference like `Closes #XXX`
 or `Fixes #XXX`, which will automatically close the issue when merged.

@@ -0,0 +1,70 @@
+# Project governance
+
+The [OCI charter][charter] §5.b.viii tasks an OCI Project's maintainers (listed in the repository's MAINTAINERS file and sometimes referred to as "the TDC", [§5.e][charter]) with:
+
+> Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC.
+
+This section describes generic rules and procedures for fulfilling that mandate.
+
+## Proposing a motion
+
+A maintainer SHOULD propose a motion on the [email protected] mailing list (except [security issues](#security-issues)) with another maintainer as a co-sponsor.
+
+## Voting
+
+Voting on a proposed motion SHOULD happen on the [email protected] mailing list (except [security issues](#security-issues)) with maintainers posting LGTM or REJECT.
+Maintainers MAY also explicitly not vote by posting ABSTAIN (which is useful to revert a previous vote).
+Maintainers MAY post multiple times (e.g. as they revise their position based on feeback), but only their final post counts in the tally.
+A proposed motion is adopted if two-thirds of votes cast, a quorum having voted, are in favor of the release.
+
+Voting SHOULD remain open for a week to collect feedback from the wider community and allow the maintainers to digest the proposed motion.
+Under exceptional conditions (e.g. non-major security fix releases) proposals which reach quorum with unanimous support MAY be adopted earlier.
+
+A maintainer MAY choose to reply with REJECT.
+A maintainer posting a REJECT MUST include a list of concerns or links to written documentation for those concerns (e.g. GitHub issues or mailing-list threads).
+The maintainers SHOULD try to resolve the concerns and wait for the rejecting maintainer to change their opinion to LGTM.
+However, a motion MAY be adopted with REJECTs, as outlined in the previous paragraphs.
+
+## Quorum
+
+A quorum is established when at least two-thirds of maintainers have voted.
+
+For projects that are not specifications, a [motion to release](#release-approval) MAY be adopted if the tally is at least three LGTMs and no REJECTs, even if three votes does not meet the usual two-thirds quorum.
+
+## Security issues
+
+Motions with sensitive security implications MUST be proposed on the [email protected] mailing list instead of [email protected], but should otherwise follow the standard [proposal](#proposing-a-motion) process.
+The [email protected] mailing list includes all members of the TOB.
+The TOB will contact the project maintainers and provide a channel for discussing and voting on the motion, but voting will otherwise follow the standard [voting](#voting) and [quorum](#quorum) rules.
+The TOB and project maintainers will work together to notify affected parties before making an adopted motion public.
+
+## Amendments
+
+The [project governance](#project-governance) rules and procedures MAY be amended or replaced using the procedures themselves.
+The MAINTAINERS of this project governance document is the total set of MAINTAINERS from all Open Containers projects (runC, runtime-spec, and image-spec).
+
+## Subject templates
+
+Maintainers are busy and get lots of email.
+To make project proposals recognizable, proposed motions SHOULD use the following subject templates.
+
+### Proposing a motion
+
+> [{project} VOTE]: {motion description} (closes {end of voting window})
+
+For example:
+
+> [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC)
+
+### Tallying results
+
+After voting closes, a maintainer SHOULD post a tally to the motion thread with a subject template like:
+
+> [{project} {status}]: {motion description} (+{LGTMs} -{REJECTs} #{ABSTAINs})
+
+Where `{status}` is either `adopted` or `rejected`.
+For example:
+
+> [runtime-spec adopted]: Tag 0647920 as 1.0.0-rc (+6 -0 #3)
+
+[charter]: https://www.opencontainers.org/about/governance
@@ -1,4 +1,3 @@
-
                                  Apache License
                            Version 2.0, January 2004
                         http://www.apache.org/licenses/
@@ -176,7 +175,18 @@
 
    END OF TERMS AND CONDITIONS
 
-   Copyright 2015 The Linux Foundation.
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "{}"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright {yyyy} {name of copyright owner}
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

@@ -50,7 +50,7 @@ All decisions affecting this project, big and small, follow the same 3 steps:
 
 * Step 2: Discuss the pull request. Anyone can do this.
 
-* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do 
+* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do
 this (see below "Who decides what?")
 
 ### I'm a maintainer, should I make pull requests too?
@@ -62,43 +62,45 @@ made through a pull request.
 
 All decisions are pull requests, and the relevant maintainers make
 decisions by accepting or refusing the pull request. Review and acceptance
-by anyone is denoted by adding a comment in the pull request: `LGTM`. 
+by anyone is denoted by adding a comment in the pull request: `LGTM`.
 However, only currently listed `MAINTAINERS` are counted towards the required
-two LGTMs.
+two LGTMs. In addition, if a maintainer has created a pull request, they cannot
+count toward the two LGTM rule (to ensure equal amounts of review for every pull
+request, no matter who wrote it).
 
 Overall the maintainer system works because of mutual respect across the
 maintainers of the project.  The maintainers trust one another to make decisions
-in the best interests of the project.  Sometimes maintainers can disagree and 
+in the best interests of the project.  Sometimes maintainers can disagree and
 this is part of a healthy project to represent the point of views of various people.
-In the case where maintainers cannot find agreement on a specific change the 
-role of a Chief Maintainer comes into play.  
+In the case where maintainers cannot find agreement on a specific change the
+role of a Chief Maintainer comes into play.
 
-The Chief Maintainer for the project is responsible for overall architecture 
-of the project to maintain conceptual integrity.  Large decisions and 
-architecture changes should be reviewed by the chief maintainer.  
-The current chief maintainer for the project is the first person listed 
-in the MAINTAINERS file.  
+The Chief Maintainer for the project is responsible for overall architecture
+of the project to maintain conceptual integrity.  Large decisions and
+architecture changes should be reviewed by the chief maintainer.
+The current chief maintainer for the project is the first person listed
+in the MAINTAINERS file.
 
 Even though the maintainer system is built on trust, if there is a conflict
-with the chief maintainer on a decision, their decision can be challenged 
-and brought to the technical oversight board if two-thirds of the 
-maintainers vote for an appeal. It is expected that this would be a 
+with the chief maintainer on a decision, their decision can be challenged
+and brought to the technical oversight board if two-thirds of the
+maintainers vote for an appeal. It is expected that this would be a
 very exceptional event.
 
 
 ### How are maintainers added?
 
 The best maintainers have a vested interest in the project.  Maintainers
 are first and foremost contributors that have shown they are committed to
-the long term success of the project.  Contributors wanting to become 
-maintainers are expected to be deeply involved in contributing code, 
+the long term success of the project.  Contributors wanting to become
+maintainers are expected to be deeply involved in contributing code,
 pull request review, and triage of issues in the project for more than two months.
 
-Just contributing does not make you a maintainer, it is about building trust 
+Just contributing does not make you a maintainer, it is about building trust
 with the current maintainers of the project and being a person that they can
 depend on and trust to make decisions in the best interest of the project.  The
 final vote to add a new maintainer should be approved by over 66% of the current
-maintainers with the chief maintainer having veto power.  In case of a veto, 
+maintainers with the chief maintainer having veto power.  In case of a veto,
 conflict resolution rules expressed above apply.  The voting period is
 five business days on the Pull Request to add the new maintainer.
 
@@ -116,6 +118,3 @@ a vote by 66% of the current maintainers with the chief maintainer having veto p
 The voting period is ten business days.  Issues related to a maintainer's performance should
 be discussed with them among the other maintainers so that they are not surprised by
 a pull request removing them.
-
-
-
@@ -0,0 +1,51 @@
+# Releases
+
+The release process hopes to encourage early, consistent consensus-building during project development.
+The mechanisms used are regular community communication on the mailing list about progress, scheduled meetings for issue resolution and release triage, and regularly paced and communicated releases.
+Releases are proposed and adopted or rejected using the usual [project governance](GOVERNANCE.md) rules and procedures.
+
+An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases.
+We want to build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability.
+
+## Parallel releases
+
+A single project MAY consider several motions to release in parallel.
+However each motion to release after the initial 0.1.0 MUST be based on a previous release that has already landed.
+
+For example, runtime-spec maintainers may propose a v1.0.0-rc2 on the 1st of the month and a v0.9.1 bugfix on the 2nd of the month.
+They may not propose a v1.0.0-rc3 until the v1.0.0-rc2 is accepted (on the 7th if the vote initiated on the 1st passes).
+
+## Specifications
+
+The OCI maintains three categories of projects: specifications, applications, and conformance-testing tools.
+However, specification releases have special restrictions in the [OCI charter][charter]:
+
+* They are the target of backwards compatibility (§7.g), and
+* They are subject to the OFWa patent grant (§8.d and e).
+
+To avoid unfortunate side effects (onerous backwards compatibity requirements or Member resignations), the following additional procedures apply to specification releases:
+
+### Planning a release
+
+Every OCI specification project SHOULD hold meetings that involve maintainers reviewing pull requests, debating outstanding issues, and planning releases.
+This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC.
+Maintainers MUST send updates to the [email protected] with results of these meetings.
+
+Before the specification reaches v1.0.0, the meetings SHOULD be weekly.
+Once a specification has reached v1.0.0, the maintainers may alter the cadence, but a meeting MUST be held within four weeks of the previous meeting.
+
+The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones).
+GitHub milestones and issues are only used for community organization and all releases MUST follow the [project governance](GOVERNANCE.md) rules and procedures.
+
+### Timelines
+
+Specifications have a variety of different timelines in their lifecycle.
+
+* Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback.
+* Major specification releases MUST release at least three release candidates spaced a minimum of one week apart.
+  This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
+  Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
+  For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
+- Minor and patch releases SHOULD be made on an as-needed basis.
+
+[charter]: https://www.opencontainers.org/about/governance