Right now, my ranking is: 8016 > 8015 > 8012 > Further discussion > everything else.
Rationale for the low-ranking ones
PEP 8013: the core idea here is to elect a council of independent non core devs to serve as neutral arbitrars. The governance geek in me thinks this is exciting and interesting. I have no idea if it would work – AFAICT no F/OSS project has ever used anything like this. But I think this is a bad time and place to try new and exciting things that no-one has ever tried before! I’d be all for trying it out in a limited way (e.g. on one PEP), but switching directly to this as our one-and-only way of working, starting now? No way.
PEP 8014: …I was going to say that it’s way too vague, but looking at it again now apparently Jack added a bunch more details last week, so actually I need to re-read more carefully it before I’ll know what I think!
PEP 8010 and 8011: The core idea in these is similar: they believe that Guido’s consistent, unified vision has been crucial to Python’s success, and so their primary goal is to avoid “design by committee”. Therefore, they propose that we elect either a single leader (8010) or a trio of leaders (8011) whose job is to take ultimate responsibility for all design decisions over a ~5 year period.
I have a few concerns here.
First, I’m personally not really worried about the consistent vision issue. If Python were a brand new language, then yeah, having a strong leader inventing the vision would be valuable. But that’s not where we are. Python already has an established, consistent set of design principles. At this stage in its lifecycle, the goal is to preserve that vision, not invent a new one. And everyone on the core team has spent years or decades absorbing that vision. Together I think we can be trusted to preserve Python, probably more so than any individual or trio.
Second, I’ve never heard of another community-oriented open-source project using a model like this, with dictators-who-are-elected. Founder-as-BDFL is common, community-governance is common, but these two PEPs strike me as a kind of mutant hybrid that AFAICT has never been seen before in the wild. In some ways it feels like the closest analogues are the governance systems for commercial projects (e.g. Google appointing a new BDFL for Golang), but that’s a pretty different situation as well. And as noted above, I’m not a big fan of testing new governance models “in prod” on CPython.
Finally, and this is the big reason: I’ve been a BDFL for much smaller projects than CPython, and my experience has been that it’s incredibly hard and scary. It’s a completely different thing than being a regular contributor. You have to constantly watch what you say, because people read things into random comments. It demands this extraordinary mix of technical and people skills, where you have to not just deeply understand the design landscape, but also guide discussions productively, manage everyone’s emotions, walk the tightrope between trusting your own intuition too much or too little, and keep contributors happy. For a project like CPython, you have millions of people judging you constantly, and every complaint is ultimately Your Fault. There is no guidebook – literally, since so few people end up acting as BDFLs for large projects, and the people who do all follow such idiosyncratic paths to get there, there are no tutorials or guidelines or accepted wisdom or anything, you’re on your own figuring everything out. We don’t know what makes some people like Guido succeed and others fail, because only a tiny tiny fraction of people succeed. Only like 0.001% of projects succeed like Python. (Made up number, but that’s about the right order-of-magnitude.)
And… actually it’s worse than that, because Guido was doing it on easy mode: he had 25 years to grow into the role, and to build up an immense store of trust from other contributors. Anyone trying to step into his shoes now has to somehow jump straight into that role from a standing start, and they have to do it while walking the additional tightrope of providing their personal vision while keeping in mind that if they do anything too extreme then the core devs will stage a coup and depose them, in a way that Guido never had to worry about.
I think Brett is very courageous to be willing to stand for the PEP 8010 technical leader. I’ve been impressed by Brett’s contributions to Python. I have absolutely no idea whether Brett would make a good leader in the PEP 8010 sense, because it’s a completely different skillset. And that goes for any other potential candidates too. With PEP 8010 I feel like we’re trying to decide who to fly a 747, by voting, and none of the candidates have a pilot’s license. Maybe we’ll get lucky and pick a natural… but I don’t want to be a passenger in that plane.
PEP 8011 tries to mitigate some of these issues by spreading the load over 3 people instead of just 1. But I feel like this is just as likely to hurt as it is to help? Maybe the 3 people will have great rapport and do better than any could individually. Or maybe they’ll struggle to find consensus, and it’ll be even more stressful on the individuals than doing it alone would be. If they’re supposed to represent the diversity of contributors and users, then they probably shouldn’t be people who’ve spent a lot of time working together before, so … again, it’s playing roulette with Python’s future.
PEPs 8010 and 8011 both seem very risky to me.
Rationale for the ordering of the rest
PEP 8012 is a version of Rust’s governance, based around subject-area-specific teams, with a fallback to whole-project votes. PEPs 8015 and 8016 are based around the idea of an elected “steering council”. There are some differences in detail (e.g. the two councils are elected for different terms), but the big conceptual difference is that in PEP 8015 the council’s job is to manage PEPs following specific procedures (assigning BDFL-delegates or calling for a project-wide vote), while in PEP 8016 the council’s job is to define and evolve governance as necessary.
These three PEPs are all based on mainstream ideas that have been widely successful in community open-source projects. I think any of them could probably work. In fact, they’re not even mutually exclusive – PEP 8012 cites Django as an example of a project that uses its model, but if you look at Django’s formal governance, it’s really an 8016-style council underneath as a last resort, with a 8012-style team structure laid on top.
So, my ranking here is based more on implementation details than on big conceptual differences.
Given this, you will not be surprised to learn that PEP 8016, the one I’m a co-author on, is all about trying to get a clean, well-factored implementation :-). I won’t repeat the abstract and rationale here, but one thing I’m pleased about is that if you look at the message counts in the discourse threads, PEP 8016 has significantly more discussion than any of the other PEPs, even though it was posted much later; one of the goals was to make it sufficiently small and well-defined that it would invite detailed feedback.
I like the general ideas in PEP 8012, but if we’re going to use this model then I prefer the Django-style implementation where we choose 8016 as the core governance model and then layer the team structure on top. The two-layer approach makes it easier to adjust things over time and handle unanticipated governance issues that may arise. Also, some specific points bother me: AFAICT 8012 has no way to update the governance document itself. I dislike its decision to make promoting new core developers require a unanimous vote. And I’m personally OK with how 8012 makes all votes public, but it looks like Łukasz and I are pretty much alone in that, so it’s probably not the best thing to codify in an unchangeable document now.
Victor’s put a lot of hard work into refining PEP 8015 over the last few weeks, but it still strikes me as being a bit all over the place. Why is it formalizing the idea of “Python Users” – what does that even mean? Why is it purporting to formalize the PSF Code of Conduct Workgroup? It already exists and was formalized by the PSF; formally it’s a co-equal sibling of CPython. Why does it assign the CoC workgroup the power to ban a core dev, when handling individual CoC issues isn’t even mentioned in their charter that’s pasted right above? (And if the CoC workgroup changes their charter, does that mean we have to hold a vote to update our governance PEP?) Why does a governance PEP digress to talk about IDLE’s backport policy? (Does that mean that any future changes to IDLE’s backport policy will require a 4/5 supermajority vote, because it’s changing the governance PEP?) What do we do if we have a governance question that isn’t about whether to approve a PEP or ban a core developer? (For example: deciding whether a particular proposal is large enough to require a PEP, or working with the PSF to handle project resources.) Why is a governance PEP documenting specific github labels?
I absolutely admit that these are all kind of petty :-). But I think there’s real value in having a clean, unambiguous “project constitution”, and I think PEP 8016 does a better job of that.