Picking a governance model for Python

The Python language project has been officially "leaderless" since the mid-July announcement that Guido van Rossum was stepping down. He is, of course, the founder of the language and had served for more than two decades as its Benevolent Dictator for Life (BDFL). But he did not appoint a successor and left it up to the project's core developers to come up with a new governance structure. In the three months since, a great deal of work has gone into that effort, which has to bootstrap itself since there was not even any mechanism to choose how to select a new governance model.

As with nearly any sizable change for Python, the governance question was broken up into a series of Python Enhancement Proposals (PEPs). In this case, PEP 8000 is an overview (or index) of the different PEPs that are being considered. The starting point, though, is to determine how those competing proposals (there are six currently, though there is a fair amount of overlap between them in various ways) will be chosen. That is the role of PEP 8001 ("Python Governance Voting Process").

How to decide

There is a bit of a chicken-and-egg problem for PEP 8001, though. Normally, Van Rossum would decide on PEPs (or delegate them to someone else); he has not completely left the fold, but is definitely not handling that role any more. There was a core developer sprint in September where much of the contents of PEP 8001 were hashed out; it was then discussed with the core developer community. PEP 8001 was made "active" on October 22 by Łukasz Langa based more or less on consensus among the core developers.

As with almost all of the public discussion on the governance PEPs, the PEP 8001 discussion was held using the Python Discourse instance. As we reported in mid-October, Python is experimenting with Discourse for conversations that normally would have taken place in the core-developer-only python-committers mailing list. For the most part, the conversation has moved to Discourse, as was requested in order to truly experiment with that communication medium.

Based on PEP 8001, the vote will be done using instant-runoff voting (IRV); voters must rank all of the options from one to six (assuming no change in the number of entrants before the vote) in preference order (with one being the highest). If there is not a majority for one of the options, the lowest vote-getting option is eliminated and the second choice is used from those ballots; that process is repeated until one option achieves a majority.

All core committers are eligible to vote, though there is a request that inactive core developers, who intend to remain inactive, abstain. It is completely voluntary, but is meant to allow inactive developers "to assess their skin in the game" before deciding whether to vote. The vote will be held for the two-week period of November 16-30. Votes will be collected in a Git repository. Obviously the results will be made public, but, in addition, the actual rankings made by each voter will also be public after the vote.

Most of the discussion of PEP 8001 centered on some possible deficiencies of IRV and the possibility that voters could "peek" at other votes to try to game the vote with tactical voting. In the end, most seem comfortable that IRV will give the project a governance structure it can live with and IRV is easier to explain and discuss than some of the other options. While it is true that voters could peek, concern about it is not widespread. As Gregory P. Smith put it:

However, Donald Stufft pointed out that "tactical voting", itself, is not necessarily a bad thing. Stufft advocated the STAR voting system as well as ways to keep ballots secret. In the end, though, simplicity seems to have won out; Brett Cannon summed things up by noting that not encrypting the ballots is far easier (and "I personally don't care even if people do peek"). There was no real groundswell of support for STAR either, he said. A few days later, PEP 8001 was "approved".

GUIDO

PEPs 8010 through 8015 make up the proposals that the core developers will need to choose between. Once the new governance structure is picked, it will be enshrined as PEP 13. Given that Python has had a BDFL for its entire history, until now, it probably does not come as a surprise that one of the proposals, PEP 8010 ("The BDFL Governance Model"), would continue that role, though it does not name a BDFL. Like with other proposals, another election would be needed to fill the position.

PEP 8010, which was authored by Barry Warsaw, would replace the BDFL with another, rather familiar looking acronym, GUIDO, which stands for "Gracious Umpire Influencing Decisions Officer"—a bit of a stretch linguistically perhaps. The PEP describes the role of the GUIDO and how they are elected, for how long, and, even, how they are replaced if the community loses faith in them. It notes:

The GUIDO would be nominated and seconded by the core developers and chosen under the same scheme described in PEP 8001. They would serve for roughly four-and-a-half years (which is three Python release cycles under the current cadence); they could run again as many times as they wanted. The GUIDO will serve with an elected Council of Pythonistas (CoP) who will provide counsel to them as well as serving as a check on their power. A unanimous vote of the three-member CoP can cause a project-wide confidence vote on the GUIDO to be held.

The main role for the GUIDO is "to provide an overarching, broad, coherent vision for the evolution of the Python language, spanning multiple releases". They would also be the ultimate authority for deciding on PEPs, but they can delegate that authority to another, as was done under Van Rossum. They also have broad powers in terms of determining what is "PEP-worthy", shutting down unproductive discussions on the mailing lists or elsewhere, and in resolving other kinds of disputes. For day-to-day operations, though, the GUIDO would be uninvolved—for the most part Python hums along without any need for a dictator—which is also as things were under Van Rossum.

The discussion of the PEP has been somewhat sporadic. There are clearly some who are uncomfortable with the idea of a single person's "vision" (other than, perhaps, Van Rossum's) ruling the language going forward. There were also some comments about wording and the like. As with the other proposals, people are generally not posting positive comments; instead the comments are either seeking clarification or are critical of some aspect (or the whole thing).

Trio of Pythonistas

PEP 8011 ("Python Governance Model Lead by Trio of Pythonistas") on the other hand, replaces the BDFL with a "Trio of Pythonistas" (ToP or simply Trio), who are tasked with making the final decisions for the language. It does not name any members of the Trio but describes how it would be formed. Instead of electing three separate core developers to the Trio, slates of three developers would be nominated; each core developer could then vote for their favorite slate, with the slate receiving the most votes being elected as the Trio. In the discussion, it was stated that a core developer could be a candidate on multiple slates.

The goal is to get three core developers with a similar vision for Python, but potentially with different skill sets that would complement each other. Much of the PEP is marked "open to discussion", including the term of service, which is open-ended. If a single Trio member needs to step down for some reason, they would be replaced, but it is not yet specified how that would be done. The Trio as a whole is asked to give one-year's notice before it disbands or retires; at that time, the community can reflect on how successful the Trio model has been. If desired, an entirely different governance model could be chosen at that time. In some sense, that is inherent in all of the proposals, since new PEPs can always override older ones, but PEP 8011 is the only one that explicitly calls out the idea of "refactoring" the governance.

There is a whole list of things the Trio is meant to do (and a list of things that are not responsibilities for the group), but much of that boils down to handling PEP acceptance. To a large extent, that is where the rubber hits the road in Python governance; no major change is made without a PEP being accepted that describes the change. Whoever controls the PEP process controls Python, its direction, and its future. There are other things that Van Rossum did (and would be part of the Trio's responsibilities), such as setting a good example in terms of behavior and tone, but PEP pronouncement is where the power lies in the Python community.

So far, much of the discussion about the Trio proposal was focused on the requirement that Trio members also be voting members of the Python Software Foundation (PSF). Several felt that the requirement might lead otherwise-qualified developers to not run for the Trio, so it was suggested that PSF membership not be required.

Community governance

PEP 8012 ("The Community Governance Model") is based on the governance models of several large open-source projects, some of which were described in PEP 8002 ("Open Source Governance Survey"). In particular, Rust and Django are both governed by the "community model" and were outlined in PEP 8002; ECMAScript and C++ are similarly governed (according to PEP 8012) but were not part of that governance survey.

The basic idea is to have special interest groups of experts that form around specific areas of the language and, effectively, have veto power over any changes in those areas. PEPs can be put forward in a "final comment period" by unanimous consent among the experts, along with a disposition (accept, accept provisionally, reject, or defer). That period lasts 14 days and gives any stakeholders a final chance to raise objections.

If a core developer thinks that a PEP in its final comment period should be rejected instead of accepted, they can call for a vote. If more than one-third of the non-dormant core developer population vote to reject, the PEP is rejected. On the other hand, the only recourse to overturning a rejection by the experts is to disband the team of experts, which requires a two-thirds supermajority of the non-dormant developer population—as does removing a core developer from the project. The intent is that these developer-wide votes would be rare; certainly something has gone awry if they are frequent.

Developers can assign themselves to an existing expert team with unanimous consent among the existing members. PEP 8012 is one of the few proposals that has a mechanism for adding new core developers. Only one negative vote is enough to keep a nominated person from becoming a core developer. This "blackball" mechanism was questioned in the discussion of the PEP, but it is considered to be integral to the trust model of the community governance by Langa, who is the author of the PEP.

One interesting note that came out of the discussion is that Langa suspects that language changes like PEP 572 ("Assignment Expressions"), which led to the "PEP 572 mess" and, ultimately, Van Rossum's resignation, would probably not get accepted in a Python governed by PEP 8012.

External council

PEP 8013 ("The External Council Governance Model") is one of the more distinctive proposals. It would add a "Council of Auditors" (CoA) that is specifically made up of two to four people who are not core developers. As with the other proposals, much of the responsibility that the CoA has is to decide on PEPs. The CoA would be elected for the duration of one Python release cycle, but members could run again as often as they wish.

There is a voting process, where nominated and seconded non-core-developers are added to the python-committers mailing list to introduce themselves and explain why they are interested in being part of the CoA. Once the feature freeze of a release approaches, voting opens and core developers can vote for as many candidates as they like; the first-place candidate becomes the president of the CoA and the next nominees that get more than 50% of the vote (up to three) are members. Any ties are resolved by the release manager of the following release (the one for which the CoA serves).

There is also a no-confidence voting process that allows core developers to nominate CoA members to be removed; they can also nominate PEPs that should be reverted as part of the no-confidence vote. Any of those that are seconded are voted on after the CoA members are given seven days to respond to the "charges". After that, voting takes place over the next seven days; more +1 votes that -1 votes is sufficient to effect the change.

As might be guessed, much of the discussion surrounded the requirement that CoA members not be core developers. It was seen as somewhere between counter-intuitive and insulting to suggest that external people who are not core developers could be the ones to decide on language features going forward. PEP 8013 author Steve Dower clearly sees that as a benefit and is confident that well-respected (and known) people can be found for the CoA, but others are not so sure.

Commons

In some ways, PEP 8014 ("The Commons Governance Model") is similar to PEP 8013. In fact, Dower said that he would be happy to adopt parts of it into PEP 8013. The main difference is that the "Council of Elders" (CoE) proposed by PEP 8014 would allow core developers as members, unlike PEP 8013's CoA. PEP 8014 author Jack Jansen is aiming for "as few procedures, defined terms and percentages as possible"; he would have called it "The Anarchist Governance Model" if "anarchist" did not have such negative connotations to some.

Given the aims, it is not surprising that there is a fair amount of hand-waving in the PEP. The overarching idea is that the CoE of 5-10 people, with a diversity of backgrounds within the Python ecosystem, can determine the will of the community on any given PEP. How those persons are chosen and what kind of "emergency brake" is available to override a misbehaving council are not specified in the PEP, at least as of yet. The discussion has been largely positive; some questions about anonymity for the CoE members have been batted about.

Community organization

That brings us to the final proposal, which is PEP 8015 ("Organization of the Python community"). Unlike the other proposals, PEP 8015 sets out to formalize the current Python community organization and then to make minimal changes to the organization to reflect the changed situation (i.e. no BDFL). The goal is to "get a smooth transition from the old to the new organization".

To that end, it "replaces" the BDFL with a Python Core Board that takes over the PEP approval process. It also strengthens the existing "team" idea within Python and gives teams more autonomy. The board can delegate its PEP-approval role to teams (as is currently done with the Packaging Team) for PEPs in their areas of expertise. It can also delegate to individuals, PEP-Delegates, which are the equivalent of the BDFL-Delegates in the old organization.

For particularly controversial PEPs (e.g. PEP 572), the board can call for a vote among core developers, where a simple majority rules the outcome. The three board members would serve for three years, with one seat being up for election every year; no one could serve more than two terms on the board. The idea is to promote some turnover, while maintaining some continuity as well. Board members must be core developers and must come from from different companies (no two board members can come from the same company, including its subsidiaries).

Commonality

There is a certain amount of commonality with the proposals, which should not be a huge surprise. Python has been chugging along with few major governance difficulties over the years. Obviously, losing the BDFL would qualify, but the community seems up to the challenge of finding something new. It is also not impossible that, a few years down the road, adjustments, or even a major overhaul, will be made. The latter would be disruptive, but it would be possible to do if hiccups in the governance process are found.

One interesting thread looked at the statistics of core development. While the data is not conclusive, it does seem like there has been a downturn in the number of commits over the past six years or so. That might indicate that the language is settling into a stable phase, where large changes are not really on the table. If that is the case, much of the hand-wringing around things like PEP 572 may not be much of a factor moving forward.

It would be difficult to handicap the different options at this point—or perhaps anytime before December 1. Four of the proposals (8010, 8011, 8012, and 8015) do not stray all that far from well known and understood models, either for Python or other projects. Certainly adopting the BDFL model would largely be status quo ante. PEP 8015 does not change things all that much either. The two wild cards may be PEPs 8013 and 8014 (or some combined version of them); both would upend much of the existing structure in ways that are not all that formally specified. It will be interesting to watch and see where it all goes; stay tuned.