From e36c1066fc23efe629032c663317ddb30f93847a Mon Sep 17 00:00:00 2001 From: Michael Crosby Date: Wed, 4 Oct 2017 13:45:41 -0400 Subject: [PATCH] Remove BDFL sections Signed-off-by: Michael Crosby --- MAINTAINERS | 44 ++++---------------------------------------- 1 file changed, 4 insertions(+), 40 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 64c7ea1eb..9328b054f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -50,10 +50,9 @@ 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 +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. The BDFL's vote is mandatory. +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 @@ -108,43 +107,12 @@ 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 +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] - - 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] @@ -214,10 +182,6 @@ made through a pull request. # Current project roles [Roles] - [Roles.bdfl] - - person = "shykes" - [Roles."Chief Architect"] person = "crosbymichael"