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>
This commit is contained in:
Phil Estes
parent
1082aa759e
commit
449c870afb
3 changed files with 126 additions and 17 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
Loading…
Reference in a new issue