Compare commits

...

1 commit

Author SHA1 Message Date
bba09af70e
MAINTAINERS: replace BDFL with a Council of Ancients
Wording inspired from https://en.wikipedia.org/wiki/Council_of_Ancients

Much of the consensus approach drawn from
https://en.wikipedia.org/wiki/Consensus_decision-making

Some references drawn from
http://co-intelligence.org/I-comparisonRR-CC-DF.html

This proposal comes from having had discussions with a majority of the
current maintains of containerd and modeling a governance based on what
has been found to work for the group. A further motivation is a
deep desire to participate in a project with an expressly fair governance.

Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
2017-04-11 15:21:52 -04:00

View file

@ -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"]