Probably none. Similarly, no time was spent on removing commit privileges, and nothing has ever happened (Google seems to have been fine with the status quo for more than a decade).
Just to be clear:
The core developers themselves have to decide what the right
term is, not the community.
As mentioned several times already, we have to differentiate
between these aspects of assigning flags to core developers:
- having the status of a core developer
- having voting rights on governance issues
- having active commit rights to the repos
- being active in the sense of some metric (checkins, discussion
input, etc.) - having voting rights on PEPs
Each of those are different and IMO should be handled independently.
When it comes to terminology, special care has to be taken
to address people’s concerns. “Emeritus” has different
associations in different cultures and contexts. Same as
“inactive”.
Thanks,
I just posted a few more tweaks: PEP 8016: more tweaks based on discussion by njsmith · Pull Request #838 · python/peps · GitHub
The parts that are relevant to the discussion here:
Tie-breaking
The above PR changes the tie resolution rule to basically “if one of the candidates wants to step down, ok, otherwise we’ll flip a coin”. I think this is fine, given that by definition the tied candidates are all equally acceptable to the electorate. We can tweak it more if anyone cares, but hopefully this is uncontroversial :-).
Emeritus members (or whatever you want to call them)
I didn’t change the name in this PR, since it doesn’t seem like there’s any clear preferred alternative. I’m happy to do so if one emerges though, or if someone tells me that they really find this term unacceptable and insist it be changed (@skrah?).
But, the discussion here did make me realize: while it’s obvious to me that we don’t want to erase anyone from history or anything like that, it’s still better if the text actually says that explicitly :-). So I edited the bit about emeritus vs active members to read:
To record and honor their contributions, emeritus team
members will continue to be listed alongside active core team members;
and, if they later resume contributing, they may switch themselves
back to active status on request, without the need for a vote. While
someone is in emeritus status, though, they lose their active
privileges like voting or nominating for the steering council and commit access.
Hopefully that makes things a bit clearer?
Full changelog
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
I don’t think it’s possible or desirable to treat these flags as totally independent… since the goal of PEP 8016 is to write down clear guidelines for resolving governance issues in the future, it does have to specify who can vote on governance issues :-). And since it says that active core developers can vote, that means it also has to define “active” and “core”, so there’s a concrete proposal there whose details you can read. We tried to make it all as boring and uncontroversial as possible, but if you object to something then please speak up. (And of course, none of it will actually effect anything unless the core developers choose to ratify it.)
OTOH, PEP 8016 doesn’t actually say anything about commit rights or voting rights on PEPs – meaning that those can be handled as separate discussions. Which in practice I guess will mean that we keep doing things the way we have been, until we decide to do something different.
I agree with this principle, but from the discussion so far I can’t tell which word actually addresses people’s concerns the best :-). Do you find “emeritus” problematic? What would resolve your concerns?
It’s more of a philosophical question: Some people here seem eager to define everything, I don’t like to apply arbitrary labels to persons. “Emeritus” is one such label that I’m vigorously opposed to.
It over-formalizes things. Too much bureaucracy takes the fun out of a project.
Somewhat related:
Is Condorcet resilient against one unique PEP that leaves things more open (Barry’s) and 6 similar but more explicit PEPs, each of which contains a passage that 10% of the people don’t like? 
While I didn’t run a simulation, it seems unlikely to me.
1 Like
So I guess there are two things you might be objecting to:
- The idea of keeping a list of core team members, and distinguishing between ones who are active and ones who aren’t, for the purpose of project governance.
- Using the word “emeritus” for that distinction.
If you’re objecting to the basic idea of (1) then… I’m not sure what to tell you. It’s a pretty standard, widely-agreed-upon best practice for F/OSS projects, and no more bureaucracy than we’re already doing. Maybe you would do better to vote for PEP 8014, “The Anarchist Governance Model” :-).
If you’re objecting to (2), the word “emeritus”, and want a different word instead, then OK, sure. I take it your preference would be to change the text to use “inactive”? Does anyone else object to that?
I don’t understand exactly what scenario you’re imagining, so I can’t give a proper answer. But in general, for Barry’s PEP to win a Condorcet election, it has to be able to beat every other PEP in a simple two-way head-to-head match-up. There’s really no such thing as vote-splitting in a Condorcet election.
I’m not sure that I like “Emeritus”. For me, it sounds like “ok, I’m done with Python, let’s take my retreat”.
I prefer “Inactive” which can mean “my life priorities changed, and I have to make a break with Python, it’s me, it’s not you Python, I still love you, but you know, you and me changed… it’s time for a break… well, not a definitive break, just I cannot say for how long… i will keep you in touch, ok?” (hum, this description is maybe too long). Using “Inactive” term, for me it’s more obvious then a core dev can become “Active” again as soon as they are back (ex: move to a different company, get an agreement with their manager to get more time on Python, etc.)
I would not appreciate to “automatically” become a “Emeritus” because one of my family member becomes sick and I have to step down with Python. Becoming “Emeritus” just because I am no longer able to reply to questions by emails like: “do you still want to be considered as active, or can we move you to Emeritus list? you will become Emeritus if you don’t reply before XXXX.” Can someone estimate how long a family member will be sick? That’s a silly question.
Replace “sick family member” with “burnout” if you prefer.
Becoming “Inactive” because you don’t reply to emails and don’t contribute anymore sounds more “logical” to me.
–
In short, Inactive sounds to me as a reversible change, whereas Emeritus sounds to me as a one-way change. Emeritus sounds to me as “taking your retreat” and it’s harder for me to imagine a grandfather to restart working. Ah yes, Emeritus also sounds like “old” to me.
I guess that the exact definition of Emeritus also depends on the country and the culture, whereas Inactive sounds like connoted.
FWIW, I believe that simple things like changing a word that doesn’t semantically change the PEP is probably fine to occur at any time. IOW, if PEP 8016 gets selected, but people really prefer a different word, I don’t think that is an issue.
I think 1) became more popular in the last couple of years, for reasons that I don’t want to go into now. 
I’m okay with 1) as long as a contact attempt is made.
For 2) I agree basically with what Victor wrote in the meantime. “Inactive” sounds more reversible and friendly.
I guess the difficult part is to move from the current state (no process to move a core dev to a Inactive list) to a new contract (a core dev becomes Inactive if XXX).
Once the contract is approved by all core devs (by approving a governance PEP for example?), I think that it will be fine, no?
Yeah, but it’d be better not to have to go there if we can avoid it :-).
OK, I’ve updated PEP 8016: more tweaks based on discussion by njsmith · Pull Request #838 · python/peps · GitHub to replace “emeritus” with “inactive”.
Voting methods can’t substitute for wisdom 
. If a vaguer PEP is preferred by almost everyone over all other PEPs because it’s more vague, then any voting method is likely to call it the winner. The voting method can’t judge why it’s more preferred, it can only know that it is more preferred.
Or maybe you’re really wondering whether the vaguer PEP is at a disadvantage because it’s up against 6 PEPs that differ from it in the same key way? Not in a formal sense, because Condorcet (as we’re using it) satisfies “independence of clones” - “the winner must not change due to the addition of a non-winning candidate who is similar to a candidate already present”.
Which is a pile of hot air . I expect psychological effects are far more important: if a PEP is unique in some way, for some people that will be an attraction, but for others an alarm bell, and more so the higher the number of PEPs that differ from it in that way. Then whether the PEP’s uniqueness works for or against it depends on whether more people view that as “attraction” or “alarm bell”.
The voting system we’re using won’t exaggerate those effects: whether PEP A “beats” PEP B depends only on whether more ballots rank_A_higher_than_B than rank_B_higher_than_A, and each pair of PEPs has its own pair of such counts.
Sorry, I don’t get why no veto by the steering council is a must here. Honestly at least two-thirds positive core team votes sounds conflict with veto by the steering council. Does this veto also needs voting (more than two-thirds) inside the council or just a single member of it?
Yeah, I hear what you’re saying! This is a tricky and sensitive topic.
To clarify how the PEP currently works…
- Normally, when a new core dev is nominated, then the existing core devs do a vote, and if >=2/3 are in favor, the person becomes a core dev, and that’s it.
- If the steering council wants to veto, then the council members have to vote amongst themselves.
- This is a general rule – individual council members don’t have any special power. All the council’s special powers require a vote.
- The council votes are always simple majority (reference), except for the special case of ejecting an existing core team member, which requires a supermajority. So a veto requires a simple majority.
Background/motivation
The council veto was one of the things we copied directly from Django (you can read their version here). They’ve never actually used the veto in real life, and I hope that we’ll never use it either. But, there’s one specific situation where it’s important.
Imagine there’s some developer who has a good public reputation, but you know that in private they’re an abusive manipulator who does terrible things to people. Now, because they have a good reputation, someone nominates them as a core dev, and all your fellow core devs innocently vote for them, because they have no idea that there’s any issue. What do you do? You could speak up about what you know… but if you do that in public, then you know the dev will come after you, try to ruin your reputation, stalk you, make you lose your job … you’ve seen them do it before to other people, and you can’t risk it. The veto gives you another option: you can go privately to the steering council, and share what you know. And if they’re convinced, then they can use their veto.
Again, we hope this never comes happens. And it’s far from perfect. For the council to announce that they’re rejecting a core dev and they can’t explain why… that is a truly shitty thing to do. But there are situations when the alternatives are even worse.
Is it likely to be abused? I don’t think so – remember that the council is elected by the core devs, so for a veto to happen you’d need at least 3 widely-trusted people to all be convinced that this was the best option, despite all the downsides. And if it ever happened, it would be super controversial. If the 2/3 of core devs who voted to promote the dev don’t trust the council, then that’s enough core devs devs to kick out the council with a vote-of-no-confidence, or even to modify the governance PEP to remove the council’s right to use a veto.
Alternatives
Personally I think it’s good to have some kind of way to eject toxic people that doesn’t require dragging everyone into a giant group discussion, but I’m not too fussed about the details, because it should be a very rare and special event.
Technically the veto power isn’t strictly necessary, since the PEP also has a way for the steering council to eject core team members via a special vote (basically for the same reasons as above); in any case where the council would veto a new core dev, they could instead wait for them be elected, and then kick them out again. The only difference is that the eject-an-existing-core-dev vote requires a special council supermajority, while the veto-a-new-core-dev vote only needs a regular council majority, so it’s harder to kick out an existing core dev than it is to block a new core dev from joining. This seems fine to me, but it’s not particularly important… we could e.g. make the veto be a supermajority too, or drop the veto and rely on the regular eject-an-existing-core-dev power alone, if people think something like that is better.
I guess there is one procedural weirdness with the current text, where it’s not exactly clear when the council can use their veto power. Like if someone questionable is nominated to be a core dev, and it takes the council a week to figure out whether they want to veto, and in the mean time they’re promoted, then can the council still use the veto power or do they need to use the eject-an-existing-member power? This kind of procedural edge case is tiresome and unpleasant, so maybe we should merge the two powers to keep things simpler.
Thanks for the reply.
In the PEP I only see the word strict majority:
Are they the same thing? simple majority has a definition in wikipedia, not strict majority.
Not sure in open source world we should take such real life things into consideration. It’s complicated.
+1. The council could use their power later if there is really a problem. Promoting core devs could be frequent but not ejecting one. I think so.
An alternative is not give veto to the council, let the contributor be promoted, and watch their behavior. If the new core dev is quickly identified as toxic, there is the conduct workgroup to take actions against the core dev. The conduct workgroup might even provide evidences of misbehavior which can be analyzed by everyone, rather than using a veto without explaining anything.
Maybe a contributor misbehaved 5 years and has a long history with one member of the council, but changed their behavior. There is a risk of abusing the veto power.
No special power, no risk
2 Likes
Sorry for the slow reply here – I’ve been feeling guilty about not getting back to you, but between the US holiday/work/general uncertainty about whether it was acceptable to change the PEP at all I haven’t found the chance to reply until now.
Yeah, they’re the same thing, except apparently “strict majority” is a term I made up that no-one else uses. Whoops. Thanks for pointing that out. Fixed here: PEP 8016: remove confusing term "strict majority" by njsmith · Pull Request #846 · python/peps · GitHub
@dstufft and I talked this over today, and we both generally felt nervous about making changes at this point. (Partly this is my fault for being slow to follow-up, but partly it’s because this didn’t come up until we were already in the “final review period”.) How worried about this are you?
Even though promoting core devs is frequent (we hope!), I don’t think this affects it too much. If the steering council doesn’t use their veto, then they just… do nothing, and the core dev is promoted. The only time the veto makes any difference is if they actually use it, which will hopefully never happen. So if you’re worried that this will add a lot of complications to regular promotions, I don’t think you need to worry about that.
Also, if PEP 8016 is selected, then making small tweaks to the text like this is doable. It takes a little bit of work – someone has to propose the specific change, and somehow count who’s in favor and who isn’t, but that’s all. If it’s an uncontroversial change then I don’t think it should be hard to do. (And we might be doing this to tweak the council term anyway – see here.)
If you’re really worried about this, and the timing works out, the specific change we talked about possibly making is: adding the sentence “Veto votes follow the procedure described in the ‘Ejecting core team members’ section.” But, I think we’d rather not change it at this point, if you’re OK with that.
If we don’t change it now, and PEP 8016 does end up getting selected in the vote, then feel free to poke me once things have settled down and I’m happy to help figure out how to make a fix-up proposal, like I described above.
What do you think?
Let’s go with it.
Thanks for your patience!
(Note for posterity: we also discussed this briefly offlist, and IIUC @xiangz’s biggest concern was the idea that the council would have to explicitly step in on every core dev promotion to say whether they were going to veto, and this would add unnecessary overhead. But PEP 8016 doesn’t require the council to actively approve each new core dev; if they do nothing, then the core dev is approved automatically. And doing nothing is very low overhead :-).)