Remove BDFL sections
@@ -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"
