# PEP 8010 - The singular leader **URL:** \ **Category:** Committers\ **Tags:** governance\ **Created:** [October 8, 2018, 2:56am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188 "2018-10-08T02:56:52Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [October 8, 2018, 2:56am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/1 "2018-10-08T02:56:52Z")
PEP: 8010 Title: The BDFL Governance Model Author: Barry Warsaw [barry@python.org](mailto:barry@python.org) Status: Active Type: Informational Content-Type: text/x-rst Created: 2018-08-24 # Abstract This PEP proposes a continuation of the singular project leader model, euphemistically called the `Benevolent Dictator For Life `\_ (BDFL) model of Python governance, to be henceforth called in this PEP the Gracious Umpire Influencing Decisions Officer (GUIDO). This change in name reflects both the expanded view of the GUIDO as final arbiter for the Python language decision making process in consultation with the wider development community, and the recognition that “for life” while perhaps aspirational, is not necessarily in the best interest of the well-being of either the language or the GUIDO themselves. This PEP describes: - The rationale for maintaining the singular leader model - The process for how the GUIDO will be selected, elected, retained, recalled, and succeeded; - The roles of the GUIDO in the Python language evolution process; - The term length of service; - The relationship of the GUIDO with a Council of Pythonistas (CoP) that advise the GUIDO on technical matters; - The size, election, and roles of the CoP; - The decision delegation process; - Any changes to the PEP process to fit the new governance model; This PEP does _not_ name a new BDFL. Should this model be adopted, it will be codified in PEP 13 along with the names of all officeholders described in this PEP, as voted on per the guidelines in PEP 8001. # Open discussion points Various tweaks to the parameters of this PEP are allowed during the governance discussion process, such as the exact size of the CoP, term lengths of service, and voting procedures. These will be codified by the time the PEP is ready to be voted on. It is allowed, and perhaps even expected, that as experience is gained with this model, these parameters may be tweaked as future GUIDOs are named, in order to provide for a smoother governing process. The process for tweaking these parameters will generally be the same voting process as described in PEP 8001. # Why a singular leader? Why this model rather than any other? It comes down to “vision”. `Design by committee`\_ has many known downsides, leading to a language that accretes new features based on the varied interests of the contributors at the time. An famous aphorism is “a camel is a horse designed by committee”. Can a language that is designed by committee “hang together”? Does it feel like a coherent, self-consistent language where the rules make sense and are easily remembered? A singular leader can promote that vision more than a committee can, whether that committee is small (e.g. 3 or 5 persons) or spans the entire Python community. Every participant will have their own vision of what “Python” is, and this can lead to indecision or illogical choices when those individual visions are in conflict. Should CPython be 3x faster or should we preserve the C API? That’s a very difficult question to get consensus on, since neither choice is right or wrong. But worse than making the wrong decision might be accepting the status quo because no consensus could be found. # Flexibility Degrees of flexibility are given to both the GUIDO and CoP by way of underspecification. This PEP describes how conflicts will be resolved, but expects all participants, including core developers, community members, and office holders, to always have the best interest of Python and its users at heart. The PEP assumes that mutual respect and the best intentions will always lead to consensus, and that the Code of Conduct governs all interactions and discussions. # The role of the GUIDO One of the most important roles of the GUIDO is to provide an overarching, broad, coherent vision for the evolution of the Python language, spanning multiple releases. This is especially important when decision have lasting impact and competing benefits. For example, if backward incompatible changes to the C API leads to a 2x improvement in Python performance, different community members will likely advocate convincingly on both sides of the debate, and a clear consensus may not emerge. Either choice is equally valid. In consultation with the CoP, it will be the GUIDO’s vision that guides the ultimate decision. The GUIDO is the ultimate authority for decisions on PEPs, including whether any particular change is PEP-worthy. As is the case today, many --in fact perhaps most-- decisions are handled by discussion and resolution on the issue tracker, merge requests, and discussion forums, usually with input or lead by experts in the particular field. Where this operating procedure works perfectly well, it can continue unchanged. This also helps reduce the workload on the CoP and GUIDO, leaving only the most important decisions and broadest view of the landscape to the central authority. Similarly, should a particular change be deemed to require a PEP, but the GUIDO, in consultation with the CoP, identifies experts that have the full confidence to make the final decision, the GUIDO can name a Delegate for the PEP. While the GUIDO remains the ultimate authority, it is expected that the GUIDO will not undermine, and in fact will support 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 counter to the long term vision for Python. This is done with compassion for the advocates of the change, but with the health and well-being of all community members in mind. A toxic discussion on a dead-end proposal does no one any good, and they can be terminated by fiat. # Authority comes from the community The GUIDO’s authority ultimately resides with the community. A rogue GUIDO that loses the confidence of the majority of the community can be recalled and a new vote conducted. This is an exceedingly rare and unlikely event. This is a sufficient stopgap for the worst case scenario, so it should not be undertaken lightly. The GUIDO should not fear being deposed because of one decision, even if that decision isn’t favored by the majority of Python developers. Recall should be reserved for actions severely detrimental to the Python language or community. The Council of Pythonistas (see below) has the responsibility to initiate a vote of no-confidence. # Length of service and term limits The GUIDO shall serve for three Python releases, approximately 4.5 years given the current release cadence. After this time, a new election is held according 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 of course, Life Happens. Should the GUIDO need to step down before their term ends, the vacancy will be filled by the process outlined below as per choosing a new GUIDO. However, the new GUIDO will only serve for the remainder of the original GUIDO’s term, at which time a new election is conducted. The GUIDO stepping down may continue to serve until their replacement is selected. # Choosing a GUIDO The selection process is triggered whenever a vacancy exists for a new GUIDO, or when the GUIDO is up for re-election in the normal course of events. When the selection process is triggered, either by the GUIDO stepping down, or two months before the end of the GUIDO’s regular term, a new election process begins. For three weeks prior to the vote, nominations are open. Candidates must be chosen from the current list of core Python developers. Non-core developers are ineligible to serve as the GUIDO. Candidates may self-nominate, but all nominations must be seconded. Nominations and seconds are conducted as merge requests on a private repository. Once they accept their nomination, nominees may post short position statements using the same private repository, and may also post them to 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 process described in PEP 8001. # The Council of Pythonistas (CoP) Assisting the GUIDO is a small team of elected Python experts. They serve on a team of technical committee members. They provide insight and offer discussion of the choices before the GUIDO. Consultation can be triggered from either side. For example, if the GUIDO is still undecided about any particular choice, discussions with the CoP can help clarify the remaining issues, identify the right questions to ask, and provide insight into the impact on other users of Python that the GUIDO may not be as familiar with. The CoP are the GUIDO’s trusted advisers, and a close working relationship is expected. The CoP shall consistent of 3 members, elected from among the core developers. Their term runs for 3 years and members may run for re-election as many times as they want. To ensure continuity, CoP members are elected on a rotating basis; every year, one CoP member is up for re-election. In order to bootstrap the stagger for the initial election, the CoP member with the most votes shall serve for 3 years, the second most popular vote getter shall serve for 2 years, and CoP member with the least number of votes shall serve initially for 1 year. All ties in voting will be broken with a procedure to be determined in PEP 8001. The nomination and voting process is similar as with the GUIDO. There is a three week nomination period, where self-nominations are allowed and must be seconded, followed by a period of time for posting position statements, followed by a vote. By unanimous decision, the CoP may begin a no-confidence vote on the GUIDO, triggering the procedure in that section. # No confidence votes As mentioned above, the CoP may, by unanimous decision, initiate a vote of no-confidence in the GUIDO. This process should not be undertaken lightly, but once begun, it triggers up to two votes. In both cases, voting is done by the same procedure as in PEP 8001, and all core developers may participate in no confidence votes. The first vote is whether to recall the current GUIDO or not. Should a simple majority of Python developers vote “no confidence”, the GUIDO is recalled. A second vote is then conducted to select the new GUIDO, in accordance with the procedures for initial section of this office holder. During the time in which there is no GUIDO, major decisions are put on hold, but normal Python operations may of course continue. # Day to day operations The GUIDO is not needed for all – or even most – decisions. Python developers already have plenty of opportunity for delegation, responsibility, and self-direction. The issue tracker and pull requests serve exactly the same function as they did before this governance model was chosen. Most discussions of bug fixes and minor improvements can just happen on these forums, as they always have. # PEP considerations The GUIDO, members of the CoP, and anyone else in the Python community may propose a PEP. Treatment of the prospective PEP is handled the same regardless of the author of the PEP. However, in the case of the GUIDO authoring a PEP, an impartial PEP Delegate should be selected, and given the authority to accept or reject the PEP. The GUIDO should recuse themselves from the decision making process. In the case of controversial PEPs where a clear consensus does not arrive, ultimate authority rests with the CoP. The PEP propose is further enhanced such that a core developer must always be chose as the PEP Shepherd. This person ensure that proper procedure is maintained. The Shepherd must be chosen from among the core developers. This means that while anyone can author a PEP, all PEPs must have some level of sponsorship from at least one core developer. # Copyright This document has been placed in the public domain. … \_`Design by committee`: [https://en.wikipedia.org/wiki/Design\_by\_committee](https://en.wikipedia.org/wiki/Design_by_committee) … Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [October 8, 2018, 2:57am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/2 "2018-10-08T02:57:27Z")
Consider this a draft! I also have a [pull request](https://github.com/python/peps/pull/800). ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [October 8, 2018, 9:36am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/3 "2018-10-08T09:36:10Z")
> [@barry](#): > > `Design by committee` \_ has many known downsides, leading to a language > that accretes new features based on the varied interests of the > contributors at the time. An famous aphorism is “a camel is a horse > designed by committee”. Can a language that is designed by committee > “hang together”? Does it feel like a coherent, self-consistent > language where the rules make sense and are easily remembered? This seems a bit FUDesque to me. The PEP doesn’t enumerate any BDFL-designed languages (except for Python, implicitly), nor any committee-designed languages, it just makes an unsubstantiated general argument. According to Wikipedia, « **Design by committee** is a disparaging term for a project that has many designers involved but no unifying plan or vision. » The term doesn’t say anything about a project that would have several designers _and_ a unifying plan or vision (Rust?). It also doesn’t say anything about a project that would have a single designer/dictator but _no_ unifying plan or vision (PHP?). > [@barry](#): > > leading to a language > that accretes new features based on the varied interests of the > contributors at the time. Well, isn’t it what happened with Python as well? Python got `yield from` and then `async / await` because Guido and several other people were interested by those at the time. Then it got the `typing` module because Guido and several other people were interested by those at the time. There is no overarching “vision” that determined those would be present from the start (had Guido not been employed at a company with a large Python codebase maintenance issue (Dropbox), perhaps `typing` would never have been integrated). AFAIK, the only time Python had some kind of (implicit or explicit) roadmap was for the design of Python 3. Otherwise, it’s just contributors implementing whatever interests them – including Guido. So I think the entire argument for this PEP is a post-hoc rationalization (and embellishment) of a very ad hoc process. ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [October 8, 2018, 9:40am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/4 "2018-10-08T09:40:21Z")
PS : in which category is this topic posted? I can’t find it in “Committers”… And why does it say “This topic will close 3 days after the last reply” ? ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [October 8, 2018, 8:54pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/5 "2018-10-08T20:54:07Z")
I’m not sure how different that is from other proposals though. ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [October 8, 2018, 8:54pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/6 "2018-10-08T20:54:25Z")
All I did was hit “New Topic” and Discourse did the rest! ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 8, 2018, 9:00pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/7 "2018-10-08T21:00:46Z")
Apparently that created a topic that isn’t in a category… I also just came across this topic by pure chance… Maybe someone who understands discourse can move this to committers? ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [October 8, 2018, 9:03pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/8 "2018-10-08T21:03:11Z")
Ok, I changed the category to “Committers”. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [October 8, 2018, 9:04pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/9 "2018-10-08T21:04:07Z")
It seems like “PEP 8010 - The singular leader” has been posted in the “Welcome to Discourse” category. I expected it in the “Committers” category. By the way, from a discussion, I’m unable to find the category. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 8, 2018, 9:14pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/10 "2018-10-08T21:14:27Z")
There is one thing I really like in this proposal, and one thing I really don’t like. I really like how this proposal looks at innovation, and at how a singular leader can take hard decisions that will never be taken with any of the committee/council/etc models from the other 801X series. I really don’t like how the proposal doesn’t seem to address the workload and emotional load that having one BDFL or GUIDO puts on a single individual. Just a wild idea: would it be possible to come up with a model where there is some committee or procedure (from one of the other 801X proposals) for normal decisions and a separate 8010-GUIDO-like individual who is in charge of long term progress of the language? ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [October 8, 2018, 9:22pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/11 "2018-10-08T21:22:38Z")
I am purposefully not address the workload issue, because that’s going to be different for every person, and the coping strategies will be different too. E.g. @brettcannon taking a month off per year. I’m implicitly pushing a lot of the workload to PEP authors/groups, the tracker, and PRs. I think that’s a common theme among the governance PEPs, so maybe we can refactor those bits out. After all that, maybe the workload on the GUIDO will be a lot less. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 8, 2018, 9:30pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/12 "2018-10-08T21:30:22Z")
> [@barry](#): > > I’m implicitly pushing a lot of the workload to PEP authors/groups, the tracker, and PRs. I think that’s a common theme among the governance PEPs, so maybe we can refactor those bits out. After all that, maybe the workload on the GUIDO will be a lot less. I now see that somewhat, in the _day to day operation_ section. But the really visible decisions, i.e. the controversial PEPs or the PEPs that turn out to have implications that weren’t initially foreseen, would still fall on the shoulders of a single individual… ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [October 8, 2018, 9:33pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/13 "2018-10-08T21:33:56Z")
True. I think it’ll generally be manageable, but the GUIDO can always take a vacation. I’ll admit maybe I’m downplaying the stress placed on the GUIDO here. ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [October 8, 2018, 10:05pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/14 "2018-10-08T22:05:11Z")
> [@barry](#): > > I’m not sure how different that is from other proposals though. What do you mean by that? ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 8, 2018, 10:09pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/15 "2018-10-08T22:09:34Z")
He’s rightfully saying there’s plenty of trash talk on the other PEPs as well, also with little citation. I know PEP 8012 does some of that, Carol made nice edits to make it less so in the repo. I need to merge it on Discourse, will do that in the morning. ---
**Author:** ![system](https://us1.discourse-cdn.com/flex002/uploads/python1/original/1X/3aff56846ebe57781a163dfc748fd1417119d8ab.png) [@system](https://discuss.python.org/u/system)\ **Post date:** [October 11, 2018, 10:09pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/16 "2018-10-11T22:09:37Z")
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 12, 2018, 9:16am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/17 "2018-10-12T09:16:52Z")
---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 12, 2018, 9:17am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/18 "2018-10-12T09:17:31Z")
Silly Discourse closed the topic anyway. ---
**Author:** ![hynek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hynek/32/21247_2.png) [@hynek](https://discuss.python.org/u/hynek)\ **Post date:** [October 17, 2018, 7:33am UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/19 "2018-10-17T07:33:10Z")
As @pitrou pointed out, I find it an overstatement that Guido always had grand vision for Python. The reason why I got nice things like `asyncio` or `typing` was indeed mostly because he happened to work at the right companies with the right problems. Therefore I don’t quite buy into the premise. I also have a _very_ hard time to come up with people who I’d consider fit for the job. It appears that you’d need to be a benevolent demi-god with a perfect understanding of Python’s ecosystem, a crystal ball, _and_ a time machine. All that to say that while I find the _mechanics_ good, I don’t think the _overall approach_ is realistic because I don’t think one person can fulfill the outlined tasks well. ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [October 18, 2018, 5:23pm UTC](https://discuss.python.org/t/pep-8010-the-singular-leader/188/20 "2018-10-18T17:23:46Z")
Guido always had an innate sense of what was Pythonic, and it was that vision that holds the language together. So while he may not have always had grand plans for what big things were needed in the language or stdlib, and new ideas often come organically from users (which won’t change no matter what the governance structure), I think he usually had a good sense of what Python would look like with that feature, or more importantly, why a particular feature would _not_ be Pythonic. As for coming up with candidates, I’m quite convinced that there are highly qualified leaders within they Python community that could do the job. They would do it differently than Guido (who, after all is human too 🙂 ) and they would find the right balance of life, work, family, Python. And people will grow into their leadership positions. I wonder if Guido could have imagined himself as leading one of the world’s most popular languages back when he first released it. 🙂 [Next page](https://discuss.python.org/t/pep-8010-the-singular-leader/188.md?page=2)