Straw poll: Which governance proposals do you like best?

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.

This answer is so diametrically opposed to everything I understand about governance that I’m struggling to even assume good faith :-(. I know you’re not someone who would try to be unhelpful on purpose, so there must be some fundamental miscommunication or something?

I’m not asking you to specify lots of little details, or be super bureaucratic or anything like that. I intended those cases as examples that you’d easily be able to answer, because I thought you had some underlying principle in mind about what the GUIDO’s role is. When there’s a dispute that comes up, it seems important to be able to ask “does the GUIDO have the authority to resolve this dispute?” and get “yes” or “no” as the answer. If the answer is “maybe, no-one knows”, then that doesn’t simplify anything, it just creates a whole new category of disputes, about whether the GUIDO’s attempts to resolve things are binding or not.

Traditionally, this was fully specified: “Does Guido have the authority to resolve this?” → yes he does, the end. It sounds like you’re saying that this is bad, and it would have been better if things had been more ambiguous, so we could have spent more time arguing about which of Guido’s decisions we were going to listen to? How would that have helped?

PEP 8016 notes ongoing Code of Conduct violations as one of the reasons the Steering Council may revoke someone’s core developer status. So yeah, I guess my concern with that aspect of PEP 8015 is specifically with separating that particular role out from the responsibilities of the Steering Council - I prefer the arrangement in PEP 8016 where the PSF Conduct Working Group would advise the Steering Council of the situation, and the latter would handle the actual ejection (similar to the way that it’s the PSF Board itself that is responsible for handing down any unilateral bans from PSF provided communication channels).

On the core developer nomination front, and the how-to-decide-on-controversial-PEPs front, I don’t think those are things we need to decide now - I’d prefer to see those as decisions that are decoupled from the basic governance structure, and can be amended through a lighter weight process than a formal governance change.

The PSF has already been through that kind of process - there were a lot of things that used to be overspecified in the foundation by-laws, such that they required full votes of the membership in order to change relatively minor details of the foundations operations. Over time, most of those issues have been eliminated, such that the Board now have relatively broad powers to decide exactly how eligibility for the different classes of membership is determined, with the by-laws only specifying the minimum scope for those classes.

So it isn’t that I dislike PEP 8015 - I just prefer PEP 8016 and PEP 8011.

Ok, I see, thanks. I don’t have a strong preference between PEP 8015 and PEP 8016 model. I wasn’t comfortable previously to give the power to revoke a status of a core developer because the Steering Committee only had 3 members. Maybe it’s now safer with 5 members :slight_smile:

But I would prefer to see opinions of others before modifying again my PEP :slight_smile:

Ok. I’m kind of exhausted by the governance discussions and I would prefer to decide for these things right now as well, rather than continuing these discussions one more year or longer… :slight_smile:

That’s not what I’m saying. There’s always going to be ambiguity in any constitution, and your questions came across to me as more hypothetical than must-answer. What I don’t want to do is put a big list of questions in PEP 8010 with specific answers, because that constrains the PEP too much.

But okay, I’m game to answer your questions through my interpretation of the PEP! (Assuming I can find your questions in Discourse’s unhelpful linear conversation mode.)

1 Like

Ahah.
(post must be at least 10 characters)

Thanks, I found this really helpful! So it sounds like the basic breakdown of authority for these PEPs are:

  • 8010: The GUIDO has a general authority to pronounce on any topic, technical or non-technical, except for changes to the governance PEP itself (ref). Underlying idea: the GUIDO is as close to a BDFL as you can get while keeping ultimate authority in the community.
  • 8011: The Trio has a general authority to pronounce on PEPs, but any other matters that might come up require a whole-core-team vote (ref). Underlying idea: the Trio’s job is to provide a consistent technical vision.
  • 8016: The Steering council has a general authority to pronounce on any topic, technical or non-technical, except that changes to the governance PEP or changes to the core team follow specific enumerated rules (ref). Underlying idea: the steering council’s authority derives its authority from the governance PEP + the core team, and is accountable to them, so it can’t change those.

We could add more to this list, but I need to run off to dinner :-).

@barry @mariatta Would you be OK with tweaking your PEPs to clarify the above? I definitely did not realize that 8010 and 8011 differed like this just from reading them…

In retrospect this topic probably should have been split into like, 3-4 different topics. I think this is largely my fault for the giant consolidated responses. I’ll try to do better next time…

I’ve said this a few times already, but the part I find most confusing is that the PEP seems to contradict itself. You seem to be under the impression that the Conduct Workgroup is a group that enforces the PSF code of conduct. But according to the charter pasted into your PEP, that’s not part of their mandate at all. It only covers things like “advise on policies”, “create supporting documents”, “develop training materials”… i.e. they figure out what the CoC should be, and then someone else enforces it. Their charter simply does not include enforcing the CoC, reviewing any individual cases, banning anyone, etc.

It’s like if you saw someone break the law, and went looking for the nearest member of parliament to pull out handcuffs and arrest them. Just because someone makes the laws doesn’t mean they’re set up to enforce them :-).

A lot of why PEP 8016 leaves “figure out how to deal with CoC stuff” as a thing for the steering council to figure out after it’s created, is that AFAICT there isn’t any existing enforcement setup we can delegate to. I think we’ll need to have some non-trivial conversations between the > ourselves

steering council, the core devs, and the CoC WG to figure out who will do this enforcement and how.

1 Like

Well, the charter is maybe outdated, but the conduct workgroup handles Code of Conduct incidents. I know that since I reported some emails the last 2 months and I got replies :slight_smile: Or maybe I missed something huge?

@brettcannon, @willingc, @thomas: do have any comment to add? (I don’t recall who is in this workgroup)

8010 actually, and except for the caveat that I don’t know whether a pronouncement about what is and isn’t Python would actually be legal or not without the involvement of the PSF, I’d say that’s a pretty accurate summary.

I wouldn’t mind approving a PR that added a top level TL;DR section. :wink: :arrow_left: that’s a @tim.one bot <wink> for the modern age.

1 Like

Incidents should definitely be reported to the Conduct WG. They can also provide advice on potential ramifications for an incident. But as of right now they don’t have explicit power to enforce anything. (Things are still being worked out in terms of whether that should change or stay an advisory role.)