Compare commits
1 commit
master
...
governance
Author | SHA1 | Date | |
---|---|---|---|
bba09af70e |
1 changed files with 43 additions and 36 deletions
79
MAINTAINERS
79
MAINTAINERS
|
@ -46,14 +46,15 @@ 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.
|
||||
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.
|
||||
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
|
||||
|
@ -91,43 +92,40 @@ 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.
|
||||
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.bdfl]
|
||||
[Rules.ancients]
|
||||
|
||||
title = "The Benevolent dictator for life (BDFL)"
|
||||
title = "Council of Ancients"
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
BDFL daily routine:
|
||||
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.
|
||||
|
||||
* 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]
|
||||
|
@ -197,9 +195,18 @@ made through a pull request.
|
|||
# Current project roles
|
||||
[Roles]
|
||||
|
||||
[Roles.bdfl]
|
||||
[Roles.ancients]
|
||||
|
||||
person = "shykes"
|
||||
people = [
|
||||
"crosbymichael",
|
||||
"dqminh",
|
||||
"dmcgowan",
|
||||
"estesp",
|
||||
"hqhq",
|
||||
"jhowardmsft",
|
||||
"mlaventure",
|
||||
"stevvooe",
|
||||
]
|
||||
|
||||
[Roles."Chief Architect"]
|
||||
|
||||
|
|
Loading…
Reference in a new issue