containerd/MAINTAINERS

# 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 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.

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 of at least 66% of the current
maintainers. 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.ancients]

	title = "Council of Ancients"

	text = """
containerd relies on the experience of the collective community, and most
responsibility is spread across the maintainers. If a dispute arises that
cannot be settled by consensus of the maintainers, then the Council of Ancients
can convene to resolve the issue to ensure the project does not get blocked. 

The intention of this collective decision is to find an acceptable resolution,
one that can be supported, even if it is not unanimously agreed upon or the
"favourite" of each individual. Proposals before the Council should be framed
as "is this something you can live with?"; they do not imply agreement, but
rather sufficient consent such that the life of the project stays healthy.

The Council is a specific meeting of those involved in the project (tenured
maintainers and/or top contributors), rather than an elected collection of
members that would require education on a topic in order to make an informed
decision.

The Chief Maintainer should seek to mediate any topic before needing to call
for a decision from the Council of Ancients. When a topic is raised with the 
Council, it should hold a meeting (i.e. video chat, IRC, audio conference, etc) 
where a quorum is present and can decide two-thirds majority on the specific 
issue(s) raised.

"""

	[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.ancients]

	people = [
		"crosbymichael",
		"dqminh",
		"dmcgowan",
		"estesp",
		"hqhq",
		"jhowardmsft",
		"mlaventure",
		"stevvooe",
	]

	[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"