Brett Cannon: An update on Python's governance

This post is meant to act as a summary of the current state of Python's governance as of the end of 2018. If you want to see an alternative take on what I present here, LWN has an article.

What did Guido provide us?

When discussing how the Python project used to run, you need to understand what services our BDFL, Guido van Rossum, provided us on the core team.

Design guidance

From the language perspective of the project, Guido ultimately dictated the "feel" of Python, typically through the PEP process. Sometimes Guido would delegate decision powers on a PEP to what is known as a "BDFL delegate" (and what has slowly been renamed a "PEP delegate"). But other times Guido himself would take on the role of whether a PEP would be accepted or not. But regardless of whether Guido or someone else was making the final decision, Guido would often provide feedback on a PEP which provided guidance to the rest of us on what he was thinking about a topic.

Guido would also espouse his opinion on occasion, implicitly communicating how he felt the language should feel. This could be anything from shutting down conversations on python-ideas which he felt were dead-ends to simply commenting on something. Either way, Guido communicated in various ways about what should be considered Pythonic as his brain has the closest definition of what that truly entails.

Project lead

Guido also provided a backstop position for all decisions regarding the project. If there was ever a disagreement, Guido could step in and make it be known what the resolution would be and that was that. Granted that didn't happen very often (day-to-day running of the project hasn't needed Guido for quite a long time), but it did provide some form of stability to know that there was a higher power to appeal to in order to reach a final decision when it came to the project itself.

On July 12, 2018 ...

Up until 2018-07-12 the role Guido played was what was discussed above. But then we got a fateful email one morning from Guido where he announced that he was taking an indefinite vacation from being the BDFL (although in my opinion I view the "FL" part of "BDFL" as true and still consider Python to be Guido's language, he's just letting others run things even more now on his behalf). When Guido announced his retirement he also said that he was not going to make any final decision about how we as a group were going to govern ourselves moving forward, and so we had to figure that part out on our own.

How we dealt with the problem

We quickly decided as a group that we would solicit PEPs that proposed how to govern ourselves and that we would vote on which one to accept. We accepted PEPs up until November 01 (although that was not the initial date as things slipped), and then voted December 01 - 16 (once again, later than planned due to things slipping).

In the end we ended up with 7 governance proposals. They varied from an elected dictator structure to anarchy. Since we know the result of the vote I'm not going to go into each of them (I'll discuss the results later).

As for voting, we came up with PEP 8001. We ended up using a ranked ballot and the Condorect method to determine the winner (there's a couple ways to calculate the winner using the Condorcet method, but the winner won regardless of method details so specifics don't really matter here). Voting was open to all core developers as we couldn't come up with a reasonable criteria that we all agreed to as to what defined an "active" core dev and we kept it to core devs since they would be the most impacted by the results of the vote.

And the winner is ...

In the end PEP 8016, the steering council proposal, won. The details of the vote are available, but the key thing is that the PEP clearly won no matter what way you calculated the winner and it was a decisive win against second place. Out of 96 eligible voters we had 62 votes cast, and so I feel there's no real questioning of the legitimacy of the outcome of the vote (which we worried about since we didn't want to give people a reason to complain about the outcome's legitimacy).

So what does PEP 8016 give us? The PEP is heavily modeled on the Django project's organization (to the point that the PEP had stuff copy-and-pasted from the original Django governance proposal). What it establishes is a steering council of five people who are to determine how to run the Python project. Short of not being able to influence how the council itself is elected (which includes how the electorate is selected), the council has absolute power. But the PEP does say the expectation is that the council will work to minimize having to do anything, essentially devolving power as much as possible when reasonable.

But it's the council's mandate which really defines what they are supposed to do. Remember earlier where we said that Guido acted as a project lead and language designer? Based on what PEP 8016 says, the council directly provides us the former, but not the latter. That means the result of the vote prevents us from ever having the Python project be leaderless again, it doesn't directly solve how to guide the language's design.

My guess is the vote turned out this way because PEP 8016 was most people's second or third choice. So when people split between PEP 8011 and PEP 8012, most people seemed to agree on PEP 8016 as their alternative. And I think people did that as a way to potentially still get the approach they prefer.

What's next?

The next step is we elect the council. It's looking like nominations will be from Monday, January 07 to Sunday, January 20 and voting from Monday, January 21 to Sunday, February 03.

After the election the council will start figuring out how the Python project is going to function. Implicitly that also includes figuring out how the design of the language will be handled. That already doesn't seem to please some people who have PEPs they want to be pronounced on as that whole process will have to be chosen before any pronouncement can occur.

But a key point I hope people understand is that while we solved the issue of project management that stemmed from Guido's retirement, the council will need to be given some time to solve the other issue of how to manage the design of Python itself.

from Planet Python
via read more