This PEP proposes a continuation of the singular technical projectleader model, euphemistically called theBenevolent Dictator For Life (BDFL)model of Python governance, to be henceforth called in this PEP theGracious Umpire Influencing Decisions Officer (GUIDO). This change inname reflects both the expanded view of the GUIDO as final arbiter forthe Python language decision making process in consultation with thewider development community, and the recognition that “for life” whileperhaps aspirational, is not necessarily in the best interest of thewell-being of either the language or the GUIDO themselves.
This PEP describes:
This PEP doesnot name a new BDFL. Should this model be adopted, itwill be codified inPEP 13 along with the names of all officeholdersdescribed in this PEP.
PEP 8010 was rejectedby a core developer votedescribed inPEP 8001 on Monday, December 17, 2018.
PEP 8016 and the governance model it describes were chosen instead.
Various tweaks to the parameters of this PEP are allowed during thegovernance discussion process, such as the exact size of the CoP, termlengths of service, and voting procedures. These will be codified bythe time the PEP is ready to be voted on.
The voting procedures and events described in this PEP will default tothe voting method specified inPEP 8001, although as that PEP is stillin discussion at the time of this writing, this is subject to change.
It is allowed, and perhaps even expected, that as experience is gainedwith this model, these parameters may be tweaked as future GUIDOs arenamed, in order to provide for a smoother governing process.
Why this model rather than any other? It comes down to “vision”.Design by committee has many known downsides, leading to a languagethat accretes new features based on the varied interests of thecontributors at the time. A famous aphorism is “a camel is a horsedesigned by committee”. Can a language that is designed by committee“hang together”? Does it feel like a coherent, self-consistentlanguage where the rules make sense and are easily remembered?
A singular technical leader can promote that vision more than acommittee can, whether that committee is small (e.g. 3 or 5 persons)or spans the entire Python community. Every participant will havetheir own vision of what “Python” is, and this can lead to indecisionor illogical choices when those individual visions are in conflict.Should CPython be 3x faster or should we preserve the C API? That’s avery difficult question to get consensus on, since neither choice isright or wrong. But worse than making the wrong decision might beaccepting the status quo because no consensus could be found.
Degrees of flexibility are given to both the GUIDO and CoP by way ofunderspecification. This PEP describes how conflicts will beresolved, but expects all participants, including core developers,community members, and office holders, to always have the bestinterest of Python and its users at heart. The PEP assumes thatmutual respect and the best intentions will always lead to consensus,and that the Code of Conduct governs all interactions and discussions.
One of the most important roles of the GUIDO is to provide anoverarching, broad, coherent vision for the evolution of the Pythonlanguage, spanning multiple releases. This is especially importantwhen decision have lasting impact and competing benefits. Forexample, if backward incompatible changes to the C API leads to a 2ximprovement in Python performance, different community members willlikely advocate convincingly on both sides of the debate, and a clearconsensus may not emerge. Either choice is equally valid. Inconsultation with the CoP, it will be the GUIDO’s vision that guidesthe ultimate decision.
The GUIDO is the ultimate authority for decisions on PEPs and otherissues, including whether any particular change is PEP-worthy. As isthe case today, many –in fact perhaps most– decisions are handled bydiscussion and resolution on the issue tracker, merge requests, anddiscussion forums, usually with input or lead by experts in theparticular field. Where this operating procedure works perfectlywell, it can continue unchanged. This also helps reduce the workloadon the CoP and GUIDO, leaving only the most important decisions andbroadest view of the landscape to the central authority.
Similarly, should a particular change be deemed to require a PEP, butthe GUIDO, in consultation with the CoP, identifies experts that havethe full confidence to make the final decision, the GUIDO can name aDelegate for the PEP. While the GUIDO remains the ultimate authority,it is expected that the GUIDO will not undermine, and in fact willsupport the authority of the Delegate as the final arbiter of the PEP.
The GUIDO has full authority to shut down unproductive discussions,ideas, and proposals, when it is clear that the proposal runs counterto the long-term vision for Python. This is done with compassion forthe advocates of the change, but with the health and well-being of allcommunity members in mind. A toxic discussion on a dead-end proposaldoes no one any good, and they can be terminated by fiat.
To sum up: the GUIDO has the authority to make a final pronouncementon any topic, technical or non-technical, except for changing to thegovernance PEP itself.
The GUIDO’s authority ultimately resides with the community. A rogueGUIDO that loses the confidence of the majority of the community canbe recalled and a new vote conducted. This is an exceedingly rare andunlikely event. This is a sufficient stopgap for the worst-casescenario, so it should not be undertaken lightly. The GUIDO shouldnot fear being deposed because of one decision, even if that decisionisn’t favored by the majority of Python developers. Recall should bereserved for actions severely detrimental to the Python language orcommunity.
The Council of Pythonistas (see below) has the responsibility toinitiate a vote of no-confidence.
The GUIDO shall serve for three Python releases, approximately 4.5years given the current release cadence. If Python’s release cadencechanges, the length of GUIDO’s term should change to 4.5 years roundedto whole releases. How the rounding is done is left to the potentialrelease cadence PEP. After this time, a new election is heldaccording to the procedures outlined below. There are no term limits,so the GUIDO may run for re-election for as long as they like.
We expect GUIDOs to serve out their entire term of office, but ofcourse, Life Happens. Should the GUIDO need to step down before theirterm ends, the vacancy will be filled by the process outlined below asper choosing a new GUIDO. However, the new GUIDO will only serve forthe remainder of the original GUIDO’s term, at which time a newelection is conducted. The GUIDO stepping down may continue to serveuntil their replacement is selected.
During the transition period, the CoP (see below) may carry out theGUIDO’s duties, however they may also prefer to leave substantivedecisions (such as technical PEP approvals) to the incoming GUIDO.
The selection process is triggered whenever a vacancy exists for a newGUIDO, or when the GUIDO is up for re-election in the normal course ofevents. When the selection process is triggered, either by the GUIDOstepping down, or two months before the end of the GUIDO’s regularterm, a new election process begins.
For three weeks prior to the vote, nominations are open. Candidatesmust be chosen from the current list of core Python developers.Non-core developers are ineligible to serve as the GUIDO. Candidatesmay self-nominate, but all nominations must be seconded. Nominationsand seconds are conducted as merge requests on a private repository.
Once they accept their nomination, nominees may post short positionstatements using the same private repository, and may also post themto the committers discussion forum. Maybe we’ll even have debates!This phase of the election runs for two weeks.
Core developers then have three weeks to vote, using the processdescribed inPEP 8001.
Assisting the GUIDO is a small team of elected Python experts. Theyserve on a team of technical committee members. They provide insightand offer discussion of the choices before the GUIDO. Consultationcan be triggered from either side. For example, if the GUIDO is stillundecided about any particular choice, discussions with the CoP canhelp clarify the remaining issues, identify the right questions toask, and provide insight into the impact on other users of Python thatthe GUIDO may not be as familiar with. The CoP are the GUIDO’strusted advisers, and a close working relationship is expected.
The CoP shall consist of 3 members, elected from among the coredevelopers. Their term runs for 3 years and members may run forre-election as many times as they want. To ensure continuity, CoPmembers are elected on a rotating basis; every year, one CoP member isup for re-election.
In order to bootstrap the stagger for the initial election, the CoPmember with the most votes shall serve for 3 years, the second mostpopular vote getter shall serve for 2 years, and CoP member with theleast number of votes shall serve initially for 1 year.
All ties in voting will be broken with a procedure to be determined inPEP 8001.
The nomination and voting process is similar as with the GUIDO. Thereis a three-week nomination period, where self-nominations are allowedand must be seconded, followed by a period of time for postingposition statements, followed by a vote.
By unanimous decision, the CoP may begin a no-confidence vote on theGUIDO, triggering the procedure in that section.
As mentioned above, the CoP may, by unanimous decision, initiate avote of no-confidence in the GUIDO. This process should not beundertaken lightly, but once begun, it triggers up to two votes. Inboth cases, voting is done by the same procedure as inPEP 8001, andall core developers may participate in no confidence votes.
The first vote is whether to recall the current GUIDO or not. Shoulda super majority of Python developers vote “no confidence”, the GUIDOis recalled. A second vote is then conducted to select the new GUIDO,in accordance with the procedures for initial section of this officeholder. During the time in which there is no GUIDO, major decisionsare put on hold, but normal Python operations may of course continue.
The GUIDO is not needed for all – or even most – decisions. Pythondevelopers already have plenty of opportunity for delegation,responsibility, and self-direction. The issue tracker and pullrequests serve exactly the same function as they did before thisgovernance model was chosen. Most discussions of bug fixes and minorimprovements can just happen on these forums, as they always have.
The GUIDO, members of the CoP, and anyone else in the Python communitymay propose a PEP. Treatment of the prospective PEP is handled thesame regardless of the author of the PEP.
However, in the case of the GUIDO authoring a PEP, an impartial PEPDelegate should be selected, and given the authority to accept orreject the PEP. The GUIDO should recuse themselves from the decisionmaking process. In the case of controversial PEPs where a clearconsensus does not arrive, ultimate authority on PEPs authored by theGUIDO rests with the CoP.
The PEP propose is further enhanced such that a core developer mustalways be chose as the PEP Shepherd. This person ensure that properprocedure is maintained. The Shepherd must be chosen from among thecore developers. This means that while anyone can author a PEP, allPEPs must have some level of sponsorship from at least one coredeveloper.
Version 2
- Renamed to “The Technical Leader Governance Model”
- “singular leader” -> “singular technical leader”
- The adoption ofPEP 8001 voting procedures is tentative until thatPEP is approved
- Describe what happens if the GUIDO steps down
- Recall votes require a super majority of core devs to succeed
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-8010.rst
Last modified:2025-02-01 08:55:40 GMT