Python elects a steering council

After a two-week voting period, which followed a two-week nomination window, Python now has its governance back in place—with a familiar name in the mix. As specified in PEP 13 ("Python Language Governance"), five nominees were elected to the steering council, which will govern the language moving forward. It may come as a surprise to some that Guido van Rossum, whose resignation as benevolent dictator for life (BDFL) led to the need for a new governance model and, ultimately, to the vote for a council, was one of the 17 candidates. It is perhaps much less surprising that he was elected to share the duties he once wielded solo.

The other members of the steering council are Barry Warsaw, Brett Cannon, Carol Willing, and Nick Coghlan. Other candidates and their nomination statements are available as part of PEP 8100 ("January 2019 steering council election"). Warsaw, Cannon, and Coghlan are likely recognizable names to those who follow Python development (as is, of course, Van Rossum). Willing is perhaps less-known in the Python world, even though she is a core developer, has been a member of the Python Software Foundation (PSF) board of directors, and is a core developer and steering council member for the Jupyter project.

The number of candidates for the Python steering council was rather large, especially when compared with either the eligible voter pool (96) or the number who actually cast ballots (69). Voting was restricted to active core developers, though nominees could come from outside of that set. Some concerns were expressed about allowing external nominees, but the PEP did explicitly allow core developers to nominate "outsiders". Three of the nominees were not on the list of eligible voters: David Mertz, Peter Wang, and Travis Oliphant. However, Oliphant is a former core developer as can be seen in his nomination thread. The rest of the candidates are a mix of both older and newer core developers with interests ranging throughout the Python ecosystem.

Ultimately, voters decided not to elect any of the outsiders. Part of the reason for that might have been the voting method itself, which allowed each core developer to vote for zero to five of the candidates. That is rather different than true "approval voting" where voters can choose any number of the candidates. As a thread in the Committers Discourse discussion group showed, though, that was something of an oversight. The Django election process document that was used as a starting point for the PEP that was eventually adopted (PEP 8016, "The Steering Council Model") used that scheme and no one brought up the "vote for zero to five" mechanism until after the PEP became "law". As Nathaniel J. Smith, who was a co-author of the PEP, put it:

One of the concerns that came up in the thread was that a restricted number of votes could lead to a landslide victory for the best-known candidates. In the Discourse thread, Tim Peters linked to a description of "bloc voting"—what is being used for the council election—which described the problem this way:

Coghlan thought that pure approval voting might lead to the "old guard" getting elected, though Peters's intuition led him to the opposite conclusion. So far, the full number of votes for each candidate have not been released (though it is being worked on), but voters can see those totals. In a post to the python-committers mailing list, Peters used that information to show that the landslide did seem to happen:

While it is possible that the outcome did not exactly reflect the "will of the voters", it seems likely that it will serve the project just fine for the first incarnation of the council. Tweaks to the voting method and possibly other issues with the governance model may come about over the next year or so. The current council will serve until the release of Python 3.8, which is currently scheduled for October. After that, the electorate will get another chance to choose council members.

In the meantime, though, the PEP-decision process is something that the council will need to work on. As it currently stands, there is no real mechanism to approve PEPs, which is obviously sub-optimal. Ultimately, the power rests with the steering council, but that may or may not be the path forward. The various governance proposals, as well as the discussion around them, seemed to indicate that delegating PEP decisions to the proper person might be the preferred path forward. That is not anything completely new, of course, as Van Rossum would sometimes pass his PEP-pronouncement power to a BDFL delegate.

It has been just over six months since Van Rossum stepped down. Over that time, the core developers have figured out how to choose a governance system, proposed a half-dozen systems, and voted to pick one of those. In the past month, they have nominated 17 candidates and chosen five of them to serve on the steering council. At this point, we should start to see what changes come about and perhaps get resolution on some dangling PEPs. It is not common to see a community completely change its governance in this way, so it will be interesting to watch it all play out.

To a large extent, the voters chose to stick with the status quo. Obviously, Van Rossum represents continuity with the previous regime, but the others elected were also high-profile decision makers for the language. That would seem to indicate fairly small changes ahead. What exists today, both in the language itself and in its governance, are not likely to see any radical changes, at least in the short term—which is probably for the best for a mature, nearly thirty-year-old language.