Remove BDFL sections
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This commit is contained in:
		
							
								
								
									
										44
									
								
								MAINTAINERS
									
									
									
									
									
								
							
							
						
						
									
										44
									
								
								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 | After a candidate has been announced on the maintainers mailing list, the | ||||||
| existing maintainers are given five business days to discuss the candidate, | 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 66% of the current maintainers by adding their vote on the mailing | ||||||
| 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 | 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 | 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 | 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. | 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 | 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 maintainers. The BDFL's vote is mandatory. An e-mail is sent to the | the current maintainers. An e-mail is sent to the | ||||||
| mailing list, inviting maintainers of the project to vote. The voting period is | 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 | 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 | discussed with them among the other maintainers so that they are not surprised | ||||||
| by a pull request removing them. | 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] | 	[Rules.decisions] | ||||||
| @@ -214,10 +182,6 @@ made through a pull request. | |||||||
| # Current project roles | # Current project roles | ||||||
| [Roles] | [Roles] | ||||||
|  |  | ||||||
| 	[Roles.bdfl] |  | ||||||
|  |  | ||||||
| 	person = "shykes" |  | ||||||
|  |  | ||||||
| 	[Roles."Chief Architect"] | 	[Roles."Chief Architect"] | ||||||
|  |  | ||||||
| 	person = "crosbymichael" | 	person = "crosbymichael" | ||||||
|   | |||||||
		Reference in New Issue
	
	Block a user
	 Michael Crosby
					Michael Crosby