Merge branch 'master' into minor-patch-bullet

Author: caniszczyk

.pullapprove.yml

@@ -4,19 +4,20 @@ requirements:
   signed_off_by:
     required: true
 
+always_pending:
+  title_regex: '^WIP'
+  explanation: 'Work in progress...'
+
 group_defaults:
   required: 2
   approve_by_comment:
     enabled: true
-    approve_regex: ^LGTM
-    reject_regex: ^Rejected
+    approve_regex: '^LGTM'
+    reject_regex: '^Rejected'
   reset_on_push:
     enabled: true
   author_approval:
     ignored: true
-  always_pending:
-    title_regex: ^WIP
-    explanation: 'Work in progress...'
   conditions:
     branches:
       - master

CONTRIBUTING.md

@@ -1,4 +1,31 @@
-## Contribution Guidelines
+# Contribution Guidelines
+
+Development happens on GitHub.
+Issues are used for bugs and actionable items and longer discussions can happen on the [mailing list](#mailing-list).
+
+The content of this repository is licensed under the [Apache License, Version 2.0](LICENSE).
+
+## Code of Conduct
+
+Participation in the Open Container community is governed by [Open Container Code of Conduct][code-of-conduct].
+
+## Meetings
+
+The contributors and maintainers of all OCI projects have monthly meetings at 2:00 PM (USA Pacific) on the first Wednesday of every month.
+There is an [iCalendar][rfc5545] format for the meetings [here][meeting.ics].
+Everyone is welcome to participate via [UberConference web][UberConference] or audio-only: +1 415 968 0849 (no PIN needed).
+An initial agenda will be posted to the [mailing list](#mailing-list) in the week before each meeting, and everyone is welcome to propose additional topics or suggest other agenda alterations there.
+Minutes from past meetings are archived [here][minutes].
+
+## Mailing list
+
+You can subscribe and browse the mailing list on [Google Groups][mailing-list].
+
+## IRC
+
+OCI discussion happens on #opencontainers on [Freenode][] ([logs][irc-logs]).
+
+## Git
 
 ### Security issues
 
@@ -21,25 +48,19 @@ We're trying very hard to keep the project lean and focused. We don't want it
 to do everything for everybody. This means that we might decide against
 incorporating a new feature.
 
-
 ### Conventions
 
 Fork the repo and make changes on your fork in a feature branch.
 For larger bugs and enhancements, consider filing a leader issue or mailing-list thread for discussion that is independent of the implementation.
-Small changes or changes that have been discussed on the project mailing list may be submitted without a leader issue.
+Small changes or changes that have been discussed on the [project mailing list](#mailing-list) may be submitted without a leader issue.
 
 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
-well as a clean documentation build. See ``docs/README.md`` for more
-information on building the docs and how docs get released.
-
-Write clean code. Universally formatted code promotes ease of writing, reading,
-and maintenance. Always run `gofmt -s -w file.go` on each changed file before
-committing your changes. Most editors have plugins that do this automatically.
+well as a clean documentation build.
 
 Pull requests descriptions should be as clear as possible and include a
 reference to all the issues that they address.
@@ -68,8 +89,7 @@ or `Fixes #XXX`, which will automatically close the issue when merged.
 The sign-off is a simple line at the end of the explanation for the
 patch, which certifies that you wrote it or otherwise have the right to
 pass it on as an open-source patch.  The rules are pretty simple: if you
-can certify the below (from
-[developercertificate.org](http://developercertificate.org/)):
+can certify the below (from [developercertificate.org][]):
 
 ```
 Developer Certificate of Origin
@@ -118,3 +138,12 @@ then you just add a line to every git commit message:
 using your real name (sorry, no pseudonyms or anonymous contributions.)
 
 You can add the sign off when creating the git commit via `git commit -s`.
+
+[code-of-conduct]: https://github.com/opencontainers/tob/blob/d2f9d68c1332870e40693fe077d311e0742bc73d/code-of-conduct.md
+[developercertificate.org]: http://developercertificate.org/
+[Freenode]: https://freenode.net/
+[irc-logs]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/
+[mailing-list]: https://groups.google.com/a/opencontainers.org/forum/#!forum/dev
+[meeting.ics]: https://github.com/opencontainers/runtime-spec/blob/master/meeting.ics
+[minutes]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/
+[UberConference]: https://www.uberconference.com/opencontainers

GOVERNANCE.md

@@ -14,7 +14,7 @@ A maintainer SHOULD propose a motion on the [email protected] mailing list
 
 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.
+Maintainers MAY post multiple times (e.g. as they revise their position based on feedback), 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.

MAINTAINERS

@@ -0,0 +1,8 @@
+This meta-project is maintained by the union of MAINTAINERS for all OCI Projects [1].
+
+Other OCI Projects should list one maintainer per line, with a name, email address, and GitHub username:
+
+Random J Developer <[email protected]> (@RandomJDeveloperExample)
+A. U. Thor <[email protected]> (@AUThorExample)
+
+[1]: https://github.com/opencontainers/

MAINTAINERS_GUIDE.md

@@ -18,21 +18,18 @@ available to them.
 This is a living document - if you see something out of date or missing,
 speak up!
 
-## What are a maintainer's responsibility?
+## What are a maintainer's responsibilities?
 
 It is every maintainer's responsibility to:
 
-* 1) Expose a clear roadmap for improving their component.
-* 2) Deliver prompt feedback and decisions on pull requests.
-* 3) Be available to anyone with questions, bug reports, criticism etc.
-  on their component. This includes IRC and GitHub issues and pull requests.
-* 4) Make sure their component respects the philosophy, design and
-  roadmap of the project.
+* Expose a clear roadmap for improving their component.
+* Deliver prompt feedback and decisions on pull requests.
+* Be available to anyone with questions, bug reports, criticism etc. on their component.
+  This includes IRC and GitHub issues and pull requests.
+* Make sure their component respects the philosophy, design and roadmap of the project.
 
 ## How are decisions made?
 
-Short answer: with pull requests to the project repository.
-
 This project is an open-source project with an open design philosophy. This
 means that the repository is the source of truth for EVERY aspect of the
 project, including its philosophy, design, roadmap and APIs. *If it's
@@ -44,14 +41,19 @@ repository. An implementation change is a change to the source code. An
 API change is a change to the API specification. A philosophy change is
 a change to the philosophy manifesto. And so on.
 
-All decisions affecting this project, big and small, follow the same 3 steps:
-
-* Step 1: Open a pull request. Anyone can do this.
+All decisions affecting this project, big and small, follow the same procedure:
 
-* Step 2: Discuss the pull request. Anyone can do this.
-
-* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do
-this (see below "Who decides what?")
+1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list).
+   Anyone can do this.
+2. Open a pull request.
+   Anyone can do this.
+3. Discuss the pull request.
+   Anyone can do this.
+4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request.
+   The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
+   Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).
+5. Merge or close the pull request.
+   The relevant maintainers do this.
 
 ### I'm a maintainer, should I make pull requests too?
 
@@ -68,25 +70,10 @@ 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
-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.
-
-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
-very exceptional event.
-
+Overall the maintainer system works because of mutual respect.
+The maintainers trust one another to act in the best interests of the project.
+Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people.
+In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus.
 
 ### How are maintainers added?
 
@@ -96,25 +83,10 @@ 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
-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,
-conflict resolution rules expressed above apply.  The voting period is
-five business days on the Pull Request to add the new maintainer.
-
-
-### What is expected of maintainers?
+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 to act in the best interest of the project.
+The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md).
 
-Part of a healthy project is to have active maintainers to support the community
-in contributions and perform tasks to keep the project running.  Maintainers are
-expected to be able to respond in a timely manner if their help is required on specific
-issues where they are pinged.  Being a maintainer is a time consuming commitment and should
-not be taken lightly.
+### How are maintainers removed?
 
-When a maintainer is unable to perform the required duties they can be removed with
-a vote by 66% of the current maintainers with the chief maintainer having veto power.
-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.
+When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md).
+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.

README.md

@@ -1,8 +1,11 @@
 # OCI Project Template
 
-All OCI projects should have:
-* LICENSE
-* CONTRIBUTING.md
-* MAINTAINERS.md
-* MAINTAINERS_GUIDE.md
-* README
+Useful boilerplate and organizational information for all OCI projects.
+
+* README (this file)
+* [The Apache License, Version 2.0](LICENSE)
+* [A list of maintainers](MAINTAINERS)
+* [Maintainer guidelines](MAINTAINERS_GUIDE.md)
+* [Contributor guidelines](CONTRIBUTING.md)
+* [Project governance](GOVERNANCE.md)
+* [Release procedures](RELEASES.md)