Remove BDFL sections

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This commit is contained in:
Michael Crosby 2017-10-04 13:45:41 -04:00
parent 732b1560b4
commit e36c1066fc

View File

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