Private ballot for voting on promoting a contributor as a core developer?

governance

(Victor Stinner) #1

Hi,

While looking one more time at Annex: Summary on votes of my PEP 8015, I was thinking why the vote for the Steering Committee uses private ballot, but the vote on promoting a contributor is fully public?

It seems like the general trend is that when a vote is on “someone”, it’s better to use a private ballot. The rationale for a private ballot is to be free to vote “against” a friend. More generally, to be allowed to provide a fair vote unrelated to your relationship with the candidate.

When promoting a core developer, it can be tricky to vote against a contributor which can then become your peer, a new core developer.

Historically, these votes were always public, and it’s not uncommon that there are negative votes (“vetos”). I was always very uncomfortable with that. The full name of the candidate is associated with a negative comment like “their skill is not good enough to become a core developer” on a public mailing list. Because of that, when I’m thinking about promoting someone, I always started with a private “poll” with a few close core developers, to have an idea if the vote will be positive or negative.

If the ballot becomes private, the early poll becomes useless. However, I explained in my PEP that a promotion can be rejected, it’s part of the process. It’s not something unexpected. And I explained that it’s fine to retry later:

If the candidate is not promoted, a new vote can be organized later, when the candidate gets the missing skills, for example 6 months later.

My question is now: for the vote itself, do you see any good reason to use a public ballot?

I’m not talking about discussions around the vote, where people are free to express themselves, knowing that python-committers archives are public.


(Donald Stufft) #2

I think that it is generally a good idea to use a private ballot for this.

This one thing I’m concerned about is that right now, there’s somewhat of an expectation that when you vote no on someone, you’ll give an explanation of that No vote, so that if there’s something that person is still missing that they need to be good enough, they have concrete feedback to work on. Switching to a private ballot will likely lose this property. That might be worth it (people who want to can still comment that they voted No, and why) but it does represent a loss in functionality.


(Victor Stinner) #3

The rationale for each vote against the promotion can be sent in private to the vote organizer who may or may not fully disclose it to the candidate. Or do you think that it’s important to make the rationale public as well?

Currently, if you don’t want to make your rationale public, you cannot vote against a promotion. Imagine someone who is known to be toxic in other communities. It’s difficult to say in public “this candidate is toxic, but I don’t want or cannot share details to explain why”. I feel your PEP 8016 gives a veto power to the Council exactly for this reason. As I wrong? cc @njs

Note: I’m not thinking to any potential toxic candidate :slight_smile: I just used the idea hypothetical toxic candidate, because IMO it’s easy to understand how public ballots are an issue on such case.


(Steve Dower) #4

I think requiring the public rationale is fine, though potentially tough in some circumstances (which is why we do the initial testing). Hopefully everyone has someone else on the team they can trust enough to tell privately about specific non-technical concerns who is then willing to make those public.

I’m more concerned about candidates being rejected for no reason. Nobody should be getting far enough through the process to then be refused based on an anonymous vote with no explanation. And I fully believe that if somebody has a concern, that concern needs to be evaluated properly, not simply outvoted.

The most common concern I’m aware of is “I’ve never heard of this person before”. Hopefully at least a few of us are aware of the candidates contributions before they are nominated, but also knowing who is aware is good information. If nobody apart from the nominator knows who the person is, there may be a good case for spending some more time contributing first.

But with a private vote, I have no idea, so I have to either not-care about who joins the team or vote against. As it’s a “yes/no” on a particular person, I favor a veto approach, where any -1 vote blocks the promotion.

(I’m also fully aware that I would not have become a core developer under any of these systems, as I was a total unknown at the time. I got lucky that my niche had an opening, but I didn’t actually seek out the position - I was only looking for an opportunity to contribute and things escalated quickly :slight_smile: I’m not convinced that’s a sustainable approach.)


(Nathaniel J. Smith) #5

I’m also generally favorable towards private ballots for core contributors, but intentionally left this vague in PEP 8016 because I figured this could be its own discussion later when we’re not all distracted by the more fundamental governance questions. (So: PEP 8016 just says that there has to be a vote with a >= 2/3 majority, and it doesn’t care whether it’s public or private, or which mailing list it’s announced on, etc. etc., as far as it’s concerned any vote is fine.)

I can’t really imagine a vote where >1/3 of core devs say “no” but the core dev who proposed the vote can’t figure out why…?

In the situation you describe, I don’t think private voting really helps either. Sure, it lets the one person who knows about the candidate’s toxic behavior vote against them without having to post a public explanation, but unless you require unanimity that one vote won’t actually do anything. I think this is the main motivation for having a council veto: it makes it at least possible for private information to block a vote while staying private. Which is kind of terrible, but sometimes the alternative is worse…

That’s fine when someone is scared of reprisal. But it doesn’t help when the problem is that making the details public would cause harm to a third party. (One common situation where this can happen: a victim who’s willing to talk to a CoC committee in confidence, but doesn’t want to share the details of what happened to them with the world.)


(Steve Dower) #6

Would allowing the CoC handlers (for, say, python-committers or some relevant venue that already requires CoC enforcement) to enter an unexplained veto on behalf of any voter without identifying the voter be sufficient? That at least formalises the process for anonymous -1 votes, while hopefully retaining the positive aspects of the public approval process.


(Victor Stinner) #7

Maybe the status quo is a good compromise. About the veto of the PEP 8016 council: I would prefer to see it justified somehow, so provide an explanation. So private ballots wouldn’t help in practice.


(Nathaniel J. Smith) #8

I think this is more or less the idea of PEP 8016’s council veto, and in particular the specific process you describe would be allowed under PEP 8016.


(Gregory P. Smith) #9

I understand and agree with the concern of public mailing list discussions about someone. (I don’t think I even realized committers was a public archive until the past year).

But who gets a commit but has never been a vote in that there has been no computable value and required participation to decide. It has been a consensus discussion where an objection from most us is not a veto and we happily, IMNSHO rightfully, plod ahead and a grant commit bit at times despite some opposition because of assigned mentor conditions, self restraint, and ultimately version control being able to contain the scope of any problem should it actually ever arise works fine.

I don’t want us to turn into a vote for everything culture. Private ballots on people allow unchecked conscious and unconscious discrimination.

A forum for non-public discussion could be setup here. The question is more of do we prevent people from ever seeing the discussion about themselves in the future upon acceptance? does granting access grant them private discussion archive access to the past. Preventing access to past discussion for specific individuals is painful to implement and more pain to guarantee for life. I recommend against that complexity.


(Ned Deily) #10

We already have such a non-public forum. It’s the Inquisition category here.


(Nathaniel J. Smith) #11

Discussions are excellent! I like them a lot. (More than most core devs, I think :-).) But without Guido, we need some way to resolve disputes. And it’s best for this to be written down so it’s transparent, predictable, etc. And so far all the proposals for handling this require the core devs to occasionally do something (e.g. vote for a steering council or supreme leader or whatever).

If we want a well-defined, written-down process, that involves the core devs doing something… then that means we need a well-defined, written-down process for figuring out – once the discussion dust has settled – whether someone is a core dev or not.

In PEPs 8012, 8015, and 8016, this is done by a vote. And specifically in Victor’s proposal in particular (8015), he wants to define a detailed process for this, so he has to decide whether the vote happens in public or private, hence this thread.

Personally I think it’s a mistake to try to figure out all these details right now, which is why 8016 tries to keep things minimal – it just says core team membership “is granted by receiving at least two-thirds positive votes in a core team vote and no veto by the steering council”, and leaves the rest to be figured out later. The vote could be a mailing list thread where people write +1/-1 with rationale, it could be a cryptographically blinded vote through Helios, PEP 8016 doesn’t care, whatever we want. But 8016 does require votes for exactly two things – adding new core devs, and selecting the steering council – because those are the two decisions that together bootstrap the governance system.

(And AFAICT PEPs 8010, 8011, 8013, and 8014 simply take for granted that we all know what a core dev is, which seems like a recipe for messiness later. Like… a few months ago Pablo got several -1’s but Victor declared that this was good enough, and Guido supported him, so that worked out. But next time we have an ambiguous case like that, then what happens? I’m pretty sure people have genuinely different expectations here – you think that an objection is not a veto, but PEP 8012 says that any -1 is a veto, so I guess Łukasz has a different idea… and we don’t have Guido to resolve things.)


(Jack Jansen) #12

Good point… And I think it extends to other decisions that aren’t explicitly handled by PEPs such as 8014 that don’t have a “top of the pyramid”. The nice thing of a BDFL is that it also works as a catch-all for any decision that is needed unexpectedly…


(Carol Willing) #13

I think that there is a strong benefit to keep this public or if a vote to make it 51% for acceptance as a core dev.

As we look toward growing the active contributor community and improve inclusion in the core language team, I believe transparency matters more than making these decisions behind closed doors.

By moving this to a private vote, the ability to provide a reason or rationale behind a delay or rejection becomes difficult to identify. This would make it even harder to articulate what an individual needs to do to be considered for core developer commit privileges.

tl;dr Public discourse on promotions adds transparency to the decision making process.


Straw poll: Which governance proposals do you like best?
(Nathaniel J. Smith) #14

You might want to start a new topic for this? It’s orthogonal to the public/private question, and I think it’s a significant shift from how people are currently thinking about this. (E.g. currently every proposal that has a mechanism for people to become core devs at all requires some kind of supermajority.)


(Victor Stinner) #15

Why do you think that I wanted to formalize the process to promote a contributor? :slight_smile: Previously, it wasn’t clear when a vote ends, how many +1 votes vs -1 votes are needed, etc. Sometimes, Guido showed up and said something like “enough, the promotion is accepted”.

In my experience, many votes to promote a contributor were controversial. The “-1 vote means veto” rule was never really applied. If 3 to 5 people support a promotion, but there is a single -1: the -1 is not a veto, the candidate has been promoted anyway. A promotion has been refused when they were 2 to 3 -1 votes, whereas there were 3 or less +1. I didn’t check votes, I’m giving random numbers. My point is that in practice, it’s a more a 2/3 majority (again, this ratio is not exact science :slight_smile: ) than “any -1 is a veto”.

IMHO “any -1 vote is a veto” sounds like a great recipe to ensure that no more core dev is promoted… It’s very easy to spot a single mistake of a candidate and exaggerate it to motivate a -1 vote. This is not how I want to promote contributors.

The 2/3 majority of my PEP 8015 is a deliberate choice to get more contributors onboard. As Gregory explained in length, we do have many protections against mistakes, and tooling to fix mistakes (like revert a change). I also became a strong believer of the mentorship church :slight_smile: Assigning a mentor before and after a promoting reduces the risk of mistake even more.


Scope of the governance PEPs
(Antoine Pitrou) #16

Let’s not exagerate this either. We all have a rather good idea of what a core dev, even though those ideas may not align exactly. It’s not like there are many different roles among core devs either.


(Victor Stinner) #17

(It’s kind of off-topic, but let me reply)

It’s a deliberate choice of me to write down everything and go into details, and I noticed that it’s a big difference between your PEP and mine. Once I hesitated to contact you to see how we can merge our two PEPs, but it seems like differences are big enough and I’m not sure that we can agree in which direction we want to move :slight_smile: It’s likely fine to have these two kinds of PEPs, so core devs can choose their favorite level of detail.

I’m not comfortable to vote for a governance which gives power to a group of people but don’t describe the exact limits of these powers. In this thread, I used the example of a vote to promote a contributor. In the past, the rules to promote a contributor were very flexible but IMHO the result is that it’s not fair. I also would like a stability for next years, so reduce the changes in governance. I prefer to decide most important points at once. I decided to not discuss “inactive core devs”, IMHO the governance PEP can be amended later to add a section/paragraph on that.

Note: My PEP doesn’t invent many new things, it only does 3 things: Formalize the existing concept of “Python teams”; Give more autonomy to Python teams; Replace the BDFL (Guido van Rossum) with a new “Python Steering Committee” (…). Most part of the PEP is a formalized form of what we did the last 10 years, but I made “small adjustments” like the way we vote to promote a contributor :slight_smile: