1 of 29

A New Era in Python Governance

Shauna Gordon-McKeon

2 of 29

I saw this tweet recently, and I really loved it. You see, I’ve spent many years as part of the Python community without really thinking about how things run. I was just like, Guido’s the BDFL. The PSF exists. And things seem to be going fine. Sometimes it takes a kid’s relentless curiosity to get us asking, “Wait, why? What does it mean to be the BDFL? How does the PSF run? What other roles exist and how do people end up in them? How did this system even come about, and how do we change it?”
The other thing that can get us asking questions like these is a big conflict or shake up. That’s what happened to lots of folks last year, when Guido announced he was stepping down as BDFL.
This talk is going to try to answer some of those questions. It’ll be roughly chronological. I’m going to start by talking about how Python used to run, then we’ll go into what changed and how, and finally we’ll talk about things work now. So let’s get to it.

3 of 29

I made this chart to help myself understand the different elements of the Python community and how they work together. This chart represents how things used to be, say, a year ago.
One of the first things that may leap out at you here is how the Python Software Foundation and the Python language are two distinct groups with two distinct governance processes. This is something I didn’t understand myself until fairly recently. And I think part of that confusion is because Guido has been the leader of both groups, so even though they’re technically separate, people see the same person leading both and assume they’re more entangled than they are.
So: which group does what?

The PSF manages the intellectual property of Python. They’re also primarily responsible for community building and community management. For instance, they run PyCon and do a heck of a job with it. They also sponsor other conferences and meetups, run diversity initiatives, and more.
The Python language, on the other hand, is focused on developing CPython.

4 of 29

member-elected 501c3 non-profit
four types of voting members (contributing, managing, supporting and fellows) and one non-voting type (basic)
must declare intent to vote and vote regularly to remain eligible
current board chair: Naomi Ceder
current president: Guido van Rossum
next election: June 2019 (director nominations open May 6 2019)

We’re going to focus mostly on the Python language, but I want to take a moment to talk about how the PSF runs, because it’s important too.

The PSF is a 501c3 non-profit.

All non-profits have a board of directors who govern the project.

Most have self-perpetuating boards, which means boards appoint new directors. They do have a legal responsibility, but a lot of boards eventually decline into irrelevance or mismanagement because there’s not much accountability.
I could go into great detail on the problems with self-perpetuating boards but I won’t, because I’m pleased to say the PSF has a member-elected board.
That board in turn appoints a President to lead the organization, and the PSF board has appointed Guido to lead the PSF.
But it’s important to stress here that Guido’s authority in the PSF comes from the board, and not vice versa.

Because the PSF is member-elected, it’s important to clarify how membership works. There’s 5 kinds of PSF members.

First there’s basic members. Anyone who wants to can be a basic member, as long as you agree to follow the Code of Conduct, but basic members are the only kind of non-voting members.
If you want to be a voting member, you have to be a supporting, managing, or contributing member, which you get by donating to PSF or by participating in some significant way. Or you can be a Python fellow.
Limiting voting to people who’ve contributed to the Python community I think is a good way to make sure that the people who are voting on leadership have a real stake in the community.
The PSF does some other interesting things regarding voting, like requiring people to vote in a minimum number of votes in order to keep their voting eligibility for the year, again rewarding participation and encouraging sustained engagement.

5 of 29

But enough about the PSF, and back to the Python language.
So here is where we get this idea of Guido as the “Benevolent Dictator for Life” because as I just stressed, he was never in any way the dictator of the PSF, because member-elected non-profits can’t have dictators, benevolent or otherwise. Instead, he was the BDFL of the language itself.
So what does it mean to be the BDFL? In theory, it means you’re in charge of everything. But Guido actually mostly focused on higher level stuff, and the day to day running of the project was done by the “core team”.

This is the group of people with commit privileges for Python-related repositories. Anyone can join but you have to go through a period of contribution beforehand, learning the tools and the community. An existing core developer then sponsors you and reviews your commits for a while, and when the community’s ready it votes to extend you an offer to be an official core dev.

So the core developers did the day to day work of maintaining and extending Python, and Guido as the BDFL had the “ultimate say” whenever there was conflict or a need for determining the sort of long term vision. Practically speaking, a lot of how his authority was exercised was in deciding which PEPs got accepted or rejected.

6 of 29

Sidebar - what’s a PEP? PEP stands for “Python Enhancement Proposal” and its how the community makes decisions about language design, standards or processes. The most well known of these is probably PEP 8, which lays out the style guide for Python code, but there are in fact several hundred PEPs.
PEP 1 goes into great detail about what PEPs are and how they’re decided on, but the very quick version of that is:

Someone authors a PEP. If that person is a core developer, they can propose the PEP formally, otherwise they need to find a core developer sponsor to propose it.
The core developers review the PEP. To make this process more efficient, a single person is usually responsible for managing the review process and determining whether the PEP is accepted or rejected or still being discussed. Sometimes this was Guido, sometimes this was what was called a “BDFL-delegate”. That is, this was a person Guido was delegating his authority to. Sometimes Guido asked them to take the role, sometimes they self-nominated. My understanding is that there was little to no conflict around who took BDFL-delegate roles.
Anyway, eventually the BDFL-delegate or Guido himself would rule that the PEP was accepted, or rejected. There are a few other possible end-states, as you can see in this chart, like deferred, or withdrawn, but there’s no need to go into those in detail.

7 of 29

So to come back to our chart, and how things used to be, we’ve got this group of core developers who are writing code and documentation triaging issues on the issue tracker and discussing things via PEPs. Practically speaking they’ve got a lot of power themselves to make decisions but when there’s conflict, the BDFL can step in and say this is how we’re doing things. It’s a system that’s worked for many years. But it’s not our system anymore. So what happened?
Well, there was a PEP, 572. Dustin Ingram gave a talk on PEP 572 the other day if you’re interested in leaning more about the PEP itself, but the content of it isn’t important for us here. The relevant thing is that it was highly controversial, and involved a great many very heated discussions, and at the end of it all, in July of last year, Guido sent out an email saying, essentially, “I resign, you figure out what you want to do next”.

8 of 29

Who’s in charge now?

How do we decide what our governance model is going to be?

What’s our governance model going to be?

So Python was faced with the question, “Who’s in charge now?” They could have just selected another BDFL but there was no one obvious person with the trust or legitimacy or history that Guido had, who could just step into that role. So really, before they could tackle, “Who’s in charge?” they were faced with the question, “What is our governance model going to be?” But they didn’t have any way to decide that either, because Guido had always just been BDFL, and he didn’t want to unilaterally pick the new governance model. So really, before they could tackle, “What’s our governance model going to be?” they were faced with the question, “How do we decide what our governance model’s going to be?”
So there’s three layers of decision-making here. And it’s important for all communities making these governance decisions, to recognize that there are multiple levels of decision-making and not confuse them.

9 of 29

How do we decide

what our governance

model is going to be?

What’s our governance

model going to be?

Who’s in charge now?

10 of 29

How do we decide what our governance model is going to be?

Lots of intense online and in person discussions, leading to PEP-8001.

�PEP-8001 says:

How to propose models? Submitting PEPs.

Who can propose and vote? Core developers, self-selected as “active”.

How will the vote work? Ranked choice, administered by PSF.

Okay, so how did Python answer these questions? Let’s start with the first, “How do we decide what our governance model’s going to be?”

There were several months of intense online and in person conversations about this. In September of 2018 there was an in-person meeting of the core-developers in Redmond, with those who couldn’t make it in person joining remotely and conversing via threads on discuss.python.org.
But eventually they consensed around an answer, which is laid out in PEP-8001. The short version is, that people could submit proposals for new governance models in the form of PEPs, and that after [time period] the community would vote on which one to choose.

Who got to propose?

Anyone who could submit a PEP, so: core developers, or someone who could get a core developer sponsor. Practically, though, only core developers submitted.

Who got to vote? Active core developers.

PEP-8001 says “we are asking core developers to self-select based on whether the governance situation will affect them directly". I think this is a really good idea. There’s lots of research that shows that communities function better when the people most impacted by a decision have the primary say in making that decision. If you want to learn more about that, check out my recent LibrePlanet talk which I’ve got linked at the end of my slides.

How should the vote work?

There was some debate on what method of voting would be best. I won’t go into it but there’s a long thread on discuss.python.org if you’re a voting methods nerd - they chose the Condorcet method of voting, which is a formed of ranked voting, where you rank the options instead of just picking your favorite.
And it was administered by an official of the PSF, Ernest W Durbin III, the director of infrastructure. Which I think was a good way to take advantage of the fact that they had this separate but trusted body to help them when they needed someone impartial.

11 of 29

How do we decide

what our governance

model is going to be?

What’s our governance

model going to be?

Who’s in charge now?

PEP-8001

12 of 29

What’s our governance model going to be?

PEP-8002: Open Source Governance Survey

PEPs 8010-8016: The Actual Proposals

13 of 29

PEP 8010 - Technical Leader Model	elected BDFL* who serves for 4.5 years/3 releases, helped by a council of 3 people, all core devs elected by core devs
PEP 8011 - Trio of Pythonistas Model	three leaders who run as a slate, must be core devs & PSF voting members
PEP 8012 - Community Governance Model	builds off Experts Index, experts accept/reject PEPs in their domain but can be overruled by vote of core devs as a whole
PEP 8013 - External Council Governance Model	a council of auditors who cannot be core devs
PEP 8014 - Commons Anarchist Governance Model	“council of elders” decides if and how votes are held on contentious issues
PEP 8015 - “Steering Committee” Model	3 member committee, makes high level design decisions but cannot vote on PEPs, can only delegate or hold vote
PEP 8016 - Steering Council Model	5 members elected for length of release, empowered to decide on PEPs but urged not to

Then, community members submitted PEPs with various proposals:

“Technical Leader Model”

essentially an elected BDFL who serves for 4.5 years/3 releases (so a BDFR, or “benevolent dictator for release”)
helped by a council of 3 people, all core devs elected by core devs

“Trio of Pythonistas Model”

sets of 3 people who run as slates (to make sure they work well together)
must be core devs but also must be PSF voting members, interesting!

“Community Governance Model”

expands on idea of experts; Experts Index is a list of people to ask for opinions and feedback on ideas/proposals in their area
experts in an area accept/reject PEPs but can be overruled by vote of core devs

“External Council Governance Model”

creates a council of auditors, who are not core devs; goal was to put power in the hands of a neutral third party

“Commons Anarchist Governance Model”

the title of the PEP is the Commons Governance Model, but the author says they used that phrase instead of Anarchist because Anarchist has negative connotations

which, personally, makes the pedant inside me wince, because commons governance is a real thing and it’s often not anarchist, so I’m changing the name back

this one proposes a “council of elders” who conduct votes to make decisions, and are given a lot of discretion on what kind of vote is appropriate for a given circumstance

PEP-8015’s model, aka “Steering Committee” model

3 member committee who make high level design decisions but do not decide on PEPs, instead they can either select a PEP delegate or hold a vote

”The Steering Council Model”

5 member committee, elected for length of a release
can make decisions about PEPs but try not to as much as possible - they only step in when there’s real conflict

14 of 29

Points of debate

distributed vs hierarchical power
number of people in leadership roles
importance of being a core dev
formalization of process/power vs leaving things implicit
who decides on PEPs?
what happens if leadership is bad?
how much burden is being placed on core devs?

15 of 29

What’s our governance model going to be?

PEP-8002: Open Source Governance Survey

PEPs 8010-8016: The Actual Proposals

Debate!

The vote: PEP 8016, the Steering Council Model, wins.

(View the vote yourself on the CIVS website.)

16 of 29

How do we decide

what our governance

model is going to be?

What’s our governance

model going to be?

Who’s in charge now?

PEP-8001

The “Steering Council” Model

17 of 29

Who’s in charge now?

Elections were held in January.

Steering Council: Barry Warsaw, Brett Cannon, Carol Willing,

Guido van Rossum, Nick Coghlan

18 of 29

How do we decide

what our governance

model is going to be?

What’s our governance

model going to be?

Who’s in charge now?

PEP-8001

The “Steering Council” Model

Barry Warsaw, Brett Cannon, Carol Willing, Guido van Rossum, Nick Coghlan

19 of 29

20 of 29

Core Team

Steering Council

Similar to previous “core team”/“core developers”.

Membership granted by 2/3rds vote of core team and no veto by steering council.

No terms, but people who haven’t contributed in 2 years may be moved to “inactive”.

5 people.

Decides things via majority vote.

Nominated and elected by the core team.

No more than 2 employed by the same company.

21 of 29

Core Team

Steering Council

Responsible for Python project infrastructure (Github org and repositories, issue trackers, mailing lists, IRC channel, etc).

Responsible for reliability and stability of Python language, making contributing accessible & sustainable, liaising with PSF, establishing decision-making processes and resolving controversial decisions.

22 of 29

Core Team

Steering Council

Has power to accept/reject PEPs & enforce CoC but:

“The council should look for ways to use these powers as little as possible. Instead of voting, it's better to seek consensus. Instead of ruling on individual PEPs, it's better to define a standard process for PEP decision making (for example, by accepting one of the other 801x series of PEPs). It's better to establish a Code of Conduct committee than to rule on individual cases. And so on.”

23 of 29

Core Team

Steering Council

With 2/3rds vote can declare “no confidence” in individual steering council members or council as a whole.

If whole steering council voted out, a new election is held immediately.

Can eject member of the core team with majority vote of non-abstaining members of the steering council.

24 of 29

25 of 29

Going forward

What’s changing? How can you get involved?

What’s going to change?

Well, unless you’re already a Python contributor or member of the core team, probably very little will change. That being said, the governance transition is not complete. The steering council has been tasked with figuring out the details of the transition and determining whether Python’s previous processes can still work without a BDFL figure. So there may be some visible changes down the line.
If you’re interested in the work the steering council is doing, check out the steering council’s keynote from this morning.

So how can you get involved?

You can get involved by contributing to Python. Leadership of Python is drawn from and accountable to the community of active contributors, so become a contributor! There are some great resources for getting more involved, including a very detailed contributing guide, which I’ve linked at the end of the talk. Python also has a core mentors program, to provide individual mentors to new contributors, which I’ve also linked.
If you’re more interested in the community side of things, consider volunteering with the PSF.

26 of 29

Lessons Learned

make your governance structure explicit

most projects are BDFL-style by default, implicitly
no way to handle resignation, death, abuse

More broadly, I think there are some interesting lessons here for other projects who are struggling with governance.

Many project have only informal governance processes. It’s important to stress here, all projects have some kind of governance process. Just because it’s entirely at the whim of a single person doesn’t mean it’s not a governance process.

Most projects start as a single person, and as the project grows, that founder retains authority. When governance is formalized, it’s often but not always codified into the “BDFL” model. The path that Python and Guido took is really very common.

A number of projects are partly formalized. They’ll specify “who is in charge” but not “how do we change our governance model” - that foundational, fundamental level of decision-making.

So when they have to change, because someone retires or moves on, or just because their current system isn’t working, they’re at a loss for how to change.

27 of 29

Lessons Learned

make your governance structure explicit

most projects are BDFL-style by default, implicitly
no way to handle resignation, death, abuse

worried about bureaucracy? just specify that “first level” of governance

how the decision will happen
who gets to make the decision

And there’s a tension here, because if you build in explicit governance too early it can be seen as adding unnecessary bureaucracy to the project, but the alternative is often worse.

Many projects discover the need for governance processes only once there an active conflict in the community that people are deeply invested in and have chosen sides in, and that’s a much rougher place to be making governance decisions from, because then you have to make all these complicated positions from a place of mistrust.

My recommendation to projects is to get that “first level of decision-making” done before there’s any pressure or reason to change leadership. It doesn’t have to change anything about what the experience of participating in or leading the project is like, because you’re not saying anything about who governs or how they govern - just how you decide how they govern.

So you can keep your BDFL, but also spell out, if the BDFL steps down or dies or grows abusive, what happens next. For Python, that would have been the equivalent of already having PEP-8001 when Guido stepped down.
Your project’s equivalent of PEP-8001 probably won’t look like PEP-8001. But it should cover:

how the decision over what happens next will be made (vote? consensus? majority vs supermajority?)
who will get to make it (who can propose options, who can vote on options)

28 of 29

Lessons Learned

make your governance structure explicit

most projects are BDFL-style by default, implicitly
no way to handle resignation, death, abuse

worried about bureaucracy? just specify that “first level” of governance

how the decision will happen
who gets to make the decision

when changing governance, make use of existing systems of trust

29 of 29

Thank you!

Thanks to Carol Willing and Brett Cannon for answering so many of my questions!

Check out the steering council keynote from this morning.
Brett Cannon’s PyCon Canada talk, Replacing Guido
Victor Stinner’s discuss.python.org thread comparing proposals
PEP-8000, an index of governance-related PEPs
PEP-0013, the official project governance PEP
The CIVS vote to select the steering council model
Ways to get involved: Python’s Contributing Guide & Core Mentorship
Guido van Rossum’s resignation email
Governance Resources project
My Governing the Software Commons talk will he uploaded here soon