1. docker
  2. Commit 449c870afbd21563a6df04445fbb136d3230629b
Browse code

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>

Phil Estes authored on 2017/12/13 05:06:25
Showing 3 changed files
CONTRIBUTING.md
History View file @ 449c870
... ... 
@@ -303,9 +303,8 @@ commit automatically with `git commit -s`.
303 303 
 ### How can I become a maintainer?
304 304
305 305 
 The procedures for adding new maintainers are explained in the
306 
-global [MAINTAINERS](https://github.com/docker/opensource/blob/master/MAINTAINERS)
307 
-file in the [https://github.com/docker/opensource/](https://github.com/docker/opensource/)
308 
-repository.
306 
+[/project/GOVERNANCE.md](/project/GOVERNANCE.md)
307 
+file in this repository.
309 308
310 309 
 Don't forget: being a maintainer is a time investment. Make sure you
311 310 
 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:
371 371 
   used to ping maintainers to review a pull request, a proposal or an
372 372 
   issue.
373 373
374 
+The open source governance for this repository is handled via the [Moby Technical Steering Committee (TSC)](https://github.com/moby/tsc)
375 
+charter. For any concerns with the community process regarding technical contributions,
376 
+please contact the TSC. More information on project governance is available in
377 
+our [project/GOVERNANCE.md](/project/GOVERNANCE.md) document.
378 
+
374 379 
 ### Guideline violations — 3 strikes method
375 380
376 381 
 The point of this section is not to find opportunities to punish people, but we
MAINTAINERS
History View file @ 449c870
... ... 
@@ -1,12 +1,14 @@
1 1 
 # Moby maintainers file
2 2 
 #
3 
-# This file describes who runs the docker/docker project and how.
4 
-# This is a living document - if you see something out of date or missing, speak up!
3 
+# This file describes the maintainer groups within the moby/moby project.
4 
+# More detail on Moby project governance is available in the
5 
+# project/GOVERNANCE.md file found in this repository.
5 6 
 #
6 7 
 # It is structured to be consumable by both humans and programs.
7 8 
 # To extract its contents programmatically, use any TOML-compliant
8 9 
 # parser.
9 10 
 #
11 
+# TODO(estesp): This file should not necessarily depend on docker/opensource
10 12 
 # This file is compiled into the MAINTAINERS file in docker/opensource.
11 13 
 #
12 14 
 [Org]
project/GOVERNANCE.md
History View file @ 449c870
... ... 
@@ -1,17 +1,120 @@
1 
-# Docker Governance Advisory Board Meetings
1 
+# Moby project governance
2 2
3 
-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.
4 
-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.
3 
+Moby projects are governed by the [Moby Technical Steering Committee (TSC)](https://github.com/moby/tsc).
4 
+See the Moby TSC [charter](https://github.com/moby/tsc/blob/master/README.md) for
5 
+further information on the role of the TSC and procedures for escalation
6 
+of technical issues or concerns.
5 7
6 
-The materials from the first Docker Governance Advisory Board meeting, held on October 28, 2014, are available at
7 
-[Google Docs Folder](https://goo.gl/Alfj8r)
8 
+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
9 
+issue that you feel requires escalation.
8 10
9 
-These include:
11 
+## Project maintainers
10 12
11 
-* First Meeting Notes
12 
-* DGAB Charter
13 
-* Presentation 1: Introductory Presentation, including State of The Project
14 
-* Presentation 2: Overall Contribution Structure/Docker Project Core Proposal
15 
-* Presentation 3: Long Term Roadmap/Statement of Direction
16 
-
13 
+The current maintainers of the moby/moby repository are listed in the
14 
+[MAINTAINERS](/MAINTAINERS) file.
17 15
16 
+There are different types of maintainers, with different responsibilities, but
17 
+all maintainers have 3 things in common:
18 
+
19 
+ 1. They share responsibility in the project's success.
20 
+ 2. They have made a long-term, recurring time investment to improve the project.
21 
+ 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun.
22 
+
23 
+Maintainers are often under-appreciated, because their work is less visible.
24 
+It's easy to recognize a really cool and technically advanced feature. It's harder
25 
+to appreciate the absence of bugs, the slow but steady improvement in stability,
26 
+or the reliability of a release process. But those things distinguish a good
27 
+project from a great one.
28 
+
29 
+### Adding maintainers
30 
+
31 
+Maintainers are first and foremost contributors who have shown their
32 
+commitment to the long term success of a project. Contributors who want to
33 
+become maintainers first demonstrate commitment to the project by contributing
34 
+code, reviewing others' work, and triaging issues on a regular basis for at
35 
+least three months.
36 
+
37 
+The contributions alone don't make you a maintainer. You need to earn the
38 
+trust of the current maintainers and other project contributors, that your
39 
+decisions and actions are in the best interest of the project.
40 
+
41 
+Periodically, the existing maintainers curate a list of contributors who have
42 
+shown regular activity on the project over the prior months. From this
43 
+list, maintainer candidates are selected and proposed on the maintainers
44 
+mailing list.
45 
+
46 
+After a candidate is announced on the maintainers mailing list, the
47 
+existing maintainers discuss the candidate over the next 5 business days,
48 
+provide feedback, and vote. At least 66% of the current maintainers must
49 
+vote in the affirmative.
50 
+
51 
+If a candidate is approved, a maintainer contacts the candidate to
52 
+invite them to open a pull request that adds the contributor to
53 
+the MAINTAINERS file. The candidate becomes a maintainer once the pull
54 
+request is merged.
55 
+
56 
+### Removing maintainers
57 
+
58 
+Maintainers can be removed from the project, either at their own request
59 
+or due to [project inactivity](#inactive-maintainer-policy).
60 
+
61 
+#### How to step down
62 
+
63 
+Life priorities, interests, and passions can change. If you're a maintainer but
64 
+feel you must remove yourself from the list, inform other maintainers that you
65 
+intend to step down, and if possible, help find someone to pick up your work.
66 
+At the very least, ensure your work can be continued where you left off.
67 
+
68 
+After you've informed other maintainers, create a pull request to remove
69 
+yourself from the MAINTAINERS file.
70 
+
71 
+#### Inactive maintainer policy
72 
+
73 
+An existing maintainer can be removed if they do not show significant activity
74 
+on the project. Periodically, the maintainers review the list of maintainers
75 
+and their activity over the last three months.
76 
+
77 
+If a maintainer has shown insufficient activity over this period, a project
78 
+representative will contact the maintainer to ask if they want to continue
79 
+being a maintainer. If the maintainer decides to step down as a maintainer,
80 
+they open a pull request to be removed from the MAINTAINERS file.
81 
+
82 
+If the maintainer wants to continue in this role, but is unable to perform the
83 
+required duties, they can be removed with a vote by at least 66% of the current
84 
+maintainers. The maintainer under discussion will not be allowed to vote. An
85 
+e-mail is sent to the mailing list, inviting maintainers of the project to
86 
+vote. The voting period is five business days. Issues related to a maintainer's
87 
+performance should be discussed with them among the other maintainers so that
88 
+they are not surprised by a pull request removing them. This discussion should
89 
+be handled objectively with no ad hominem attacks.
90 
+
91 
+## Project decision making
92 
+
93 
+Short answer: **Everything is a pull request**.
94 
+
95 
+The Moby core engine project is an open-source project with an open design
96 
+philosophy. This means that the repository is the source of truth for **every**
97 
+aspect of the project, including its philosophy, design, road map, and APIs.
98 
+*If it's part of the project, it's in the repo. If it's in the repo, it's part
99 
+of the project.*
100 
+
101 
+As a result, each decision can be expressed as a change to the repository. An
102 
+implementation change is expressed as a change to the source code. An API
103 
+change is a change to the API specification. A philosophy change is a change
104 
+to the philosophy manifesto, and so on.
105 
+
106 
+All decisions affecting the moby/moby repository, both big and small, follow
107 
+the same steps:
108 
+
109 
+ * **Step 1**: Open a pull request. Anyone can do this.
110 
+
111 
+ * **Step 2**: Discuss the pull request. Anyone can do this.
112 
+
113 
+ * **Step 3**: Maintainers merge, close or reject the pull request.
114 
+
115 
+Pull requests are reviewed by the current maintainers of the moby/moby
116 
+repository. Weekly meetings are organized to are organized to synchronously
117 
+discuss tricky PRs, as well as design and architecture decisions.. When
118 
+technical agreement cannot be reached among the maintainers of the project,
119 
+escalation or concerns can be raised by opening an issue to be handled
120 
+by the [Moby Technical Steering Committee](https://github.com/moby/tsc).