4f2b443a27
This rewrites the Go imports after switching to the new github org. Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
283 lines
9.4 KiB
Text
283 lines
9.4 KiB
Text
# containerd project maintainers file
|
|
#
|
|
# This file describes who runs the containerd project and how.
|
|
# This is a living document - if you see something out of date or missing,
|
|
# speak up!
|
|
#
|
|
# It is structured to be consumable by both humans and programs.
|
|
# To extract its contents programmatically, use any TOML-compliant
|
|
# parser.
|
|
|
|
[Rules]
|
|
|
|
[Rules.maintainers]
|
|
|
|
title = "What is a maintainer?"
|
|
|
|
text = """
|
|
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 harder to appreciate.
|
|
It's easy to appreciate 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.
|
|
"""
|
|
|
|
[Rules.adding-maintainers]
|
|
|
|
title = "How are maintainers added?"
|
|
|
|
text = """
|
|
Maintainers are first and foremost contributors that have shown they are
|
|
committed to the long term success of a project. Contributors wanting to become
|
|
maintainers are expected to be deeply involved in contributing code, pull
|
|
request review, and triage of issues in the project for more than three months.
|
|
|
|
Just contributing does not make you a maintainer, it is about building trust
|
|
with the current maintainers of the project and being a person that they can
|
|
depend on and trust to make decisions in the best interest of the project.
|
|
|
|
Periodically, the existing maintainers curate a list of contributors that 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 has been announced on the maintainers mailing list, the
|
|
existing maintainers are given five business days to discuss the candidate,
|
|
raise objections and cast their vote. Candidates must be approved by the BDFL
|
|
and at least 66% of the current maintainers by adding their vote on the mailing
|
|
list. Only maintainers of the repository that the candidate is proposed for are
|
|
allowed to vote. The BDFL's vote is mandatory.
|
|
|
|
If a candidate is approved, a maintainer will contact the candidate to invite
|
|
the candidate to open a pull request that adds the contributor to the
|
|
MAINTAINERS file. The candidate becomes a maintainer once the pull request is
|
|
merged.
|
|
"""
|
|
|
|
[Rules.stepping-down-policy]
|
|
|
|
title = "Stepping down policy"
|
|
|
|
text = """
|
|
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.
|
|
"""
|
|
|
|
[Rules.inactive-maintainers]
|
|
|
|
title = "Removal of inactive maintainers"
|
|
|
|
text = """
|
|
Similar to the procedure for adding new maintainers, existing maintainers can
|
|
be removed from the list 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 neutral
|
|
person 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 remain a maintainer, but is unable to perform the
|
|
required duties they can be removed with a vote by the BDFL and at least 66% of
|
|
the current maintainers. The BDFL's vote is mandatory. 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.
|
|
"""
|
|
|
|
[Rules.bdfl]
|
|
|
|
title = "The Benevolent dictator for life (BDFL)"
|
|
|
|
text = """
|
|
containerd follows the timeless, highly efficient and totally unfair system
|
|
known as [Benevolent dictator for
|
|
life](https://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with yours
|
|
truly, Solomon Hykes, in the role of BDFL. This means that all decisions are
|
|
made, by default, by Solomon. Since making every decision himself would be
|
|
highly un-scalable, in practice decisions are spread across multiple
|
|
maintainers.
|
|
|
|
Ideally, the BDFL role is like the Queen of England: awesome crown, but not an
|
|
actual operational role day-to-day. The real job of a BDFL is to NEVER GO AWAY.
|
|
Every other rule can change, perhaps drastically so, but the BDFL will always be
|
|
there, preserving the philosophy and principles of the project, and keeping
|
|
ultimate authority over its fate. This gives us great flexibility in
|
|
experimenting with various governance models, knowing that we can always press
|
|
the "reset" button without fear of fragmentation or deadlock. See the US
|
|
congress for a counter-example.
|
|
|
|
BDFL daily routine:
|
|
|
|
* Is the project governance stuck in a deadlock or irreversibly fragmented?
|
|
* If yes: refactor the project governance
|
|
* Are there issues or conflicts escalated by maintainers?
|
|
* If yes: resolve them
|
|
* Go back to polishing that crown.
|
|
"""
|
|
|
|
[Rules.decisions]
|
|
|
|
title = "How are decisions made?"
|
|
|
|
text = """
|
|
Short answer: EVERYTHING IS A PULL REQUEST.
|
|
|
|
containerd 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, all decisions can be expressed as changes to the 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 containerd, big and small, follow the same 3 steps:
|
|
|
|
* Step 1: Open a pull request. Anyone can do this.
|
|
|
|
* Step 2: Discuss the pull request. Anyone can do this.
|
|
|
|
* Step 3: Merge or refuse the pull request. Who does this depends on the nature
|
|
of the pull request and which areas of the project it affects.
|
|
"""
|
|
|
|
[Rules.DCO]
|
|
|
|
title = "Helping contributors with the DCO"
|
|
|
|
text = """
|
|
The [DCO or `Sign your work`](
|
|
https://github.com/containerd/containerd/blob/master/CONTRIBUTING.md#sign-your-work)
|
|
requirement is not intended as a roadblock or speed bump.
|
|
|
|
Some containerd contributors are not as familiar with `git`, or have used a web
|
|
based editor, and thus asking them to `git commit --amend -s` is not the best
|
|
way forward.
|
|
|
|
In this case, maintainers can update the commits based on clause (c) of the DCO.
|
|
The most trivial way for a contributor to allow the maintainer to do this, is to
|
|
add a DCO signature in a pull requests's comment, or a maintainer can simply
|
|
note that the change is sufficiently trivial that it does not substantially
|
|
change the existing contribution - i.e., a spelling change.
|
|
|
|
When you add someone's DCO, please also add your own to keep a log.
|
|
"""
|
|
|
|
[Rules."no direct push"]
|
|
|
|
title = "I'm a maintainer. Should I make pull requests too?"
|
|
|
|
text = """
|
|
Yes. Nobody should ever push to master directly. All changes should be
|
|
made through a pull request.
|
|
"""
|
|
|
|
[Rules.meta]
|
|
|
|
title = "How is this process changed?"
|
|
|
|
text = "Just like everything else: by making a pull request :)"
|
|
|
|
# Current project roles
|
|
[Roles]
|
|
|
|
[Roles.bdfl]
|
|
|
|
person = "shykes"
|
|
|
|
[Roles."Chief Architect"]
|
|
|
|
person = "crosbymichael"
|
|
|
|
text = """
|
|
The chief architect is responsible for the overall integrity of the technical
|
|
architecture across all subsystems, and the consistency of APIs and UI.
|
|
|
|
Changes to UI, public APIs and overall architecture must be approved by the
|
|
chief architect.
|
|
"""
|
|
|
|
[Roles."Chief Maintainer"]
|
|
|
|
person = "crosbymichael"
|
|
|
|
text = """
|
|
The chief maintainer is responsible for all aspects of quality for the project
|
|
including code reviews, usability, stability, security, performance, etc. The
|
|
most important function of the chief maintainer is to lead by example. On the
|
|
first day of a new maintainer, the best advice should be "follow the C.M.'s
|
|
example and you'll be fine".
|
|
"""
|
|
|
|
# Current project organization
|
|
[Org]
|
|
|
|
[Org.Maintainers]
|
|
people = [
|
|
"crosbymichael",
|
|
"dqminh",
|
|
"dmcgowan",
|
|
"estesp",
|
|
"hqhq",
|
|
"jhowardmsft",
|
|
"mlaventure",
|
|
"stevvooe",
|
|
]
|
|
|
|
[People]
|
|
|
|
[People.crosbymichael]
|
|
Name = "Michael Crosby"
|
|
Email = "crosbymichael@gmail.com"
|
|
GitHub = "crosbymichael"
|
|
|
|
[People.dqminh]
|
|
Name = "Daniel, Dao Quang Minh"
|
|
Email = "dqminh89@gmail.com"
|
|
GitHub = "dqminh"
|
|
|
|
[people.dmcgowan]
|
|
Name = "Derek McGowan"
|
|
Email = "derek@mcgstyle.net"
|
|
GitHub = "dmcgowan"
|
|
|
|
[People.estesp]
|
|
Name = "Phil Estes"
|
|
Email = "estesp@linux.vnet.ibm.com"
|
|
GitHub = "estesp"
|
|
|
|
[People.hqhq]
|
|
Name = "Qiang Huang"
|
|
Email = "h.huangqiang@huawei.com"
|
|
GitHub = "hqhq"
|
|
|
|
[People.jhowardmsft]
|
|
Name = "John Howard"
|
|
Email = "jhoward@microsoft.com"
|
|
GitHub = "jhowardmsft"
|
|
|
|
[People.mlaventure]
|
|
Name = "Kenfe-Mickaël Laventure"
|
|
Email = "mickael.laventure@docker.com"
|
|
GitHub = "mlaventure"
|
|
|
|
[People.stevvooe]
|
|
Name = "Stephen Day"
|
|
Email = "stephen.day@docker.com"
|
|
GitHub = "stevvooe"
|