Straw poll: Which governance proposals do you like best?

[vstinner (Victor Stinner)]

@pf_moore

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 Python stability vs getting new hires.

[brettcannon]

@pf_moore

Interesting point. Does that also mean that there’s a pressure to not give out core developer privileges quite so freely?

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.

@vstinner

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

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.

[barry (Barry Warsaw)]

@njs

PEPs 8010

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.

[njs (Nathaniel J. Smith)]

@pf_moore

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.

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?

@pf_moore

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?

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.

@brettcannon

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.

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.

[pf_moore (Paul Moore)]

@njs

To me, determining who was a core dev, and what that meant, is obviously part of what Guido did

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.

@njs

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

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.

[brettcannon]

@njs

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?

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.

[Mariatta]

@njs

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?

• 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.

[njs (Nathaniel J. Smith)]

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

@brettcannon

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?

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.

@brettcannon

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.

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 :

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.

@brettcannon

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.

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…

@brettcannon

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.

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

@njs

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).

@njs

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

@pf_moore

Well, I’d take the view that as with anything else, if we don’t have a clear consensus [about whether to promote someone], 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.

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

@brettcannon

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).

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

@Mariatta

• 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 )

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?

[vstinner (Victor Stinner)]

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:

• Pablo Galindo
  • Vote: https://mail.python.org/pipermail/python-committers/2018-June/005564.html
  • Result: https://mail.python.org/pipermail/python-committers/2018-June/005621.html 10 votes in 7 days: 8 “+1”, 1 “-1”, 1 “0”
• Xiang Zhang
  • Vote: https://mail.python.org/pipermail/python-committers/2016-November/004045.html Please note how people don’t say “+1” or “-1” but share their experience with the candidate. How are we supposed to take a decision based on such feedback?
  • Result: https://mail.python.org/pipermail/python-committers/2016-November/004061.html 6 votes in 8 days: 5 “+1”, 1 (implicit) “-1”
• INADA Naoki
  • Vote: https://mail.python.org/pipermail/python-committers/2016-September/004013.html
  • Result: https://mail.python.org/pipermail/python-committers/2016-September/004021.html I counted manually, 7 votes in 2 days: 5 “+1” (including Yury who proposed INADA-san), 2 “-1”.
• Julien Palard
  • Vote: https://mail.python.org/pipermail/python-committers/2017-December/004989.html
  • Result: https://mail.python.org/pipermail/python-committers/2017-December/005019.html 7 “+1” votes (including mine) in 3 days.

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?

[ncoghlan (Alyssa Coghlan)]

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

[pitrou (Antoine Pitrou)]

@brettcannon

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.

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.

@brettcannon

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.

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 ;-).

[barry (Barry Warsaw)]

@njs

But I’m not sure! @barry, can a GUIDO do all of the things above, or if not, then which ones?

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.

[vstinner (Victor Stinner)]

@ncoghlan

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).

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

@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.

[njs (Nathaniel J. Smith)]

@barry

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.

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?

[ncoghlan (Alyssa Coghlan)]

@vstinner

@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).

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.

[vstinner (Victor Stinner)]

@ncoghlan

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).

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

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

@ncoghlan

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.

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…

[barry (Barry Warsaw)]

@njs

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.

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.)

@njs

• Pronounce on PEPs (YES)
• Decide whether a particular decision requires a PEP (YES)
• Decide whether or not an alternative implementation is really Python (NOT NECESSARILY - this seems like more of a legal question than a technical one, thus the PSF would certainly be involved IMHO)
• Add people to the core team, remove people from the core team, change the process for promoting people (YES - assuming consensus cannot be reached)
• Make decisions about special cases, like giving someone bpo permissions without commit permissions, or giving commit permissions but only for the docs (YES - assuming consensus cannot be reached, or subsequent policies do not cover this case)
• Change the rules for the governance itself, or for any of the above (NO)

[pitrou (Antoine Pitrou)]

@barry

(Assuming I can find your questions in Discourse’s unhelpful linear conversation mode.)

Ahah.
(post must be at least 10 characters)

[njs (Nathaniel J. Smith)]

@barry

But okay, I’m game to answer your questions through my interpretation of the PEP!

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…

@barry

(Assuming I can find your questions in Discourse’s unhelpful linear conversation mode.)

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…

@vstinner

@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’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.

[vstinner (Victor Stinner)]

@njs

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. (…)

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 Or maybe I missed something huge?

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