*: Pull opencontainers/project-template

CONTRIBUTING.md

@@ -1,35 +1,90 @@
-# Contributing to Docker open source projects
+## Contribution Guidelines
 
-Want to hack on this project? Awesome! Here are instructions to get you started.
+### Security issues
 
-This project is a part of the [Docker](https://www.docker.com) project, and follows
-the same rules and principles. If you're already familiar with the way
-Docker does things, you'll feel right at home.
+If you are reporting a security issue, do not create an issue or file a pull
+request on GitHub. Instead, disclose the issue responsibly by sending an email
+to [email protected] (which is inhabited only by the maintainers of
+the various OCI projects).
 
-Otherwise, go read Docker's
-[contributions guidelines](https://github.com/docker/docker/blob/master/CONTRIBUTING.md),
-[issue triaging](https://github.com/docker/docker/blob/master/project/ISSUE-TRIAGE.md),
-[review process](https://github.com/docker/docker/blob/master/project/REVIEWING.md) and
-[branches and tags](https://github.com/docker/docker/blob/master/project/BRANCHES-AND-TAGS.md).
+### Pull requests are always welcome
 
-For an in-depth description of our contribution process, visit the
-contributors guide: [Understand how to contribute](https://docs.docker.com/opensource/workflow/make-a-contribution/)
+We are always thrilled to receive pull requests, and do our best to
+process them as fast as possible. Not sure if that typo is worth a pull
+request? Do it! We will appreciate it.
+
+If your pull request is not accepted on the first try, don't be
+discouraged! If there's a problem with the implementation, hopefully you
+received feedback on what to improve.
+
+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:
+
+- If it's a bugfix branch, name it XXX-something where XXX is the number of the
+  issue
+- 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.
+
+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
+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.
+
+Pull requests descriptions should be as clear as possible and include a
+reference to all the issues that they address.
+
+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
+suggested modifications and push additional commits to your feature branch. Be
+sure to post a comment after pushing. The new commits will show up in the pull
+request automatically, but the reviewers will not be notified unless you
+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 (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.
 
 ### Sign your work
 
-The sign-off is a simple line at the end of the explanation for the patch. Your
-signature certifies that you wrote the patch 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/)):
+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/)):
 
 ```
 Developer Certificate of Origin
 Version 1.1
 
 Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
-1 Letterman Drive
-Suite D4700
-San Francisco, CA, 94129
+660 York Street, Suite 102,
+San Francisco, CA 94110 USA
 
 Everyone is permitted to copy and distribute verbatim copies of this
 license document, but changing it is not allowed.
@@ -62,11 +117,10 @@ By making a contribution to this project, I certify that:
     this project or the open source license(s) involved.
 ```
 
-Then you just add a line to every git commit message:
+then you just add a line to every git commit message:
 
-    Signed-off-by: Joe Smith <joe.smith@email.com>
+    Signed-off-by: Joe Smith <joe@gmail.com>
 
-Use your real name (sorry, no pseudonyms or anonymous contributions.)
+using your real name (sorry, no pseudonyms or anonymous contributions.)
 
-If you set your `user.name` and `user.email` git configs, you can sign your
-commit automatically with `git commit -s`.
+You can add the sign off when creating the git commit via `git commit -s`.

GOVERNANCE.md

@@ -0,0 +1,63 @@
+# 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.
+
+## 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

LICENSE.code → LICENSE

@@ -1,7 +1,6 @@
-
                                  Apache License
                            Version 2.0, January 2004
-                        https://www.apache.org/licenses/
+                        http://www.apache.org/licenses/
 
    TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 
@@ -176,13 +175,24 @@
 
    END OF TERMS AND CONDITIONS
 
-   Copyright 2016 Docker, Inc.
+   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.
    You may obtain a copy of the License at
 
-       https://www.apache.org/licenses/LICENSE-2.0
+       http://www.apache.org/licenses/LICENSE-2.0
 
    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,

MAINTAINERS_GUIDE.md

@@ -0,0 +1,120 @@
+## Introduction
+
+Dear maintainer. Thank you for investing the time and energy to help
+make this project as useful as possible. Maintaining a project is difficult,
+sometimes unrewarding work.  Sure, you will get to contribute cool
+features to the project. But most of your time will be spent reviewing,
+cleaning up, documenting, answering questions, justifying design
+decisions - while everyone has all the fun! But remember - the quality
+of the maintainers work is what distinguishes the good projects from the
+great.  So please be proud of your work, even the unglamourous parts,
+and encourage a culture of appreciation and respect for *every* aspect
+of improving the project - not just the hot new features.
+
+This document is a manual for maintainers old and new. It explains what
+is expected of maintainers, how they should work, and what tools are
+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?
+
+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.
+
+## 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
+part of the project, it's in the repo. It's in the repo, it's part of
+the project.*
+
+As a result, all decisions can be expressed as changes to the
+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.
+
+* 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?")
+
+### I'm a maintainer, should I make pull requests too?
+
+Yes. Nobody should ever push to master directly. All changes should be
+made through a pull request.
+
+## Who decides what?
+
+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`.
+However, only currently listed `MAINTAINERS` are counted towards the required
+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.
+
+
+### 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,
+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?
+
+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.
+
+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.

README.md

@@ -88,17 +88,10 @@ the alternatives you tried before submitting a PR.
 
 # Reporting security issues
 
-The maintainers take security seriously. If you discover a security 
-issue, please bring it to their attention right away!
-
-Please DO NOT file a public issue, instead send your report privately
-to [email protected].
-
-Security reports are greatly appreciated and we will publicly thank you 
-for it. We also like to send gifts—if you're into Docker schwag, make 
-sure to let us know. We currently do not offer a paid security bounty 
-program, but are not ruling it out in the future.
+Guidelines for reporting security issues are [here][security].
 
 # Copyright and license
 
-Copyright © 2016 Docker, Inc. All rights reserved, except as follows. Code is released under the [Apache 2.0 license](LICENSE.code). This `README.md` file and the [`CONTRIBUTING.md`](CONTRIBUTING.md) file are licensed under the Creative Commons Attribution 4.0 International License under the terms and conditions set forth in the file [`LICENSE.docs`](LICENSE.docs). You may obtain a duplicate copy of the same license, titled CC BY-SA 4.0, at http://creativecommons.org/licenses/by-sa/4.0/.
+Copyright © 2016 Docker, Inc. All rights reserved, except as follows. Code and the [`CONTRIBUTING.md`](CONTRIBUTING.md) file are released under the [Apache 2.0 license](LICENSE). This `README.md` file is  licensed under the Creative Commons Attribution 4.0 International License under the terms and conditions set forth in the file [`LICENSE.docs`](LICENSE.docs). You may obtain a duplicate copy of the same license, titled CC BY-SA 4.0, at http://creativecommons.org/licenses/by-sa/4.0/.
+
+[security]: CONTRIBUTING.md#security-issues