This PEP formalizes the current organization of the Python community andproposes 3 main changes:
PEPs are approved by a PEP delegate or by a vote (reserved to coredevelopers, need>=2/3 majority).
PEP 8015 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 describes the organization of the whole Python developmentcommunity, from Python users to the Python Steering Committee.Describing all groups and all roles in the same document helps to makethe organization more consistent.
The number of governance changes is minimized to get a smooth transitionfrom the old BDFL organization to the new Steering Committeeorganization.
One key design of the organization is to avoid decision bottlenecks.Discussions and decisions are distributed into Python teams whereexperts in each topic can be found. The expectation is smootherdiscussions on PEPs: fewer people with better knowledge of the topic.
Previously, most decisions have been taken by the BenevolentDictator For Life (BDFL), Guido van Rossum. The growing popularity ofPython increased the pressure on a single person. The proposedorganization distributes decisions and responsibilities to reduce thepressure and avoid wearing any individual down.
To keep most of the decision power within the hands of the community,the Python Steering Committee has very limited roles. The idea is to reduce the riskthat a group of people or companies “takes over” the Python projectthrough just a couple individuals. The project must remain autonomousand open to everybody.
The most sensitives PEPs are decided by democracy: a vote reserved tocore developers, see thePEP process section below for the votingmethod.
Right now, there are different group of people involved in the Pythonproject. The more involved you are, the more decisions power you get. Itis important that the people acceding to the deepest group are the mosttrusted ones.
This PEP formalizes the following groups:
This is the largest group: anyone who uses Python.
Once a Python user sends an email to a Python mailing list, comments onthe Python bug tracker, proposes or reviews a Python change, they becomea Python contributor.
Python became too big to work as a unique team anymore, peoplenaturally have grouped themselves as teams to work more closely onspecific topics, sometimes called “Special Interest Group” (SIG).
When enough developers are interested by a specific topic, they cancreate a new team. Usually, the main action is to ask the Pythonpostmaster to create a new “SIG” mailing list, but the team can chooseto use a different communication channel.
Team members are Python contributors and Python core developers. Theteam is self-organized and is responsible to select who can join theteam and how.
Team members can get the bug triage permission on the team bug trackercomponent. The more involved in a team you are, the more decisions powerand responsibilities you get.
A team might become allowed to decide on their own PEPs, but only thePython Steering Committee can allow that (and it has the power to revokeit as well). Such a case is exceptional, currently a single team hassuch permission: the Packaging Team.
One restricted definition of a core developer is the ability to merge achange (anywhere in the code) and have the bug triage permission(on all bug tracker components).
Core developers are developers who are proven to have the required skills todecide if a change can be approved or must be rejected, but also (andthis is more important) what changes should not be made. Python has along history, big constraints on backward compatibility, high qualitystandards (ex: changes require new tests). For these reasons, becominga core can take several months or longer.
Becoming a core developer means more responsibilities. For example, if adeveloper merges a change, they become responsible for regressions andfor the maintenance of that modified code.
Core developers are expected to be exemplary when it comes to the Codeof Conduct. They are encouraged to mentor contributors.
Once an existing core developer considers that a contributor is ready tojoin the core group, to become a core developer, that core developerasks the contributor if they would like to become a core developer. Ifthe contributor is interested in such new responsibilities, a vote isorganized.
The vote is reserved to core developers, is public, and is open for 1week. Usually the core developer who proposes the promotion has todescribe the work and skills of the candidate in the description of thevote. A contributor is only promoted if two thirds (>=2/3) ofvotes approve (“+1”) the promotion. Only “+1” and “-1” votes areaccounted; other votes (ex: null, “-0”, “+0.5”) are ignored.
If the candidate is promoted, usually they get a mentor for 1 month tohelp them to handle new responsibilities.
If the candidate is not promoted, a new vote can be organized later,when the candidate gets the missing skills, for example 6 months later.
The Python Steering Committee is made of the most trusted coredevelopers since it has the most decision power. The roles of this groupare strictly limited to ensure that Python keeps its autonomy andremains open.
The Python Steering Committee is composed of 5 members. They are electedfor 3 years and 1/3 is replaced every year (first year: 1, second year:2, third year: 2). This way, a member will stay for one full Pythonrelease and the committee composition will be updated frequently. Acommittee member can be a candidate for the seat they are leaving.There are no term limits.
Committee members must be Python core developers. It is important thatthe members of the committee reflect the diversity of Python’ users andcontributors. A small step to ensure that is to enforce that only 2members (strictly less than 50% of the 5 members) can work for the sameemployer (same company or subsidiaries of the same company).
The size of 5 members has been chosen for the members diversity and toensure that the committee can continue to work even if a member becomesunavailable for an unknown duration.
Python Steering Committee roles:
To decide how a PEP is approved (or rejected or deferred), there are twooptions:
The committee keeps the “vision” and consistency of Python. It also makessure that important features reach completion. Their ability to pick PEPdelegates is meant to help them to achieve that goal.
The vote is organized by the Steering Committee. It is announced 3 weeksin advance: candidates have to apply during this period. The vote isreserved to core developers and is open for 1 week. To avoidself-censorship, the vote uses secret ballots: avoid the risk ofhostility from someone who may get more power (if they get elected).
The vote uses theSchulze/Beatpath/CSSD variant of theCondorcetmethod using anonline service likeCondorcet Internet Voting Service (CIVS). This voting method reduces the risk oftie. It also produces a ranking of all candidates, needed for thecreation of the committee.
In case of tie, a new vote is organized immediately between candidatesinvolved in the tie using the same voting method and also during 1 week.If the second vote leads to a tie again, the current Steering Committeeis responsible to select the elected member(s).
If a committee member steps down, a new vote is organized to replacethem.
If the situation of a committee member changes in a way that no longersatisfies the committee constraint (ex: they move to the same company astwo other committee members), they have to resign. If the employer of amember is acquired by the employer of two other members, the member withthe mandate ending earlier has to resign once the acquisition completes.
To bootstrap the process, 5 members are elected at the committeecreation. The vote follows the same rules than regular committee votes,except that the election needs 5 members, and the vote is organized bythe PSF Board.
In a council election, if 3 of the top 5 vote-getters work for thesame employer, then whichever of them ranked lowest is disqualifiedand the 6th-ranking candidate moves up into 5th place; this isrepeated until a valid council is formed.
In case of tie, a second vote is organized immediately betweencandidates involved in the tie and following candidates to fill theremaining seats. The vote follows the same rules as the regularcommittee vote. If the second vote still result in a tie, the PSF Boardis responsible to elect members and decide their position in the voteresult.
The order in the vote result must be unique for elected members: #1 and#2 are elected for 3 years, #2 and #3 for 2 years, and #5 for 1 year.
Example of vote result with a tie:
The first 4 candidates (A, B, C and D) are elected immediately. If Eworks for the same employer than two other elected member, F is alsoelected. Otherwise, a second vote is organized for the 5th seat betweenE and F.
A committee member can be a PEP delegate.
A committee member can propose a PEP, but cannot be the PEP delegate oftheir own PEP.
When the committee decides that a PEP must be voted, committee memberscan vote as they are also core developers, but they don’t have morepower than other core developer.
The workgroup’s purpose is to foster a diverse and inclusive Pythoncommunity by enforcing the PSF code of conduct, along with providingguidance and recommendations to the Python community on codes ofconduct, that supports the PSF mission of “ongoing development ofPython-related technology and educational resources”.
We work toward this common goal in three ways:
The organization of this workgroup is defined by theConductWG Charter.
As any other member of the Python community, the PSF Code of ConductWorkgroup can ban a core developer for a limited amount of time. In thiscase, the core developer immediately loses their core developer status.Core developers are expected to be exemplary when it comes to the Codeof Conduct.
In general, a ban is only the last resort action when all other optionshave been exhausted.
At the end of the ban, the developer is allowed to contribute again as aregular contributor.
If the developer changes their behavior, another core developer canorganize a new vote to propose the developer for promotion to coredeveloper. The vote follows the same process than for any other Pythoncontributor.
There are 2 main roles on PEPs:
PEP Authors do their best to write high quality PEP.
The PEP delegate is responsible to help the authors to enhance their PEPand is the one taking the final decision (accept, reject or defer thePEP). They can also help to guide the discussion.
If no decision is taken, the authors can propose again the PEP later(ex: one year later), if possible with new data to motivate the change. APEP Delegate can also choose to mark a PEP as “Deferred” to not rejectthe PEP and encourage to reopen the discussion later.
PEPs specific to a Python team are discussed on the team mailing list.PEPs impacting all Python developers (like language changes) must bediscussed on the python-dev mailing list.
When the Python Steering Committee decides that a PEP needs a widerapproval, a vote is organized.
The vote is reserved to core developers, is public, is announced 1 weekin advance, and is open for 1 week. The PEP can still be updated duringthe 1 week notice, but must not be modified during the vote. Such votehappens onthe mailing list where the PEP has been discussed. The committee decideswhen the vote is organized. The PEP must have been discussed for areasonable amount of time before it is put to vote.
A PEP is only approved if two thirds (>=2/3) of votes approve(“+1”) the PEP. Only “+1” and “-1” votes are accounted; other votes(ex: null, “-0”, “+0.5”) are ignored.
A PEP can only be approved or rejected by a vote, not be deferred.
If a discussion fails to reach a consensus, if the Python SteeringCommittee fail to choose a PEP delegate, or if a PEP delegate fails totake a decision, the obvious risk is that Python fails to evolve.
That’s fine. Sometimes, doing nothing is the wisest choice.
The first version of this PEP has been written after Guido van Rossumdecided to resign from his role of BDFL in July 2018. Before this PEP,the roles of Python community members have never been formalized. It isdifficult to design a perfect organization at the first attempt. ThisPEP can be updated in the future to adjust the organization, specify howto handle corner cases and fix mistakes.
Any change to this PEP must be validated by a vote. The vote isannounced 3 weeks in advance, is reserved to core developers, happens inpublic on the python-committers mailing list, and is open for 1 week.The proposed PEP change can still be updated during the 3 weeks notice,but must not be modified during the vote.
The change is only approved if four fifths (>=4/5) of votes approve(“+1”) the change. Only “+1” and “-1” votes are accounted; other votes(ex: null, “-0”, “+0.5”) are ignored.
| Vote | Notice | Open | Ballot | Method |
|---|---|---|---|---|
| Promote contributor | none | 1 week | public | >=2/3 majority |
| PEP | 1 week | 1 week | public | >=2/3 majority |
| Change this PEP | 3 weeks | 1 week | public | >=4/5 majority |
| Steering Committee | 3 weeks | 1 week | private | Condorcet (Schulze/Beatpath/CSSD) |
All these votes are reserved to core developers.
Below are examples of some Python teams (the list will not be kept up todate in this PEP).
The packaging team runs its own PEP category and can approve (or reject)their own PEPs.
DistutilsdistutilsIDLE is a special case in the Python standard library: it’s a wholeapplication, not just a module. For this reason, it has been decidedthat the code will be the same in all Python stable branches (whereasthe stdlib diverges in newer stable branches).
IDLEidlelibBecoming a core developer is long and slow process. Mentorship is anefficient way to train contributors as future core developers and builda trust relationship.
Note: The group is not responsible to promote core developers.
Documentationtype-docThe team also manages documentation translations.
See also the Mentorship team which maintains the “Devguide”.
security@python.org (to report vulnerabilities)hashlib,secrets andsslThesecurity@python.org mailing list is invite-only: only members ofthe “Python Security Response Team” (PSRT) can read emails and reply;whereas security-sig is public.
Note: This team rarely proposed PEPs.
Performancetype-performancecProfile,profile,pstats andtimeitUsually PEPs involving performance impact everybody and so are discussedon the python-dev mailing list, rather than the speed mailing list.
asyncioexpert-asyncioasyncio andcontextvarsPEP only modifyingasyncio andcontextvars can be discussed onthe async-sig mailing list, whereas changes impacting the Pythonlanguage must be discussed on python-dev.
typingNote: There is a backport for Python 3.6 and older, seetyping on PyPI.
History of this PEP:
>=2/3rather than50%+1.>=4/5 rather than50%+1.This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-8015.rst
Last modified:2025-02-01 08:55:40 GMT