diff options
author | Phil Estes <estesp@linux.vnet.ibm.com> | 2017-12-12 15:06:25 -0500 |
---|---|---|
committer | Phil Estes <estesp@linux.vnet.ibm.com> | 2017-12-13 16:51:46 -0500 |
commit | 449c870afbd21563a6df04445fbb136d3230629b (patch) | |
tree | d35358bc7947884b1fc3f44eac76f4c9f689e549 | |
parent | 1082aa759ebd73971a92a48c6c7b253cf1605ae7 (diff) | |
download | docker-449c870afbd21563a6df04445fbb136d3230629b.tar.gz |
Add Moby TSC references/governance details
Also added back some of the maintainer processes that were in
MAINTAINERS but moved to docker/opensource repo. I believe this
project's governance should be disconnected from docker/opensource as
project's remaining under docker/opensource will not use the Moby TSC.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
-rw-r--r-- | CONTRIBUTING.md | 10 | ||||
-rw-r--r-- | MAINTAINERS | 6 | ||||
-rw-r--r-- | project/GOVERNANCE.md | 127 |
3 files changed, 126 insertions, 17 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a38f54d693..519e238cc7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -303,9 +303,8 @@ commit automatically with `git commit -s`. ### How can I become a maintainer? The procedures for adding new maintainers are explained in the -global [MAINTAINERS](https://github.com/docker/opensource/blob/master/MAINTAINERS) -file in the [https://github.com/docker/opensource/](https://github.com/docker/opensource/) -repository. +[/project/GOVERNANCE.md](/project/GOVERNANCE.md) +file in this repository. Don't forget: being a maintainer is a time investment. Make sure you will have time to make yourself available. You don't have to be a @@ -371,6 +370,11 @@ guidelines for the community as a whole: used to ping maintainers to review a pull request, a proposal or an issue. +The open source governance for this repository is handled via the [Moby Technical Steering Committee (TSC)](https://github.com/moby/tsc) +charter. For any concerns with the community process regarding technical contributions, +please contact the TSC. More information on project governance is available in +our [project/GOVERNANCE.md](/project/GOVERNANCE.md) document. + ### Guideline violations — 3 strikes method The point of this section is not to find opportunities to punish people, but we diff --git a/MAINTAINERS b/MAINTAINERS index a8966873b4..4c831d7832 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1,12 +1,14 @@ # Moby maintainers file # -# This file describes who runs the docker/docker project and how. -# This is a living document - if you see something out of date or missing, speak up! +# This file describes the maintainer groups within the moby/moby project. +# More detail on Moby project governance is available in the +# project/GOVERNANCE.md file found in this repository. # # It is structured to be consumable by both humans and programs. # To extract its contents programmatically, use any TOML-compliant # parser. # +# TODO(estesp): This file should not necessarily depend on docker/opensource # This file is compiled into the MAINTAINERS file in docker/opensource. # [Org] diff --git a/project/GOVERNANCE.md b/project/GOVERNANCE.md index 6ae7baf743..4b52989a64 100644 --- a/project/GOVERNANCE.md +++ b/project/GOVERNANCE.md @@ -1,17 +1,120 @@ -# Docker Governance Advisory Board Meetings +# Moby project governance -In the spirit of openness, Docker created a Governance Advisory Board, and committed to make all materials and notes from the meetings of this group public. -All output from the meetings should be considered proposals only, and are subject to the review and approval of the community and the project leadership. +Moby projects are governed by the [Moby Technical Steering Committee (TSC)](https://github.com/moby/tsc). +See the Moby TSC [charter](https://github.com/moby/tsc/blob/master/README.md) for +further information on the role of the TSC and procedures for escalation +of technical issues or concerns. -The materials from the first Docker Governance Advisory Board meeting, held on October 28, 2014, are available at -[Google Docs Folder](https://goo.gl/Alfj8r) +Contact [any Moby TSC member](https://github.com/moby/tsc/blob/master/MEMBERS.md) with your questions/concerns about the governance or a specific technical +issue that you feel requires escalation. -These include: +## Project maintainers -* First Meeting Notes -* DGAB Charter -* Presentation 1: Introductory Presentation, including State of The Project -* Presentation 2: Overall Contribution Structure/Docker Project Core Proposal -* Presentation 3: Long Term Roadmap/Statement of Direction - +The current maintainers of the moby/moby repository are listed in the +[MAINTAINERS](/MAINTAINERS) file. +There are different types of maintainers, with different responsibilities, but +all maintainers have 3 things in common: + + 1. They share responsibility in the project's success. + 2. They have made a long-term, recurring time investment to improve the project. + 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. + +Maintainers are often under-appreciated, because their work is less visible. +It's easy to recognize a really cool and technically advanced feature. It's harder +to appreciate the absence of bugs, the slow but steady improvement in stability, +or the reliability of a release process. But those things distinguish a good +project from a great one. + +### Adding maintainers + +Maintainers are first and foremost contributors who have shown their +commitment to the long term success of a project. Contributors who want to +become maintainers first demonstrate commitment to the project by contributing +code, reviewing others' work, and triaging issues on a regular basis for at +least three months. + +The contributions alone don't make you a maintainer. You need to earn the +trust of the current maintainers and other project contributors, that your +decisions and actions are in the best interest of the project. + +Periodically, the existing maintainers curate a list of contributors who have +shown regular activity on the project over the prior months. From this +list, maintainer candidates are selected and proposed on the maintainers +mailing list. + +After a candidate is announced on the maintainers mailing list, the +existing maintainers discuss the candidate over the next 5 business days, +provide feedback, and vote. At least 66% of the current maintainers must +vote in the affirmative. + +If a candidate is approved, a maintainer contacts the candidate to +invite them to open a pull request that adds the contributor to +the MAINTAINERS file. The candidate becomes a maintainer once the pull +request is merged. + +### Removing maintainers + +Maintainers can be removed from the project, either at their own request +or due to [project inactivity](#inactive-maintainer-policy). + +#### How to step down + +Life priorities, interests, and passions can change. If you're a maintainer but +feel you must remove yourself from the list, inform other maintainers that you +intend to step down, and if possible, help find someone to pick up your work. +At the very least, ensure your work can be continued where you left off. + +After you've informed other maintainers, create a pull request to remove +yourself from the MAINTAINERS file. + +#### Inactive maintainer policy + +An existing maintainer can be removed if they do not show significant activity +on the project. Periodically, the maintainers review the list of maintainers +and their activity over the last three months. + +If a maintainer has shown insufficient activity over this period, a project +representative will contact the maintainer to ask if they want to continue +being a maintainer. If the maintainer decides to step down as a maintainer, +they open a pull request to be removed from the MAINTAINERS file. + +If the maintainer wants to continue in this role, but is unable to perform the +required duties, they can be removed with a vote by at least 66% of the current +maintainers. The maintainer under discussion will not be allowed to vote. An +e-mail is sent to the mailing list, inviting maintainers of the project to +vote. The voting period is five 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. This discussion should +be handled objectively with no ad hominem attacks. + +## Project decision making + +Short answer: **Everything is a pull request**. + +The Moby core engine 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, road map, and APIs. +*If it's part of the project, it's in the repo. If it's in the repo, it's part +of the project.* + +As a result, each decision can be expressed as a change to the repository. An +implementation change is expressed as 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 the moby/moby repository, both big and small, follow +the same steps: + + * **Step 1**: Open a pull request. Anyone can do this. + + * **Step 2**: Discuss the pull request. Anyone can do this. + + * **Step 3**: Maintainers merge, close or reject the pull request. + +Pull requests are reviewed by the current maintainers of the moby/moby +repository. Weekly meetings are organized to are organized to synchronously +discuss tricky PRs, as well as design and architecture decisions.. When +technical agreement cannot be reached among the maintainers of the project, +escalation or concerns can be raised by opening an issue to be handled +by the [Moby Technical Steering Committee](https://github.com/moby/tsc). |