Straw poll: Which governance proposals do you like best?

This is a straw poll about which governance proposals people are leaning towards currently. Please note:

  • The results here are completely non-binding; the goal is just to spur discussion. Participating here is totally optional.
  • The real vote will be anonymous; this is not.
  • In the real vote, you will have only one chance to vote and can’t change your mind after; in this vote you can update your answer as often as you like.
  • The real vote will let you rank the options from best to worst, but Discourse doesn’t have that as an option, so instead we have a multiple choice; you can pick however many you like.
  • You’re encouraged to post below with more details, like your actual ranking, and what you like or dislike about the different proposals.

So… which proposals do you like best?

I’m not comfortable with Barry’s PEP 8010 Technical Leader. It would be very hard for someone to have the same authority than Guido van Rossum who wrote Python. These days, any Python change became very controversial, and it’s harder everyday to deal with the negativity on the Internet. Multiple core developers had burnouts for example.

Last years, I also saw Guido as a bottleneck for Python changes. Some people may like to reduce changes to make Python more stable, but here it’s not a deliberate choice, but just a bottleneck issue. I would prefer to redistribute responsibilities to scale better horizontally. Well, the PEP 8010 replaces 1 people (Guido) with 4 people (leader + council), but I’m not sure that it’s enough. Some people can be unavailable for an unknown duration and don’t know anything about a topic. It’s hard to know everything in Python, Python became so big and diverse in term of use cases and features!

Mariatta’s and Barry’s PEP 8011 proposes Working Groups which are very similar to Python Teams that I propose in my PEP 8015 and Experts of PEP 8012. Sadly, I’m unable to explain exactly why, but I don’t buy the whole PEP 8011 :frowning: (well, let’s say that it’s not my favorite, sorry)

For the Steve’s PEP 8013, sadly, I’m blocked early by the fact that core developers cannot be part of the council… Again, I would prefer to rely more on existing Python Teams.

Jack’s PEP 8014 is not very different from PEP 8011, 8012, 8015 and 8016, but it under-specify many things, especially the council roles (IMHO it is at the top of the hierarchy, but Jack says that it’s no, well). I would prefer to rely more on existing Python Teams / experts.

I also dislike that everyone can vote on PEPs. I fear that the vote might become a popularity vote. In my experience, some people quickly have a strong opinion, even if they don’t understand the PEP and it’s hard to make them change their mind. This is especially true for very technical changes like asynchronous generators (PEP 525). Voting on a PEP requires to deeply jump into the PEP and really understand it. I fear that many people will vote without understanding the PEP.

I chose Lukasz’s PEP 8012, my PEP 8015 and Nathaniel’s and Donald’s PEP 8016 (without preference order). While they are many differences between these PEPs, the main structure of the decision process is very similar. Mariatta’s and Barry’s PEP 8011 would be my 4th choice, but I chose to only select 3 PEP.

1 Like

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.

OpenStack has per project Technical Leads (PTLs) which are elected for a single release cycle (~6 months). I think it’s probably roughly similar to that.Though I haven’t done OpenStack in long enough I barely remember what the PTLs did.

not sure the purpose of this poll.

We went to lengthy discussions to make vote to 80xx PEPs private and anonymous and now there is this public poll.

It seems like this is just to try to convince people to vote certain way?

Anyway I have opinion about each PEPs but I will keep my opinion and vote private and anonymous and will only submit it to the CIVS system.

Is openstack community-driven in anything like the same way Python is? (I don’t have that impression, but it’s a genuine question, I’ve never contributed to openstack.)

It’s… .complicated. Or at least it was when I was there, like I said I haven’t been involved in a long time. It’s definitely not entirely corporate controlled, but most of the major contributors (at the time anyways) were being employed to work on it. The general group of people working on it do typically stand on their own in terms of what they do.

That’s totally fine of course, I’m sorry if it came across as pressuring you to do something you’re not comfortable with. Just in case I’ve edited the first post to add a the sentence “Participating here is totally optional.”

Not any particular way. I strongly believe that whenever a community can make a decision through discussion, that makes the community stronger, and when it makes a decision through voting, that harms the community. So the closer we get to a decision through discussion, the better. Plus, the more we all learn about what people’s concerns actually are, the more likely the final proposal will actually make the maximum number of people happy. (It’s very unlikely that any of us have found the optimal version of our proposal yet! That’s OK, they don’t have to be perfect, but why wouldn’t we want to make them better if we can?)

I currently am very skeptical about PEPs 8010 and 8011 myself, but I hope someone shows up to make a strong argument for them too!

I think that our inability to come up with consensus up to this point is one reason why community-based voting can’t always work. But that’s just my personal opinion.

If there was consensus there wouldn’t be a need for voting. Voting is useful precisely when there is no consensus.

Even since we started discourse, we’ve done plenty of votings (how to vote, whether people like discourse, etc) and still those votes lead to no clear consensus.

Ah, you mean those votes :slight_smile: Those are informal votes, just like when we did informal +1/-1 voting on a mailing-list.

I don’t see how these so called informal votes are going to be any different than the other “formal” votes? What makes it formal? If people tend to vote differently during the “informal” phase, then what’s the point of the informal voting? And how am I supposed to trust the process and the community going forward when some people weren’t serious in their vote.

I’m not sure I understand you. You were complaining about our inability to come to consensus. But with a decisive vote (i.e. a vote whose outcome entails a decision), the community will be able to move forward. So I don’t understand what kind of situation you’re worried about.

I’m not sure what you mean by this. In my view, we haven’t yet had an opportunity to try to reach consensus - there has been development on a number of proposals, but no overall discussion. I’m very grateful to @njs for starting this thread, as it’s precisely the sort of discussion I wanted to see, people offering opinions and concerns, with the intention of seeing what the general opinion is.

This thread won’t dictate my vote, but it will strongly inform it. I don’t have any hope that I can understand all of the nuances of the various proposals all by myself, so I’m relying on (and grateful for) the views and opinions of the other core devs, whom I know and trust from collaborating with them over the years.

Honestly - who else would I be able to talk with about how I’m going to vote, and what my concerns and opinions are?

1 Like

My sentiment about the various PEPs is close to both @vstinner’s and @njs’s.
In particular:

  • both PEP 8010 and 8011 try to revive the notion of a BDFL (or a 3-headed version thereof), which I think would be detrimental to the project
  • the idea of non-core developers governing core developers in the Python project is a no-no for me, so I’m against PEP 8013
  • the vague and potentially disruptive power given to the “Council of Elders” in PEP 8014 makes me perplex and uneasy

So I’m left with three acceptable PEPs: PEP 8012 (@ambv), PEP 8015 (@vstinner) and PEP 8016 (@njs and @dstufft), amongst which I’m currently unable to choose an ordering.

Me and PEP 8010

First, thanks for the kind words. :smile:

Ironically I have heard the exact opposite reasoning against me being elected the GUIDO if PEP 8010 were to transpire: that I can lead folks but I don’t have enough technical chops to replace Guido. So does the union of people’s opinion count? :wink:

PEP 8010 and 8011 compared to community voting

So Mariatta said:

Which led to:

For me I think the key point for the PEPs that are very community-driven is that our inability to stick to what was outlined in the voting PEP suggests running things that way might get a bit troublesome. So for me that’s a plus for any of the PEPs that have a more structured system of how things should operate with some high-order power to keep things in line. So while having a time table for voting might keep things from dragging out, it’s also a bit harder to enforce if it’s a bit less defined who’s in charge to enforce such things (which varies from PEP to PEP).

There’s also more of a “us versus them” mentality when things are decided by votes (even with anonymous ballots people will know in general how people voted so it won’t really be unknown). Under Guido we seemed to be reasonably good at saying to ourselves, “well, that decision was made, so that is that”. But with voting it won’t be like that and people will end up taking sides and it will start to be obvious who is driving the language a certain way and that may lead to some bitterness because those people voted that way. Now it’s also quite possible it won’t work this way as much as people being just a bitter towards a single or triple of people, but I know for me I don’t expect things to necessarily run smoother if we are suddenly voting on everything after how things have gone down recently.

“Trying out” new governance models

That can also swing the other way of testing a new governance model for us. While you can argue that PEP 8010 is unique by electing a dictator, it is what we are used to, with 8011 going along that theme somewhat. But the other PEPs are new to this group of people and we don’t know how we will take to any of them as compared to having a singular leader.

Caring about a consistent vision

Personally, I’m worried. For me, “vision” goes beyond language design. It also extends to question like “do we rework the C API for potential performance, and if so how should that look?” Or how about “in the modern era of PyPI do we cut down on the batteries in the stdlib?” I think there are still plenty of question which will come down to a vision of how things should function as a whole which extend beyond just a choice on syntax or whether we want a None-aware operator.

Having this poll

I think a lot of us are curious how others are thinking. But I do understand the worry of people using the results of such an informal poll to unconsciously sway opinion. Luckily the voting system that we landed on is designed to help fight this sort of thing, so as long as people do try to vote the way they feel and not the way some people who chose to publicly state it will vote then it should help alleviate any unconscious bias.

I personally haven’t decided if I want to participate in the poll, but I think that if I do it will be extremely broad so as to not make any other PEP I would be okay with seemingly look like it has no support.

One thing I am conscious of is that some proposals (8010, 8011 most obviously) restrict themselves to just proposing what we need to do to replace Guido, whereas others (8015, 8016) extend the discussion to cover a lot more of our processes, such as what it means to be a core dev, and how people get core dev status. Whether I agree or not with those aspects of the proposals, it’s hard to have a view on the core question of “replacing Guido” when some proposals come with extra baggage, and others don’t.

If I prefer a community-based approach to core governance (PEP decisions, language direction) but hate the idea of changing the process for promoting a core dev to require a formal vote, where does that leave me?

Does anyone else share this concern, or are people just looking at the whole package with each proposal and considering whether they are comfortable with it as a whole?

1 Like

I’m personally taking the latter view.

I think one thing to keep in mind is the PEPs that are taking what I would consider a more drastic shift of moving us towards a commons/voting model should be caring more about who becomes a core developer. As I have said before, when I have previously shown support for people becoming a core developer it has not been based on how I thought they might vote on a PEP. But with the governance models that have us all voting on PEPs I think it will make it much more important to consider whether the person will want to take the language in a direction you agree with versus whether you think they can help out and follow our norms for when e.g. something is an acceptable compatibility break. IOW the PEPs that are moving us towards voting are making being a core developer much more important and so it doesn’t seem too crazy to then also need to pull in potential changes in how core developers are chosen.

Interesting point. Does that also mean that there’s a pressure to not give out core developer privileges quite so freely? One possible downside of such proposals would therefore be to add a tension between wanting more core devs to give us more manpower, vs having to be more cautious about the powers we’re granting.