opencontainers · wking · Sep 9, 2016 · Sep 9, 2016 · Sep 9, 2016 · Sep 9, 2016
diff --git a/CONTRIBUTING.md b/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
diff --git a/MAINTAINERS b/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 <random@developer.example.org> (@RandomJDeveloperExample)
+A. U. Thor <author@example.org> (@AUThorExample)
+
+[1]: https://github.com/opencontainers/
diff --git a/MAINTAINERS_GUIDE.md b/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?
 
@@ -105,13 +107,7 @@ 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?
-
-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.

diff --git a/README.md b/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)