diff --git a/pep-8012.rst b/pep-8012.rst index da2b2c757..3eade8c4e 100644 --- a/pep-8012.rst +++ b/pep-8012.rst @@ -1,28 +1,427 @@ PEP: 8012 Title: The Community Governance Model -Author: Barry Warsaw +Author: Łukasz Langa Status: Active Type: Informational Content-Type: text/x-rst -Created: 2018-08-24 - - -.. note:: This is just a placeholder until the actual governance PEPs are - written. It is possible that the title, content, model proposed, - and authorship will change once the PEP is actually written. +Created: 2018-10-03 Abstract ======== -This PEP proposes a new model of Python governance based on consensus and -voting by the Python community, without the role of a centralized singular -leader or a governing council. It describes how, when, and why votes are -conducted for decisions affecting the Python language. It also describes the -criteria for voting eligibility. +This PEP proposes a new model of Python governance based on consensus +and voting by the Python community, without the role of a centralized +singular leader or a governing council. It describes how, when, and +why votes are conducted for decisions affecting the Python language. +It also describes the criteria for voting eligibility. -Should this model be adopted, it will be codified in PEP 13 along with the -names of all officeholders described in this PEP. +Should this model be adopted, it will be codified in PEP 13. + +This model can be affectionately called "The Least Worst Governance +Model" by its property that while far from ideal, it's still the most +robust one compared to the others. Since avoiding issues inherent to +the other models is a paramount feature of the Community Governance +Model, we start the discussion a bit unusually: by rejecting the +other models. + +Rejected Ideas +============== + +Let's have another BDFL +----------------------- + +This seems like a very attractive idea because it's a model we know. +One Dictator to rule us all. + +There is no other Guido +~~~~~~~~~~~~~~~~~~~~~~~ + +There is no other single person with the unique skillset of Guido van +Rossum. Such person would have to combine the following characteristics +to be a successful leader of the project: + +* cohesive long-term vision for the project; + +* deep technical understanding of the runtime, the standard library, + and the wider third-party library context; + +* ability to resolve contentious issues in ways acceptable to all + parties involved; + +* continuous time involvement over periods of years to keep the + above-mentioned traits over time and exercise them. + +Malevolent Dictator For Life +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +What if we got somebody who is not as well suited for the position as +our first Dictator? There are possible scenarios in which this could +lead to severe consequences. + +The Dictator could gather insufficient trust due to missing technical +depth, a "close" election, inconsistent vision, poor ability to deal +with conflict or burnout, and so on. Given a controversial decision +decided by the Dictator in a specific way, a Dictator with +insufficient trust may cause a split within the project. + +The Dictator setup invites lobbying concentrated on a single person. +Unless that person is immune to leverage due to wealth, health, and +a stable life situation, this poses risk of malicious actors steering +the project from behind the curtain. + +Finally, the Dictator coming from a particular part of the community +may put more weight on the needs and interests of that particular part +of the user base, alienating others. + +We don't actually need a Dictator +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The irony of the Dictator model is that it requires an election. Better +yet, we need an election to even decide on which governance model to +use. + +If we are already able solve two problems of this gravity via the +community process, why not keep using it for all subsequent decisions? + +The warm and fuzzy feeling of a vague proposal +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +One last thing worth mentioning is that when a BDFL model is suggested, +it's easy to bypass the criticism above by not mentioning *who* the BDFL +should be. That way the hopeful reader can project their best +expectations and wants onto the abstract BDFL, making the idea appear +more attractive. This is a mistake. + +Without naming the BDFL in the model proposal we are not talking about +a concrete model. We can avoid asking and answering the hard questions. +We can imagine our best-case scenario, a candidate we'd like to serve +the role. + +Omitting a name also puts the Community Model at an unfair disadvantage. +We already know the good, the bad, and the ugly of our core developer +group. It's no platonic ideal, no perfect sphere with no friction. In +fact, we expect there to be a fair amount of friction and imperfections. + +Thus, to fairly assess the BDFL model proposal, dear reader, you +should imagine the worst possible person within our team as that +BDFL. A concrete human being. Imagine it's me. + + +Let's have a Council +-------------------- + +This group of people roughly sharing the responsibilities of a Dictator +can also be called a Triumvirate, a Quorum, Elders, Steering Committee, +and so on. + +Like a Dictator, only worse +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This model favors a small group, between three to five people. +That way it shares most of the criticism with the Dictator model, +amplified. Having not one but, say, three people in position of power +dillutes responsibility while still providing high risk of lobbying, +insufficient trust, or alienating parts of the community. + +Additionally, having multiple people share the responsibility of +governance creates ample opportunity for internal conflict, +inconsistent long-term vision of the project, and multiplies the +required continuous time involvement by its members (it's no Quorum +if they can't "reach quorum" due to other time commitments). + +Just like with a frictionless spherical BDFL, reject ideas of +Councils without considering how would it work for you if that +Council consisted of three people you find inadequate for the role. +Imagine if I had two friends. + +Most importantly, just like with a Dictator, we don't need a Council. +By the time we had one, we would have already had two successful +elections. Why not keep voting? + + +Motivation +========== + +Now that we rejected all that we should, let's talk why we even need +a governance model on top of a loosely defined group of committers. + +We want to block single committers from making wide-reaching changes +that impact the future of the language. Coherent vision and backwards +compatibility are important in any programming language, but they are +doubly important for Python which is very dynamic (e.g. has very complex +backwards compatibility implications). Moreover, Python is used by a +diverse group of users, from school children through scientists to +corporations with multi-million line codebases. We want to include +all our varied audiences. + +We want to avoid stagnation. Python is a mature project but it needs +to keep evolving to stay relevant, both the runtime and the programming +language. To do that, people interested in improving a particular part +of the project should be able to do so without needless friction. +But for substantial changes, we want some friction to ensure they are +wise changes. + + +Rationale +========= + +The Community Model is the most inclusive model. No single person or +a small group of people is in a distiguished position of power over +others. Contributors in this model are self-selecting. + +This model ensures no user group is put at a disadvantage due to the +interests of a single person or a small group of people. + +This model works. There is a number of large open-source projects run +this way (two of which, Rust and Django, are described in PEP 8002). +ECMAScript and C++ are similarly developed. + + +Specification +============= + +Key people and their functions +------------------------------ + +The core team +~~~~~~~~~~~~~ + +The Python project is developed by a team of core developers. +While membership is determined by presence in the "Python core" team +in the "python" organization on GitHub, contribution takes many forms: + +* committing changes to the repository; +* reviewing pull requests by others; +* triaging bug reports on the issue tracker; +* discussing on official Python communication channels. + +Some contributors are dormant, in other words they did not contribute +to the last two releases of CPython. Any dormant contributor can at +any time resume contribution. + +Experts +~~~~~~~ + +The Python Developer's Guide lists a number of interest areas along with +names of core developers who are recognized as experts in the given +area. An expert or a sub-team of experts has the following +responsibilities: + +* responding to issues on the bug tracker triaged to the given interest + area on a timely basis; +* reviewing pull requests identified as belonging to the given interest + area on a timely basis; +* overviewing cohesive design in the evolution of the given interest + area. + +A core developer can assign and unassign themselves at will to +a given interest area. Existing experts listed for the given interest +area must be made aware of this change and have to unanimously agree to +it. + +If a given interest area lists multiple experts, they form a sub-team +within the core team. They are responsible for the given interest area +together. + +A core developer should avoid membership as an expert in too many +interest areas at the same time. This document deliberately doesn't +specify a maximum number, it simply signals that overexertion leads to +burnout and is a risk to the project's ability to function without +a given contributor. + +Moderators +~~~~~~~~~~ + +There is a group of people, some of which are not core developers, +responsible for ensuring that discussions on official communication +channels adhere to the Code of Conduct. They take action in view of +violations. + + +Regular decision process +------------------------ + +Primary work happens through bug tracker issues and pull requests. +Core developers should avoind pushing their changes directly to the cpython +repository, instead relying on pull requests. Approving a pull +request by a core developer allows it to be merged without further +process. + +Notifying relevant experts about a bug tracker issue or a pull request +is important. Reviews from experts in the given interest area are +strongly preferred, especially on pull request approvals. Failure to +do so might end up with the change being reverted by the relevant +expert. + +Experts are not required to listen to the firehose of GitHub and bug +tracker activity at all times. Notifying an expert explicitly during +triage or bug/pull request creation may be necessary to get their +attention. + + +Controversial decision process +------------------------------ + +Substantial changes in a given interest area require a PEP. This +includes: + +* Any semantic or syntactic change to the language. +* Backwards-incompatible changes to the standard library or the C API. +* Additions to the standard library, including substantial new + functionality within an existing library. +* Removing language, standard library, or C API features. + +Failure to get a substantial change through the PEP process might result +with the change being reverted. + +Changes that are bug fixes can be exempt from the PEP requirement. Use +your best judgement. + +PEP, Enhanced +~~~~~~~~~~~~~ + +The PEP process is augmented with the following changes and clarifications +over information already present in PEP 1: + +* PEPs are not merged until the final decision is made on them; they are + open pull requests on GitHub until that moment; + + * to make review easier, all changes to the PEP under review should be + made as separate commits, allowing for granular comparison; + +* a submitted PEP needs to identify the area of interest and relevant + experts as the body that makes the final decision on it; +* if the PEP author is one of the experts of the relevant area of + interest, they must name another person from outside of that interest + area to contribute to the final decision in their place; +* the PEP author is responsible for gathering and integrating feedback + on the PEP using the official communication channels, with the goal of + building consensus; +* all community members must be enabled to give feedback; +* at some point, one of the named experts posts a "summary comment" that + lays out the current state of discussion, especially major points of + disagreement and tradeoffs; at the same time the expert proposes + a "motion for final comment period" (FCP), along with a proposed + disposition to either: + + * accept; + * accept provisionally; + * reject; or + * defer the PEP. + +* to enter the FCP, the PEP must be signed off by all experts of the + relevant area of interest; +* the FCP lasts for fourteen calendar days to allow stakeholders to file + any final objections before a decision is reached. + +Very controversial PEPs +~~~~~~~~~~~~~~~~~~~~~~~ + +If a core contributor feels strongly against a particular PEP, during +its FCP they may raise a motion to reject it by vote. Voting details +are described below in "Voting Mechanics". + +This should be a last resort and thus a rare occurrence. It splits the +core team and is a stressful event for all involved. However, the +experts filing for an FCP for a PEP should have a good sense whether +a motion to reject it by vote is likely. In such case, care should be +taken to avoid prematurely filing for FCP. + +There is no recourse for the opposite situation, i.e. when the +experts want to reject a PEP but others would like it accepted. This +ensures that the relevant experts have the last say on what goes in. +If you really want that change, find a way to convince them. + +Moderators on official communication channels enforce the Code of +Conduct first and foremost, to ensure healthy interaction between all +interested parties. Enforcement can result in a given participant +being excluded from further discussion and thus the decision process. + +Revisiting deferred and rejected PEPs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If a PEP is deferred or rejected, the relevant experts should be +contacted first before another attempt at the same idea is made. +If the experts agree there is substantial evidence to justify +revisiting the idea, a pull request editing the deferred or rejected +PEP can be opened. + +Failure to get proper expert buy-in beforehand will likely result in +immediate rejection of a pull request on a deferred or rejected PEP. + +Other Voting Situations +~~~~~~~~~~~~~~~~~~~~~~~ + +* Nominating a new core developer; +* Removing a core developer from the core team; +* Disbanding the experts team for a given area of interest. + +The latter two are votes of no confidence. Those describe a situation +where a core developer is forcefully removed from the core team or an +experts team is forcefully disbanded. Hopefully those will never have +to be exercised but they are explicitly mentioned to demonstrate how +a disfunctional area of interest can be healed. + +If a core developer is removed by vote from the core team, they lose +the ability to interact with the project. It's up to the Moderators' +discretion to remove their ability to post on the bug tracker and GitHub +or just moderate their future behavior on a case-by-case basis. + +If the experts team for an area of interest is disbanded, other core +developers can step up to fill the void at will. Members of the +disbanded experts team cannot self-nominate to return. + +Voting Mechanics +---------------- + +Votes take fourteen calendar days. The starting date is taken looking at +the timezone of the person who filed for the motion to vote. The end +date is fourteen days later Anywhere-On-Earth. + +Dormant core developers as defined in "Key people and their functions" +above are not counted towards the totals if they abstain. However, they +can vote if they choose to do so and that way they count as active. +Voting is a form of contribution. + +Voting is done by a commit to a private repository in the "python" +organization on GitHub. The repository is archived and publicized after +the voting period is over. The repository's name should start with +"vote-". + +Changes to one's vote during the voting period is allowed. Peeking +at other developers' cast votes during the time of the vote is possible. + +Every situation requires a different vote percentage: + +* PEP rejection by vote requires over 1/3rd of the non-dormant core + developer population to explicitly vote to reject. Note that if + more than 1/3rd of core developers decide against a PEP, this means + there exists no super-majority of core developers who are in favor + of the change. This strongly suggests the change should not be made + in the shape described by the PEP. +* New core developer nomination requires there to be no votes cast + against it. +* Votes of no confidence require a super-majority of at least 2/3rds of + the non-dormant core developer population to explicitly vote in favor + of the motion. + + +Omissions +========= + +This document deliberately omits listing possible areas of interest +within the project. + + +Acknowledgements +================ + +Thank you to the authors of PEP 8002 which was a helpful resource in +shaping this document. + +Thank you to Alex Crichton and the Rust team for a governance model +that was a major inspiration for this document. Copyright