@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?
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”? 
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 
).
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 :-).
I’m familiar with those things (and @tim.one mentioned another option again in one of the threads, IIRC involving sha1(tomorrow's stock prices)). But like Steve, I don’t think we need to go into this much detail – if for some reason people don’t trust the returns officer to flip a coin, then I’m confident that we can still find consensus on whether some other approach is in fact random.
Good point, and yes, I’m probably subconsciously factoring in the fact that both times are very busy for me But I’m also thinking about what a change of council might mean for a controversial decision - we still have time to modify 3.8, and will our next leader approve a proposal to remove a certain feature? Feature freeze at least puts that decision in a clearer context, and a release obviously does as well.
In my experience, post feature freeze is when most proposals slow down and people breathe a bit, but the ones for the next version start showing up before it’s released. It’s the best gap to run an election if you’re going to tie them to the release cycle.
I guess the other aspect is our current release cycle discussions. Would/should the council approve a change that affects their own term? Maybe tying it to PyCon isn’t such a bad idea…
There’s no theoretical problem with the council approving a change that affects their own term, and I’m not too worried that a council would like, refuse to change the release cycle just so they can hold onto power longer. But having the council term and the release cycle tied together does add yet another thing we have to talk about to the release cycle discussion, which is itself maybe a bad thing, since discussions always go better when separate issues can be separated. Also, the mere fact of tying their schedule together does tend to suggest to people that each council “owns” a particular release, whether that’s the intent or not. (And to be clear for posterity: it wasn’t the intent :-).)
So… what do we do. I don’t think it’s a huge deal either way – changing the text might be a modest (IMO) improvement, but there hasn’t been much followup on how we want to handle these last-minute changes, so I’m a bit nervous about touching it for a mere “modest” improvement. OTOH, if we leave the text alone, it wins the vote, and then we decide that we want to tweak the schedule (switching to “elections are held after each alpha / every February / whatever”), then it’s really not that hard to make the change. I’m assuming it wouldn’t be particularly controversial, so it’d just be like… someone (you?) writes up the actual text, posts it to python-committers, we click a few buttons to start a vote (we already need the infrastructure for doing this, to handle the council elections in the first place), like 10 people vote because no-one cares that much, 9 of them are in favor, done. Not something you want to be doing three times a week, but really not a big deal. It might even be good practice to go through the process with something simple like this :-).
So I’m leaning towards: if you feel so strongly about this that it’s really your make-or-break for the proposal, then we should change it. (And I have a mild preference for switching to a calendar-based cycle, instead of moving the point in the release cycle.) Otherwise, let’s leave it as is to reduce the disruption.
What do you think?
@ambv just contacted me off-list to suggest switching to a calendar-year-based term. Hi @ambv! I think you will be interested in the subthread between me and @steve.dower starting here.
If you both want to push for a calendar-based term, that does make me more inclined to actually make the change. Both because it’s more evidence of it being a good idea, and because it gives me more people to blame if anyone accuses me of arbitrarily fiddling with the PEP at the last minute ;-).
Straw-man concrete proposal: terms are one year long, and we do an election every January. (Why January? Just because PEP 8001 says December for picking the governance model, and January is the month after December…)
@ambv, @steve.dower, @dstufft, anyone else who feels like jumping in: Do you like that concrete proposal? Do you think we should make the change now, before Dec. 1?
Sounds good to me, though I am keeping my prediction that we won’t have enough candidates to do an election (or we won’t like enough of them enough to form a council) as soon as January 