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>

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
+raise objections and cast their vote. Candidates must be approved by at least
-and at least 66% of the current maintainers by adding their vote on the mailing
+66% of the current maintainers by adding their vote on the mailing list. Only
-list. Only maintainers of the repository that the candidate is proposed for are
+maintainers of the repository that the candidate is proposed for are allowed to
-allowed to vote. The BDFL's vote is mandatory.
+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
+required duties they can be removed with a vote of at least 66% of the current
-the current maintainers. The BDFL's vote is mandatory. An e-mail is sent to the
+maintainers. An e-mail is sent to the mailing list, inviting maintainers of the
-mailing list, inviting maintainers of the project to vote. The voting period is
+project to vote. The voting period is five business days. Issues related to a
-five business days. Issues related to a maintainer's performance should be
+maintainer's performance should be discussed with them among the other
-discussed with them among the other maintainers so that they are not surprised
+maintainers so that they are not surprised by a pull request removing them.
-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
+containerd relies on the experience of the collective community, and most
-known as [Benevolent dictator for
+responsibility is spread across the maintainers. If a dispute arises that
-life](https://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with yours
+cannot be settled by consensus of the maintainers, then the Council of Ancients
-truly, Solomon Hykes, in the role of BDFL. This means that all decisions are
+can convene to resolve the issue to ensure the project does not get blocked. 
-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
+The intention of this collective decision is to find an acceptable resolution,
-actual operational role day-to-day. The real job of a BDFL is to NEVER GO AWAY.
+one that can be supported, even if it is not unanimously agreed upon or the
-Every other rule can change, perhaps drastically so, but the BDFL will always be
+"favourite" of each individual. Proposals before the Council should be framed
-there, preserving the philosophy and principles of the project, and keeping
+as "is this something you can live with?"; they do not imply agreement, but
-ultimate authority over its fate. This gives us great flexibility in
+rather sufficient consent such that the life of the project stays healthy.
-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:
+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"]