Straw poll: Which governance proposals do you like best?

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.

There is also such tension :slight_smile: Python stability vs getting new hires.

I think so. I know it will change my view of approving new core developers as it adds another dimension to the consideration of what makes a good core developer.

Yep, the PEPs that shift to voting for PEPs may put us in a sticky situation of being more selective but then not promoting fast enough to keep the project alive.

I think a better way to think of 8010 is as a project-wide technical leader. The ‘L’ was aspirational anyway, and while the ‘D’ might have been true, it’s because we all trusted Guido’s intuition, which I guess is obvious given how long so many of us have stuck around.

Huh, it actually never occurred to me that that was “extra baggage”. To me, determining who was a core dev, and what that meant, is obviously part of what Guido did and what we need to do to replace him.

Our current process for promoting a core dev is pretty informal, right? Which is fine for easy cases where everyone agrees that someone’s ready, or everyone agrees that someone’s not ready. But sometimes there are borderline cases where there are some +1s, and some -1s, and there are more +1s then -1s, but no-one’s exactly sure what the threshold is. Right now, those cases are effectively resolved by Guido, either directly or indirectly (e.g. someone declares what they think the resolution is, and he doesn’t object). I can’t speak for the other PEPs, but at least for PEP 8016 the reason there’s a process for promoting core devs isn’t because we’re ambitious to change things, it’s because we thought we needed something written down that didn’t rely on Guido.

@pf_moore: if one of these ambiguous cases comes up next year, what do you think should happen?

This also makes me realize I’m a bit unclear on how PEP 8010 and 8011 handle these cases. Right now, I think we all agree that Guido has at least the following powers:

  • Pronounce on PEPs
  • Decide whether a particular decision requires a PEP
  • Decide whether or not an alternative implementation is really Python
  • Add people to the core team, remove people from the core team, change the process for promoting people
  • Make decisions about special cases, like giving someone bpo permissions without commit permissions, or giving commit permissions but only for the docs
  • Change the rules for the governance itself, or for any of the above

The text in PEP 8010 and 8011 makes clear that their leaders can pronounce on PEPs. And originally, PEP 8010 used language like “dictator” that made me assume that everything Guido could do carried over. But I’m not sure! @barry, can a GUIDO do all of the things above, or if not, then which ones? @Mariatta, can a trio do all of the things above, or if not, then which ones?

Well, this kind of concern is exactly why I think discussion is important :-). I think the most productive way to discuss is to act like the PEPs aren’t entirely frozen – obviously we are reluctant to change them now, but it’s better to have a free-ranging discussion and then decide not to change them, than it is to miss out on a critical change that would get broad consensus except everyone was too nervous to bring it up.

I guess that’s true, but even the proposals that don’t ask core devs to vote on PEPs, do still require the core devs to vote on something. For PEP 8016 we were trying to be as minimal as possible – the only hard-coded thing that core devs do is vote for the steering council [Edit: or for changing the governance doc] – but that’s still enough that you need to know who the core devs are. (Cf. the confusion we’ve had with PEP 8000 trying to figure out exactly who gets to vote.) For PEP 8010, core devs still vote in GUIDO and CoP and no-confidence elections, so we still need to have a definitive list of core devs somewhere, and some kind of process for maintaining that list.

FWIW IME the challenge with promoting new contributors is usually convincing them that their opinion is valid and worth expressing. Most people are really worried about overstepping their authority and messing things up.

I always viewed that as something the core devs did for themselves (although I agree, there was always “unless Guido objects” as a safety net previously, but I never really had a sense that he felt a need to keep an eye on the core dev promotion process.

Well, I’d take the view that as with anything else, if we don’t have a clear consensus, status quo wins (i.e., the default is let’s not promote someone right now, but wait a while). Sure, that means that it’s a little harder to get new core devs, but there are other aspects of the various proposals that have that problem (e.g., see my other comments in this thread), and anyway I’d personally prefer we had a high level of trust in each other, which means people getting in on a borderline decision probably isn’t the right thing.

2 Likes

I actually don’t agree that list is what Guido actually did. For instance, I have never ran by Guido any time I have given someone tracker permissions. Nor do I think he has ever really stepped in to formally specify how we choose a core developer (our current approach kind of just happened).

In regards to PEP 8010 and PEP 8011 in this regard, I assume some PEP would go up if there was a need/desire for such formality, otherwise the usual discussions and agreement among ourselves would be reached.

  • Pronounce on PEPs (expected responsibility of the trio)
  • Decide whether a particular decision requires a PEP (expected responsibility of the trio)
  • Decide whether or not an alternative implementation is really Python (I don’t actually know, I don’t have much opinion about this)
  • Add people to the core team, remove people from the core team, change the process for promoting people (not expected of the trio)
  • Make decisions about special cases, like giving someone bpo permissions without commit permissions, or giving commit permissions but only for the docs (not expected of the trio)
  • Change the rules for the governance itself (not expected of the trio, unless there’s a PEP about it)

PEP 8011 has the following guidelines: under succession planning heading:

Since future trio will be chosen out of Python core developers, it will make sense for future Python core developers to possess some but not necessarily all, qualities of the trio as laid out in this PEP.

Brett’s comments on leadership / voting / change / vision

You should take my intuitions with a huge grain of salt, but fundamentally our sample size for successful BDFLs is too small for anyone to know what works. But my intuition is that there’s leadership, there’s technical chops, and then there’s the kind of hybrid-sociotechnical-leadership that successful BDFLs show, and it’s kind of a third thing entirely. It’s about things like “what should I say about this problem that I don’t really understand, that will cause the experts discussing it to discover a better technical solution than they would have otherwise?” Absolute witchcraft.

Yeah, there are cases where voting is the right thing, but it’s just one tool, and it really doesn’t replace doing the hard, informal work of talking to each other and working things out. Here’s a giant block quote from Karl Fogel’s excellent book on F/OSS development, because it’s all so relevant that I couldn’t figure out where to trim :smile::

In general, taking a vote should be very rare — a last resort for when all other options have failed. Don’t think of voting as a great way to resolve debates. It isn’t. It ends discussion, and thereby ends creative thinking about the problem. As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes. This happens surprisingly often: a lively debate can produce a new way of looking at the problem, and lead to a proposal that eventually satisfies everyone. Even when no new proposal arises, it’s still usually better to broker a compromise than to hold a vote. After a compromise, everyone is a little bit unhappy, whereas after a vote, some people are unhappy while others are happy. From a political standpoint, the former situation is preferable: at least each person can feel he extracted a price for his unhappiness. He may be dissatisfied, but so is everyone else.

Voting’s only function is that it finally settles a question so everyone can move on. But it settles it by a head count, instead of by rational dialogue leading everyone to the same conclusion. The more experienced people are with open source projects, the less eager I find them to be to settle questions by vote. Instead they will try to explore previously unconsidered solutions, or compromise more severely than they’d originally planned. Various techniques are available to prevent a premature vote. The most obvious is simply to say “I don’t think we’re ready for a vote yet,” and explain why not. Another is to ask for an informal (non-binding) show of hands. If the response clearly tends toward one side or another, this will make some people suddenly more willing to compromise, obviating the need for a formal vote. But the most effective way is simply to offer a new solution, or a new viewpoint on an old suggestion, so that people re-engage with the issues instead of merely repeating the same arguments.

In certain rare cases, everyone may agree that all the compromise solutions are worse than any of the non-compromise ones. When that happens, voting is less objectionable, both because it is more likely to lead to a superior solution and because people will not be overly unhappy no matter how it turns out. Even then, the vote should not be rushed. The discussion leading up to a vote is what educates the electorate, so stopping that discussion early can lower the quality of the result.

I actually agree with you 100% here :-). If we end up on one of the community-based systems, then we’ll collectively have to learn how to cope with that, and it’ll take real time and effort, and we’re probably going to hate it at some points. But there’s some risk like this in any system – after all, even with a quasi-BDFL model, the actual governance depends totally on who the dictator is, and we’ve never had any dictators besides Guido!

But there are lots of successful F/OSS projects where people have learned to work together effectively, and I’m pretty confident we can figure it out too. I’m less confident that we can find a New Guido. It’s a matter of weighing the risks…

I hear your worry, and this is super subjective. But to share where I’m at: even in those cases, I’m not really worried? These are complex issues, but we have a pretty solid shared vocabulary for describing our values (our traditional commitment to backcompat, the Zen, etc.), and we have lots of technical experts to work out the trade-offs of different approaches, their effect on different user communities, etc., so we can compare them to those values. The whole point of a consistent vision is that it doesn’t involve inventing new principles to answer new questions; it’s about figuring out how old principles apply to new situations.

Paul’s concern that formalizing the new-core-dev process is alienating and bureaucratic

I see where you’re coming from, but on reflection this actually bothers me quite a bit. Let me try to articulate why.

There will always be borderline cases… as long as there is some level of consensus where the person doesn’t get promoted, and some level where they do get promoted, then it’s an unavoidable mathematical fact that there is some minimum level of support where they do get promoted, but anything less would have failed, i.e. they’re on the borderline.

So you can’t eliminate borderline cases. What you can do, and I guess what our current process does, is obfuscate them. If you make a crisp rule like “2/3 supermajority”, then it’s easy to tell how close any particular vote is. But if no-one’s quite sure where the border is, then no-one’s quite sure whether any particular case is borderline or not. You can say “well, if you’re not sure, then that’s on the failure side of the line”, but that doesn’t resolve the issue, it just moves it – now it’s the cases where we’re not sure whether we’re sure that are ambiguous.

Obfuscating the border like this does have some benefits; no-one likes having to lay down the law and be the bad guy and bureaucracy and all that. But it also causes real problems:

  • There will always be borderline cases, where no-one knows what to do. This isn’t a theoretical issue. IIUC, when Victor sent this email, he was actually uncertain about whether we had enough consensus to promote Pablo, and was kind of bluffing and hoping no-one would call him on it, and until Guido replied he wasn’t sure what the outcome would be. (@vstinner, correct me if I’m misrepresenting things here!)

  • And whenever you have power wielded by unstructured and unaccountable processes, then what tends to happen is that decisions get made by whoever blusters the loudest, or by invisible and unaccountable friend networks. It also makes it extra easy for bias to slip in, and for the appearance of bias, which is nearly as bad. Imagine you were a woman who was interested in becoming a core dev. You ask what’s required, and get told “well, at some point when you’ve jumped through enough hoops – we can’t tell you how many – then you’ll get judged by a bunch of dudes according to some criteria we can’t tell you, and if you meet some arbitrary and unspecified threshold, then you’ll get in; and if not, then maybe at some future unspecified point you can try again. But don’t worry, they all have a high level of trust in each other.” It’s just… ick. I also want us to have a high level of trust in each other, but I think we can do that while also having clear guidelines and articulable rules.

  • And obviously we’re not going to solve all these problems by just writing down some rule like “2/3 supermajority”. But it’s a necessary first step. If you can’t describe the process, then you can’t discuss it or change it. There’s substantial disagreement about how we should promote core devs: Łukasz thinks unanimity, Carol has suggested 50%, and I don’t feel like I know what the process actually is right now, which is a pretty disempowering feeling for me. Like I know the general outline, but all the details are based on precedent and whim, absorbed through osmosis, and I’ve only been a core dev for ~a year. I guess the people who’ve been core devs for 5+ years have a better idea, but I also bet they don’t all agree. (And how ridiculous is it that someone can be a core dev for a year and still not know this basic stuff?) But if we refuse to codify anything then this is what happens – it squashes discussion.

And BTW, having a formal criterion like 2/3 supermajority is totally compatible with talking to each other, it’s really not either/or :-).

Authority of leaders to rule on non-technical matters

I would not assume that just because Guido didn’t say anything, that means he wasn’t paying attention :-). I bet if he disagreed then you would have heard from him!

And you can’t tell me Guido didn’t have some direct intervention here :slight_smile:

Thanks @Mariatta, that’s helpful! And to be clear: “not expected” here doesn’t just mean “they can ignore it if they want to”, but rather means “if there’s a debate arises, they don’t have any special authority to resolve it”, right?

And then PEP 8011 also has a kind of blank check for falling back on PEP 8001 to resolve edge cases:

It is allowed, and perhaps even expected, that as experience is gained with this model, these parameters may be tweaked in order to provide for a smoother governing process. The process for tweaking these parameters will generally be the same voting process as described in PEP 8001.

Which I’m guessing would also apply to resolving any debate where the trio doesn’t have authority?

1 Like

I would like to put rules of core dev promotion because the usual number of votes is between 5 and 10. Every vote has a strong power. And it’s also common to get -1 votes. It’s also important to decide how “null votes” (vote “0”) and “-0.5” or “+0.5” votes are handled, when you have such low number of votes.

Some examples of recent votes (in the last 2 years); I counted +1 vote for the core dev who proposed the candidate:

As Nathaniel, I wasn’t comfortable when I decided to promote candidates when there were “-1” votes, since we had no written rules. Does it mean that I ignored the opinion of core devs who votes "-1? Or is it part of the vote to have +1 and -1?

For me, the major thing I’m wary of in the governance proposals is anything that increases the burdens on regular core developers beyond what I think is reasonable to request of a volunteer participating in their own time. A lot of that view is purely selfish (since I fall into that category these days, whereas I got a fair bit of paid upstream time to spend as I wished while working for Red Hat), but part of it is also about avoiding raising the barriers to core development so high that the only way to climb them is to be paid to contribute.

So for me, that rules out PEP 8012 (primarily due to the weird clause where folks have to seek permission from other core devs in order to withdraw from an interest area, but the PEP as a whole just reads as “more work for core devs than I’m personally prepared to take on” to me, even if it isn’t intended that way).

It also rules out PEP 8014, since that pushes a lot more decision making down on to votes of the entire core development team, which strikes me as worryingly similar to the original “everyone votes on everything” model used in the PSF that was ultimately replaced by the formal PSF Working Group model (where folks could opt in to voting for the things they cared about, and everyone else was only asked to vote in the annual Board elections and for changes to the by-laws).

For the rest of the proposals, I don’t think that much would actually change in the day to day experience of a core developer, so they all manage to pass that hurdle.

PEPs 8016 (Steering Council) and 8015 (Python Community) both feel like they’re staking out different positions on a Steering Council model, and my preference between them is for 8016, as I think it gets the balance between over- and underspecification right, whereas 8015 attempts to specify things that don’t need to be covered by this governance vote (like how we interact with the PSF’s Code of Conduct committee, which I think is independent of technical governance).

PEP 8011 is actually my favourite proposal, as I think it would end up being pretty similar to a PEP-8016-style steering council in practice, but with one key difference: the use of ticket voting for council elections (such that you vote for an entire council at once), rather than electing individual council members. That’s a really interesting idea to me, since it allows for deliberate construction of tickets that have particular properties (e.g. at least one newer core dev, at least one veteran core dev, at least one core developer that’s also active in the Scientific Python community, etc), such that folks can vote for the ticket that they feel offers the most appropriately balanced set of perspectives, rather than voting for individuals and then hoping the end result will still represent a reasonably broad cross-section of Python community perspectives. It also provides an interesting way of managing the corporate influence question, as I suspect folks would be wary of voting for tickets where even two of the candidates worked for the same organisation, let alone all 3 of them.

I think PEP 8013 is an interesting idea, but I also think we already have a relatively independent oversight body in the form of the PSF Board, so I don’t think we need another one at the technical steering council level. (Yes, the Board stay out of technical decision making, but the control they have over resources and infrastructure gives them significant leverage to intervene if our collective management of the core development process were ever to get so far out of whack that they felt obliged to step in)

Finally, while I think it’s good that PEP 8010 is an available option so folks can vote for perpetuating the status quo if they really want to, I think it would be a genuinely missed opportunity to switch to something more sustainable if we went that way. I don’t know yet if I’ll rank it below “Further discussion”, but I might :slight_smile:

3 Likes

I think that’s a reasonable concern. I think that most PEPs should be able to be decided, not by popular vote, but by a duly-appointed PEP delegate and/or a small group of experts. Still, a minority of PEPs (e.g. PEP 572) would require popular vote, because there’s no such thing as expertise when it comes to decide on general language additions.

I disagree with the idea that we are used to it. Someone else (I’m sorry I don’t remember whom, perhaps @pf_moore ?) already pointed this out: how a BDFL-led community functions is very much a function of the BDFL’s personality, personal style, and level of involvement. Just because I know how python-dev worked with Guido as BDFL doesn’t make me aware of how it would work with X or Y as BDFL.

I am not saying that it would work less well, by the way. Just that it is unknown as far as I’m concerned. So I might as well want to try a more scalable model that doesn’t depend on a single person being 1) benevolent 2) extremely available and dedicated 3) competent enough on a large range of aspects 4) able to withstand much increased social pressure without burning out 5) other factors I might overlook ;-).

I am uncomfortable overspecifying every little detail about what the GUIDO can and cannot do. I think it constrains us and the next technical leader too much. An important job of the GUIDO is to resolve disputes when no other means of consensus can be reached. That should be the lens through which you answer these questions.

1 Like

My intent is to explicit that core developers and the Steering Committee must respect the Code of Conduct, and that the PSF Conduct Workgroup has the authority to ban temporarily a core developer. My main motivation to mention Conduct WG is to add the rule that a ban causes a core dev to loose their status: Special Case: Ban a core developer… I’m not sure if it’s something new or not, since no core dev has been banned temporarily yet :slight_smile:

@ncoghlan: Do you disagree with giving the authority to the PSF Conduct Workgroup to (indirectly) remove the status (“commit bit”) of a core dev? Or do you just dislike to have a copy of the workgroup charter in a governance PEP? (link into my PEP 8015: Charter).

I chose to describe how contributors become core devs and how core devs may move back as regular contributors (loose their status), since the core dev status becomes even more important than previously with my PEP 8016. Mostly, because the Steering Committee can decide to use a vote open to all core devs for major change in Python.

See earlier posts in this thread, Straw poll: Which governance proposals do you like best? - #20 by brettcannon.