|
@@ -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).
|
Vincent Demeester