Working discussion for PEP 8016: The boringest possible steering council model

The management of the workgroup and reports back to the workgroup are not too time consuming. For other workgroups, we provide a 1-2 paragraph monthly report (which can be “no updates at this time”). After the workgroup agrees to funding (for example, the science workgroup) a project, the PSF handles the fiscal management from that point on.

Thanks to this discussion and Maths on vote majority discussion, I adjusted votes in my PEP 8015: Annex: Summary on votes

  • Vote on promoting a contributor and on PEPs now requires >= 2/3 rather than 50%+1.
  • Vote on changing this PEP now requires >= 4/5 rather than 50%+1.
  • (Also: Specify the Condorcet method: use Schulze/Beatpath/CSSD variant to elect Python Steering Committee members. Specify how to deal with tie and the constraint on the employers.)

I now agree that 50%+1 was too weak to justify a change/promotion. It’s hard to deal with half of core developers who disagree with a change/promotion.

Sorry, I didn’t mean to undersell the PSF here :-). The thing I’m gesturing vaguely at is… well, there’s this weird disjunction: legally, the PSF and its board are the final arbitrars of what Python is, since they hold the trademark. But traditionally, the PSF board and the Python core devs have acted as two independent groups that mostly don’t even talk to each other, and the PSF just kind of implicitly assumes that whatever it is the core devs are doing to the language is probably fine.

This wasn’t really a problem so long as both groups deferred to Guido whenever any questions arose, but going forward it would be good to get everyone on the same page. If there’s a CPython workgroup, then presumably it wants to spend the funds on things that the CPython project decides are worthwhile, which means it somehow needs to interact with the CPython project’s governance. Or for another example, consider the fork of CPython called “python 2.8” – is it Python? Can it use the trademark? The decision was “no”, basically because Guido said so. In the future, if the PSF needs a ruling on questions like “will there ever be an official python 2.8?”, then our new governance mechanism will need to somehow generate that ruling, and communicate it to the PSF.

How exactly that will look, I’m not sure! Your suggestions downthread make sense to me, but figuring out the details will take some work. My goal in the draft was just to be clear that the council has the mandate and authority to have those conversations and get something figured out. Maybe it could be clearer…

I don’t think it’s going to be a big issue, given that the candidates are all being drawn from the pool of existing Python core team members? And since they have to win an election, I assume they’ll mostly be pretty active contributors who know what’s happening in the project, already have working relationships with the other council members, and that people will often end up being re-elected for multiple terms anyway.

We could switch to staggered terms if people prefer the other way… I don’t have a strong opinion. I just figured this was probably fine and I’m trying to keep things simple :-).

Not sure where you’re getting this? In the current text, the only ways a council member can be forced to step down are either through a successful recall, or if they disappear and stop responding to messages.

That would also work, but I figured that organizing big project-wide votes is a hassle and we’d prefer to avoid it when possible. (And we’d rather people step down if they’re having trouble than hold on because they don’t want to cause a hassle.) I’m guessing that in most cases it will be like when someone volunteers to act as a BDFL-delegate – someone diffidently volunteers to take it on, and everyone else is like “oh yay now I don’t have to volunteer”. If it turns into some big controversial thing, then the council can always decide to hold a vote…

Yeah, I’ll clarify the text.

Oh interesting! I just copied that bit from Django, I can adjust.

I guess the traditional OSS thing is to elect new committers via “general acclaim”, i.e. you wait until it’s pretty obvious to everyone that someone’s ready, and the four-fifths stuff I copied from Django follows that. But now that I think about it, I’m not a huge fan of the super-conservative thing either, and Donald was suggesting using 2/3 as a supermajority threshold earlier too, so sure, let’s switch it.

Again I don’t care that much – does anyone else have an opinion? I feel like if there’s something that’s so uncontroversial that 4/5 of the core team will vote for it, then it’s unlikely that 3/5 of the council will be against it. And even if it that does happen, then the council can always be recalled, or just wait for the next election and then elect council members who aren’t so obstructive. OTOH, I can’t think of any situation where the veto would be useful either, and leaving it out would simplify things a bit…

Oh uh, that’s what Django calls it and I was sloppy with cut-and-paste :-). Thanks, I’ll fix it.

I think this is less of a problem here than it would be for something like the PSF board. For the steering council, there’s no requirement to meet regularly, votes should be rare, it’s fine if a vote is spread out over a week or two, members can abstain and still count towards quorum if its an issue where they don’t feel like they can form a meaningful opinion, and if someone doesn’t have the time to participate anymore then it’s pretty easy for them to step down and get a replacement. Also, like Donald points out, our total universe of potential candidates is only like 20-30 people (estimated from only 25 people responding to the voting systems poll), so 9 on the board would be quite a lot :-).

But really the reason I’m a bit reluctant to change this is that if quorum != council size, then it raises other issues, like should the conflict-of-interest rule be based on the size of the quorum or the size of the council? And I’d kind of like to not have to think about that kind of thing if I can avoid it :-). How worried are you about this?

Oh, that’s interesting… I would have said that obviously LinkedIn and Microsoft are the same company. (Though note that in the current draft, you can have 2 people from the same company on the council, so Barry and Brett can definitely both serve at the same time – it’s just that if they do, then maybe Steve and Eric would have to wait for the next term.)

As a practical question: is there any simple and unambiguous way to tell the difference between a separately-branded subdivision (e.g. Xbox) vs. a subsidiary (e.g. LinkedIn)? Do we have to go read SEC filings or something?

I think the benefit of a conflict-of-interest rule like this is partly to diversify the council, sure, but also there are a lot of people out there who are genuinely nervous about that possibility of a big company taking over Python development. (And let’s be honest, it’s not like these big companies haven’t done dubious things in the past.) And conversations about this are terrible, all innuendo and vague conspiracies and other distracting nonsense that isn’t good for Python or for the companies involved – so it’s better to just avoid the whole issue entirely. This generally argues for making sure the rules don’t encourage hair-splitting…

2 Likes

I like this idea very much. I have tried to do a similar thing with 8014: get a minimal governance model in place and trust in the common sense and goodwill of most people involved most of the time. (but 8014 is different than 8016 as presented here in that 8014 explicitly tries to codify as few things as possible, while 8016 seems to codify things in a simple way).

I’m looking forward to seeing the PEP!

I’m honestly surprised PEP 8013 didn’t get more of a mention, which perhaps mean I didn’t at all make clear in it that it’s spiritually identical to this except for the pool of candidates being outside the core development team, and a whole lot of non-binding details (that is, not the “spiritual” parts).

Do the authors of 8016 think there are major differences? If the pool of potential candidates were allowed to include current core developers (and we came up with some conflict-of-interest wording, which seems likely anyway) would it make more sense to combine them?

And by “combine”, I mean withdrawing mine and allowing anyone to self-nominate for election in 8016. I really don’t care that much about the details, and if people who do care about the details want to work on it I have no problem. Everything else here seems good to me.

I feel like a major difference is that PEP 8013 doesn’t allow the CoA to delegate their authority, and the intent appears to be that the CoA is making decisions themselves on PEPs with regularity. Sort of one of the core ideas of PEP 8016 is that while final decision does ultimately rest within this steering committee, that they have the freedom to effectively implement some other PEP without involving a heavyweight process. This could allow us to say, give direct democracy a try on a PEP or two and see how it works out, and give them the power to tweak how that process works over time without involving a full vote of the entire electorate. It is of course possible that they ultimately decide the best model is to have decision making stay within that steering committee, but that there is an easier way to experiment and ultimately implement changes to the process.

One example I like to think of, is that originally there was no concept of a long standing delegation like myself and Paul Moore (originally Nick Coghlan) have for PyPI and the packaging interoperability PEPs. However because Guido more or less had complete authority to experiment and tweak the PEP process, we were able to try that out and it ended up working out quite well (and if ti hadn’t, Guido had the power to revoke that delegation). Giving the steering committee flexibility to implement our processes however they see fit, means that it’s far easier to adjust to the changing needs of the Python community. Of course the steering committee does have a decent amount of power, so we do limit their ability to effect how the committee itself is chosen or serves by encoding that in the PEP and requiring a full vote for that.

With regards to whether we can allow non-committers to be a part of the steering committee or not. I don’t personally care? I’m not opposed to allowing anyone to serve on the committee and leaving it up to the core developers who are voting to decide if they are OK with a specific person who isn’t a core developer being on the steering committee or not. I suspect though that if someone is not a core developer and they get elected to the steering committee, that feels like a really strong signal that that person should probably already be a core developer anyways.

That’s true, but if the CoA says “we’ll be happy if X is happy” and there’s one final post to python-committers with the final text and a reply saying “yes”, I don’t see how it is functionally different? It also allows the CoA to withdraw the delegation if they choose, rather than it being an irreversible transfer of power. (And all of this works out because the model allows the council to choose on a case-by-case basis how to evaluate each PEP. The model provides some suggestions, but no requirements.)

Perhaps, but there are plenty of people who have an interest in Python’s direction but no willingness to merge random PRs. I don’t see any value in conflating the two roles.

It may just be a case of optimization. By explicitly disallowing delegation, it feels to me like the intent isn’t that the CoA can (or at least should) do a psuedo delegation by saying “whatever this person says is what we’ll pick”, which would seem to me like explicitly going against the intent of the PEP, which I think would make the CoA less likely to actually do that, whereas PEP 8016 explicitly enables that so the hope is that people will feel more like it’s allowed.

That being said, if you don’t actually have a problem with delegation (either to a person, or to another process) then you’re right that a lot of the differences start shrinking to how set in stone the actual process is (PEP 8013 outlines a specific process PEPS have to go through, PEP 8016 allows the steering council to make that choice) and who is eligible to serve as part of that committee.

I’d be interested in @njs view on it, but I don’t personally have a problem making anyone eligible. I trust the core developers who would be voting on the candidates to select responsible candidates who will make reasonable decisions regardless of whether those candidates are members of the core team or not.

As a practical point, if the majority of the core developers feel like being a core developer should be a part of the mandatory qualification, then it doesn’t really matter whether we allow non core developers to be a part of the steering committee or not, because they’d never actually win. However, being flexible does allow exceptions to that even if that’s the general “rule” that happens in practice.

Maybe I just have a more lax view of what it means (or should mean) to be a core developer :wink: That is maybe a larger discussion not really relevant to the governance discussions, but I feel like the commit bit is possibly the least interesting part of being a core developer (and that may be bias because I use mine so very rarely) and it’s more a recognition that we trust some person’s decision making for the good of Python and that they’ve put in some significant effort in improving Python. If someone is regularly working on PEPs and end up being involved as part of the CoA/steering committee, that feels like a strong signal we trust them and should make them part of the team, regardless of if they want to push the merge button on PRs or not.

The part where only core devs are eligible for the steering council is one of the bits we copied from Django; I’m not especially attached to it.

I agree with Donald though that anyone who could win a vote like this is probably qualified to be a core dev :-). If you look at the draft text about the “core team”, then you’ll see that another thing we copied from Django is language about how people can qualify for the core team via non-code contributions. (And this is not actually new really… I barely had any code in git when I became a core dev.)

I want to reread 8013 before saying more detailed about the relation… I had the impression there were more spiritual differences than that, but if that’s wrong and we can merge proposals then that’d be great.

I’ve updated the draft text to finish up the missing bits and incorporate the feedback from this thread. In particular:

  • Switched to a 2/3 supermajority threshold everywhere, and clarified that this is a >= check
  • Fixed the stray references to Django’s technical board and removed the reference to only core team members being allowed to review security reports (thanks @vstinner)
  • Dropped the council veto on constitutional amendments, so now it’s just a supermajority vote of the core team

The biggest change since the last draft is that I added in a mechanism to remove someone from the core team if we really have to. The proposal is that it requires a 2/3 supermajority of the steering council (so 4:1 in normal circumstances, like @dstufft suggested above), and is also special in that it can’t be delegated, and can’t be used when a vote-of-no-confidence is in process. I’m not particularly wedded to the details here; I think it should be possible but can be nearly arbitrarily difficult since it should only be used in really egregious cases.

@steve.dower For now I left in the requirement that council members also be core team members, just because I wanted to get a draft done and that discussion seems unfinished. We should finish it :slight_smile:

@Mariatta: I know you feel strongly about having some language around diversity in the governance PEP, and I really liked the language around this in PEP 8011. I ended up not copying it directly in this draft because I wasn’t sure how to fit it into the flow, but I did try to add some similar language, specifically in the section on the steering council’s mandate and electing the steering council. If you have a chance to look at it, I’d definitely value your thoughts on this part (and anything else too, of course).

Happy to. What are your thoughts? So far it seems I’m strongly in favour (but I have my own proposal), and your coauthor is okay with it on the basis that election to the steering council would imply probable election as a core developer anyway (and on this point I’d suggest that allowing non-core developers to nominate would avoid a – purely hypothetical! – rush of people to become core developers first in order to try and join the council).

I wonder if it’d make sense to move this discussion into Committers now that it’s more than an idea?

Anyways, I’ve merged PEP 8016. One thing I noticed regarding the Emeritus status, is we don’t specify how exactly you become not emeritus. I assume just stating you want to be non-emeritus and then you get everything back.

1 Like

Thanks :wink:

1 Like

@njs Can you please create a new thread on the Committers category with the full text of your PEP, so I can comment it there?

My feeling is similar to @dstufft’s, that it’s unlikely to make much difference whether we limit the council to only core members or not, so I don’t have a strong feeling either way. If you’re saying that this one change would be enough to let us drop PEP 8013 from the list and shrink the field a bit, then that seems like a good reason for making the change to me :-). But I don’t want to pressure you either.

I just re-read PEP 8013, and it struck me as both similar and dissimilar. Both 8013 and 8016 follow the general philosophy of people-over-process, where the defined process is mostly about choosing people, and then letting them apply their judgement. In 8013, the focus is very much on deciding about PEPs, and there’s no mechanism for resolving disputes about non-PEP-worthy topics or about whether a topic is PEP-worthy, for allocation of project assets, for disputes about whether someone is ready to become a core dev, etc. In 8016 OTOH the council has a much broader mandate to deal with any disputes that arise. And of course 8013 paints a compelling picture of how neutral external auditors can be used for ruling on PEPs. In 8016, the vision is more that the council will define processes like this, so instead of acting themselves as external auditors, they would delegate to external auditors if that seems like a good idea (and this decision could be made on a tentative or PEP-by-PEP basis, they could tweak details like how the external auditors are chosen as needed, etc., versus 8013 which makes some specific choices there and doesn’t currently provide any mechanism for changing them at all AFAICT). But, since they both emphasize people-over-process, there aren’t really processes in place to force things to play out that way: 8016’s council decided to themselves act as external auditors, then there’s nothing in the document to stop them.

So I guess the reason you’re suggesting that we allow 8016 steering council members to be non-core-team-members is that it makes it more plausible that we could then use the 8016 steering council itself as a “council of auditors”. And the reason Donald and I are shrugging is not that we don’t like the idea of external auditors, but rather that as far as we’re concerned, 8016 is already totally compatible with the external auditor approach, regardless of whether the steering council allows external members. Does that sound right?

Done

Yeah, we should probably put something in about this… and while we’re at it, I guess we should say explicitly who the initial core team is too, huh?

How about this:

The summary is accurate, and I’ve got no problem withdrawing my proposal if I’m happy enough with another (I only put it forward initially because I wasn’t happy with what seemed to be the initial set of proposals).

But I don’t think the ability of a core developer controlled committee to review external opinions is the same as allowing external candidates to nominate and participate in the final decision step (FWIW, I am totally fine with election leading to immediate core dev status, though theoretically not all candidates nor existing core devs would be).

The scope of what I described in my PEP is merely what was top of mind for people when I talked to them - the controversial decision process. I don’t really care if the council is automatically turned into some other working group as well, but I guess my thought was that we’d appoint groups for that via a PEP as we do for release teams currently. So perhaps I over-generalised without specifying all the things I was generalising?

In any case, I’m happier to switch to your text, provided it seems feasible to fill the council with members. So far the most enthusiastic volunteer for any of them is not a core developer, and so I’m worried that for N>1 drawing from the core team, we won’t end up with enough volunteers. I also don’t want to cause a rush of people trying to become core developers in time for each election so they can nominate.

I’m not saying it’s the same either! I think I must have been unclear. In 8016 as currently written, there’s a core-developer controlled committee, but that committee doesn’t have to make decisions directly. They can flat out appoint an external auditor to act as a BDFL-delegate for a particular PEP, and then the auditor has complete control of the final decision step. They can appoint a committee of external auditors, and grant them a standing delegation to handle all PEPs, or all PEPs in a certain area or so long as they follow a certain process, or whatever, and again the council doesn’t have to be involved again after that; the final decisions could be made by the auditors. They can even accept PEP 8013 as-is and let the core devs directly elect external auditors! (Though I guess that would probably be overkill.)

I guess annoying no-hope candidates can be annoying in either approach – either we have random passerby attempting to become core devs, or else we have random passerby straight up nominating themselves and then we have to put them on the ballot :-). Oh well, either way I’m sure we’d cope. (I guess if we relax the requirement that the steering council be core devs, we could still keep a requirement that candidates have to at least receive a nomination from a core dev?)

Regarding finding enough serious candidates: huh, that’s actually not something I’m worried about at all! I wonder what kind of evidence would reassure you (or alternatively, disturb me :-)).

There’s a sharp difference between the commitment required by PEP 8010 and 8011, versus the steering council in PEP 8016. For 8010 and 8011, we’re asking people to make a multi-year commitment to take personal responsibility for the complete language and every decision that’s made. This is such a huge ask that I personally think the proposals are actually unworkable. Most people won’t have the rare combination of skills and personality needed to handle it, and we have no way to predict who will. (Even Guido struggled with this, and he had 25 years to grow into it and fewer political complications to deal with.) But even if you’re more optimistic… 8010 and 8011 are still a huge ask :-).

For 8016’s steering council, the members are explicitly not expected to take on anything like that responsibility. I expect there will be an initial period where the workload is higher because we’re getting things organized, but in the long run they hopefully won’t be making more than a few rulings a year, and those just to rubber-stamp project consensus. Even if we don’t do anything fancy, the minimum needed would just be to ratify a BDFL-delegate for each PEP that comes in, which is hardly an onerous job. The term is relatively short, and there’s a smooth off-ramp if someone needs to step down.

Python is blessed with probably the largest and most diligent contributor teams of any community-driven project I’m aware of. We haven’t had trouble finding volunteers to handle organizational stuff like the language summit or core sprints, or building github bots; we even have core devs that are so dedicated that maintain the buildbots and serve on the PSF board, which I think most people would agree are way far away from fun hacking (and are things that other projects struggle with much more than we do).

Speaking of other projects… Django and NumPy are both significantly smaller than CPython in terms of core contributors. Django’s system is basically identical to PEP 8016’s, and AFAICT they haven’t had any trouble filling their council equivalent. NumPy’s steering council has ~12 people on it, and I think 5 on the subcommittee tasked with handling project assets and boring legal stuff, and 3 on their CoC committee. Node.JS’s council has 19 (!). The PSF Packaging Working Group is similar in that serving on it is a kind of boring administrative workload that’s distinct from actual development, and currently has ~12 people as well.

Do you think we need to do a straw poll to look for people who would be willing to serve on the council if necessary, or something like that?