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

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?

“if necessary”? :slight_smile: I hope people would have more positive motivations than that to serve on the council (though who knows?).

A straw poll in general would be great - Guido suggested it as a way to find out whether it was worth discussing councils at all if it turned out there was only one volunteer.

My evidence is the number of people participating in the governance discussion (excluding those who are only saying they can’t participate, who presumably wouldn’t continue being involved in the same system). Most of us have our areas and little desire to worry about things outside of that, which we’re seeing now, and a role like any of these requires a broader view. Surely those interested in taking the broad view would be doing it now?

Meanwhile, both of our proposals introduce a new area that no core developers have had to previously take an interest in: Evaluating and approving proposals (except Nick Coghlan, I guess). Eventually (hopefully!) I guess we’ll grow to C++ size and have people joining the core team with their existing skills in this area, but right now our mechanisms for joining the core team also require other contributions, which means multiple barely-overlapping skillsets.

For a specific example, most of my management chain at work are excellent decision makers. They know how to collect more data, when they have enough, where to go to find experts, how to think like customers, etc., but most have not written code in years. How do we get one of them into the core team so they can run for the steering council where they can contribute the most? Restricting ourselves to people willing to wade through PRs or mentorship programs excludes people who are ready to help out today, but are not and should not be “core developers” (and I used “core team” deliberately earlier, because that term makes a lot more sense under a model where contributors don’t also have to be devs or directly involved in dev-like work :+1:).

I don’t think that I would answer to such poll. I will not decide anything before a governance is selected. And each governance gives very different responsibilities to the council. In PEP 8010, the Technical Leader is in charge of “everything”. In PEP 8014, the Council has almost no responsibility (well, I’m not sure about how much responsibilities it has in practice).

I just posted a few more tweaks: PEP 8016: more tweaks based on discussion by njsmith · Pull Request #838 · python/peps · GitHub

The main part that’s relevant to the discussion here is that the PEP now leaves the door open to people serving on the council without being core team members, which should hopefully make @steve.dower happy! I’ll paste the whole commit message below:

  • Removed the requirement that council members have to be core team
    members; added the requirement that non-core-team council candidates
    need to be nominated by a core team member. Rationale: Steve Dower
    is worried that we may have a shortage of core team members who are
    willing to serve on the council. I’m not worried myself, but I like
    Steve and don’t want him to worry; this is an easy way to help with
    that. Requiring a core team member nomination should be harmless,
    since any candidate that can’t get a nomination is certainly not
    going to win a vote, and it lets us filter out random jokers early.

  • Added some language to emphasize that emeritus core team members
    will still be listed on the website and their past contributions
    will continue to be recorded.

  • Changed the vote tie-breaker from “seniority as a core team member”
    to “mutual agreement or random chance”. Victor pointed out that
    seniority is not always known or unique, and anyway this doesn’t
    make much sense if we’re allowing non-core-team member candidates.
    The goal was always just to have some unambiguous resolution that
    doesn’t require voting again, and this seems like a simpler and more
    reliable option.

  • Clarified that in the never-going-to-happen edge case where a core
    team member misbehaves so badly that the project has to kick them
    out AND that core team member is on the council, then they’re also
    removed from the council.

  • When defining the initial core team, fix the definition of “current Python committer” to match reality

  • Added link to the second discussion thread.

  • Made a few small wording tweaks and fixed some ReST formatting.

1 Like

Thank you! I have just one more concern, but then I’m willing to withdraw my proposal and throw my full support behind this one.

A new council is elected after each feature release. Each council’s term runs from when their election results are finalized until the next council’s term starts. There are no term limits.

I suspect we will need to schedule this after feature freeze, since that is when people will be preparing PEPs for the following release. This probably means that councils will have to overlap, while the previous one finishes up 3.N and the new one begins 3.(N+1), though I suspect we’ll have a decent amount of continuity from council to council.

One possible workaround would be to dissolve the old council at feature freeze, make the RM solely responsible for everything to do with their release, and the new council responsible for everything that is not specifically to do with the release. Or perhaps that could just be a suggestion for the council that they may delegate all code responsibilities to the RM at that point (I guess it’s also within scope for the council to abolish the RM role entirely?).

In any case, since decisions about a new version begin at the previous version’s feature freeze date rather than release date, I believe the council needs to be elected at the feature freeze rather than the release.

It would be nice to stop making last-minute changes like that. Otherwise it sounds like I will have to re-read all governance PEPs before voting, lest those PEPs have been changed significantly by their authors.

:-/

“If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.”

You should have a look at https://wiki.openstack.org/wiki/Governance/TieBreaking and https://github.com/oubiwann/coin-toss You can announce the coin-toss seed in advance to reduce the risk of cheating. But you should also explicit on how you pass the list of candidate, since I guess that “Alice,Bob” or “Bob,Alice” don’t give you the result (I didn’t try).

-1 on enforcing a process here. I like the current wording (it assumes we’re sensible adults, which by the time we have elected people should have been validated already).

1 Like

For purposes of this post I’m going to temporarily ignore the questions around changing the PEPs / tentatively assume that something like my proposal here will be adopted and small tweaks like this are fine. If that doesn’t happen we’ll re-evaluate.

I don’t think we want multiple councils to overlap, because it adds a lot of potential procedural complexity, in particular when you need someone to decide on an issue that isn’t clearly related to a specific release, who would do that? (Some PEPs affect older releases, some PEPs are approved during one release cycle but not implemented until the next, some PEPs or other decisions are about procedure or other projects like packaging PEPs…) Trying to formalize RMs here seems over-complicated too.

But I don’t have any particular attachment to the current steering council term + election schedule. “After each release” is a convenient marker, and Django does it this way, but since the council’s explicitly not expected to impose a particular vision on Python I don’t think it matters too much. Other schedules could work just as well, even like “the month before PyCon”.

One concern: I’ve only been through one alpha cycle as a core dev so far, and my impression was that the freeze date was like… peak burnout for most core devs? There was a lot of last minute scrambling. That might not be the best time to run an election? Though I guess as someone on the release team you might have similar feelings about the actual release :-).