PEP 8012 was rejectedby a core developer votedescribed inPEP 8001 on Monday, December 17, 2018.
PEP 8016 and the governance model it describes were chosen instead.
This PEP proposes a new model of Python governance based on consensusand voting by the Python community. This model relies on workgroups to carryout the governance of the Python language. This governance model works withoutthe role of a centralized singular leader or a governing council.
It describes how, when, and why votes are conducted for decisions affectingthe Python language. It also describes the criteria for voting eligibility.
Should this model be adopted, it will be codified inPEP 13.
This model can be affectionately called “The Least Worst GovernanceModel” by its property that while far from ideal, it’s still the mostrobust one compared to the others. Since avoiding issues inherent tothe other models is a paramount feature of the Community GovernanceModel, we start the discussion a bit unusually: by rejecting theother models.
This seems like a very attractive idea because it’s a model we know.One Dictator to rule us all.
There is no other single person with the unique skillset of Guido vanRossum. Such a person would need to have the technical, communication, andorganizational experience to lead the project successfully. Specifically, theperson would need to:
What if we got somebody who is not as well suited for the position asour first Dictator? There are possible scenarios in which this couldlead to severe consequences.
The Dictator could gather insufficient trust due to missing technicaldepth, a “close” election, inconsistent vision, poor ability to dealwith conflict or burnout, and so on. Given a controversial decisiondecided by the Dictator in a specific way, a Dictator withinsufficient 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, anda stable life situation, this poses risk of malicious actors steeringthe project from behind the curtain.
Finally, the Dictator coming from a particular part of the communitymay put more weight on the needs and interests of that particular partof the user base, alienating others.
The irony of the Dictator model is that it requires an election. Betteryet, we need an election to even decide on which governance model touse.
If we are already able solve two problems of this gravity via thecommunity process, why not keep using it for all subsequent decisions?
One last thing worth mentioning is that when a BDFL model is suggested,it’s easy to bypass the criticism above by not mentioningwho the BDFLshould be. That way the hopeful reader can project their bestexpectations and wants onto the abstract BDFL, making the idea appearmore attractive. This is a mistake.
Without naming the BDFL in the model proposal we are not talking abouta concrete model. We can avoid asking and answering the hard questions.We can imagine our best-case scenario, a candidate we’d like to servethe role.
Omitting a name for the BDFL also puts the Community Model at an unfair disadvantage.We already know the good, the bad, and the ugly of our core developergroup. It’s no platonic ideal, no perfect sphere with no friction. Infact, we expect there to be a fair amount of friction and imperfections.
Thus, to fairly assess the BDFL model proposal, dear reader, youshould imagine the worst possible person within our team as thatBDFL. A concrete human being. Imagine it’s me.
Conclusion While this has been our history, without Guido, this modeldoes not serve the best interests of the language into the future.
This group of people roughly shares the responsibilities of a Dictator. Thegroup can also be called a Triumvirate, a Quorum, Elders, Steering Committee,and so on.
This model favors a small group, between three and 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 powerdilutes responsibility while still providing high risk of lobbying,insufficient trust, or alienating parts of the community.
Additionally, having multiple people share the responsibility ofgovernance creates ample opportunity for internal conflict,inconsistent long-term vision of the project, and multiplies therequired continuous time involvement by its members (it’s no Quorumif they can’t “reach quorum” due to other time commitments).
Just like with a frictionless spherical BDFL, reject ideas ofCouncils without considering how would it work for you if thatCouncil 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 successfulelections. Why not keep voting?
Conclusion This model has similar risks like a Dictator, only worse.
Now that we rejected the basics of other governance models, let’s talk why weeven need a governance model on top of a loosely defined group of committers.
Stability and Reliability We want to prevent single committers frommaking wide-reaching changes that impact the future of the language or itsusability. Coherent vision and backwards compatibility are important in anyprogramming language, but they are doubly important for Python which is verydynamic (e.g. has very complex backwards compatibility implications).
Diverse Uses of Python Moreover, Python is used by adiverse group of users, from school children through scientists tocorporations with multi-million line codebases. We want to includeall our varied audiences.
Vitality We want to avoid stagnation. Python is a mature project but itneeds to keep evolving to stay relevant, both the runtime and the programminglanguage. To do that, people interested in improving a particular partof the project should be able to do so without needless friction.But for substantial changes, we want some discourse and reflection to ensurethe changes are wise.
Inclusive The Community Model is the most inclusive model. No single personor a small group of people is in a distinguished position of power overothers. Contributors and any workgroups in this model are self-selecting.
Pragmatic This model ensures no user group is put at a disadvantage due tothe interests of a single person or a small group of people.
Proven This model works. There is a number of large open-source projectsrun this way (two of which, Rust and Django, are described inPEP 8002).ECMAScript and C++ are similarly developed.
The Python project is developed by a team of core developers.While membership is determined by presence in the “Python core” teamin the “python” organization on GitHub, contribution takes many forms:
Some contributors are may be considered dormant, in other words they did notcontribute to the last two releases of CPython. Any dormant contributor can atany time resume contribution.
The Python Developer’s Guide lists a number of interest areas along withnames of core developers who are recognized as experts in the givenarea. An expert or a sub-team of experts has the followingresponsibilities:
A core developer can assign and unassign themselves at will toa given interest area. Existing experts listed for the given interestarea must be made aware of this change and have to unanimously agree toit.
If a given interest area lists multiple experts, they form a sub-teamwithin the core team. They are responsible for the given interest areatogether.
A core developer should avoid membership as an expert in too manyinterest areas at the same time. This document deliberately doesn’tspecify a maximum number, it simply signals that overexertion leads toburnout and is a risk to the project’s ability to function withouta given contributor.
There is a group of people, some of which are not core developers,responsible for ensuring that discussions on official communicationchannels adhere to the Code of Conduct. They take action in view ofviolations.
Primary work happens through bug tracker issues and pull requests.Core developers should avoid pushing their changes directly to the cpythonrepository, instead relying on pull requests. Approving a pullrequest by a core developer allows it to be merged without furtherprocess.
Notifying relevant experts about a bug tracker issue or a pull requestis important. Reviews from experts in the given interest area arestrongly preferred, especially on pull request approvals. Failure todo so might end up with the change being reverted by the relevantexpert.
Experts are not required to listen to the firehose of GitHub and bugtracker activity at all times. Notifying an expert explicitly duringtriage or bug/pull request creation may be necessary to get theirattention.
Substantial changes in a given interest area require a PEP. Thisincludes:
Failure to get a substantial change through the PEP process might resultwith the change being reverted.
Changes that are bug fixes can be exempt from the PEP requirement. Useyour best judgement.
The PEP process is augmented with the following changes and clarificationsover information already present inPEP 1:
If a core contributor feels strongly against a particular PEP, duringits FCP they may raise a motion to reject it by vote. Voting detailsare described below in “Voting Mechanics”.
This should be a last resort and thus a rare occurrence. It splits thecore team and is a stressful event for all involved. However, theexperts filing for a FCP for a PEP should have a good sense whethera motion to reject it by vote is likely. In such a case, care should betaken to avoid prematurely filing for a FCP.
There is no recourse for the opposite situation, i.e. when theexperts want to reject a PEP but others would like it accepted. Thisensures 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 ofConduct first and foremost, to ensure healthy interaction between allinterested parties. Enforcement can result in a given participantbeing excluded from further discussion and thus the decision process.
If a PEP is deferred or rejected, the relevant experts should becontacted first before another attempt at the same idea is made.If the experts agree there is substantial evidence to justifyrevisiting the idea, a pull request editing the deferred or rejectedPEP can be opened.
Failure to get proper expert buy-in beforehand will likely result inimmediate rejection of a pull request on a deferred or rejected PEP.
A champion nominates a person to become a new core developer by postingon official communication channels. A vote is opened.
If any existing core developer does not feel comfortable with the nomineereceiving the commit bit, they should preferably address this concern inthe nomination thread. If there is no satisfactory resolution, they cancast a negative vote.
In practice, nominating a person for a core developer should often meetwith surprise by others that this person is not a core developer yet.In other words, it should be done when the candidate is already knownand trusted well enough by others. We should avoid nominations based onpotential.
Those describe a situation where a core developer is forcefullyremoved from the core team or an experts team is forcefully disbanded.Hopefully those will never have to be exercised but they are explicitlymentioned to demonstrate how a dysfunctional area of interest can behealed.
If a core developer is removed by vote from the core team, they losethe ability to interact with the project. It’s up to the Moderators’discretion to remove their ability to post on the bug tracker and GitHubor just moderate their future behavior on a case-by-case basis.
If the experts team for an area of interest is disbanded, other coredevelopers can step up to fill the void at will. Members of thedisbanded experts team cannot self-nominate to return.
All votes described in this document are +1/-1/0 (“Yea”/”Nay”/”Present”)recorded votes. There are no other vote values, in particular valuesout of range or fractions (like +0.5) are invalid.
Votes take fourteen calendar days. The starting date is taken looking atthe timezone of the person who filed for the motion to vote. The enddate 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, theycan 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 afterthe voting period is over. The repository’s name should start with“vote-“.
Changes to one’s vote during the voting period is allowed. Peekingat other developers’ cast votes during the time of the vote is possible.
Every situation requires a different vote percentage:
This document deliberately omits listing possible areas of interestwithin the project. It also does not address election and managementof Moderators which are done by the Python Software Foundation and itsCode of Conduct Working Group which can be contacted by mailingconduct-wg@python.org.
Thank you to the authors ofPEP 8002 which was a helpful resource inshaping this document.
Thank you to Alex Crichton and the Rust team for a governance modelthat was a major inspiration for this document.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-8012.rst
Last modified:2025-02-01 08:55:40 GMT