diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7abbd2b..4e104bf 100644 --- 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,12 +48,11 @@ 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 @@ -34,12 +60,7 @@ 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 new file mode 100644 index 0000000..9bee195 --- /dev/null +++ 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 (@RandomJDeveloperExample) +A. U. Thor (@AUThorExample) + +[1]: https://github.com/opencontainers/ diff --git a/MAINTAINERS_GUIDE.md b/MAINTAINERS_GUIDE.md index 8f6f129..cbd121d 100644 --- 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 index 2a80b08..a8187da 100644 --- 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)