It feels to me that since we switched to poll-style voting, there has been an upsurge in “no” votes. In some ways that’s good (if people with reservations feel more comfortable expressing them) but I’m concerned that we don’t have an obvious way to identify what we need to do to improve our process for getting people ready for core developer status if we don’t get specific feedback from the “no” voters.
The problem with “no” votes without justification is that it leads to a situation where the candidate is rejected but there’s no actionable outcome that the candidate and mentor can use to improve their portfolio. It’s so much more helpful to say “No, because …”.
4 Likes
I have not voted yet, but the last time I voted no for someone it was because I thought the candidate needed more time to reach a point where I thought they didn’t need supervision. My suspicion in Abhilash’s case is also lack of exposure (e.g. has he spoken up that much on python-dev?).
Sure, but holy crap are you sticking your neck out when you do that. The last time there were “no” votes everyone had the same reaction of, “Why? Will someone speak up?” But that means outing yourself as someone who thinks someone shouldn’t be a core developer which puts you in the horrible position of that person knowing you don’t think they should be a core dev. And then if they don’t get it you’re the face of the reason why, and if they do then you still have to worry about what they think about you and the reasons why (and I would hope no one would ever consciously hold a grudge, but we’re human being with unconscious thoughts which we can’t easily control).
For me, when I have voted no these requests of people to publicly justify their no votes made me feel bad, like I’m letting everyone down and I almost felt guilty that I didn’t feel comfortable speaking publicly. Unless we set up some form of anonymous commenting on votes I personally would prefer we stop asking people to justify their votes (obviously if people want to they can speak up).
4 Likes
+1, I think that would be helpful,
That would require a separate setup for voting as Discourse doesn’t allow for that and I don’t know how much of a burden people want for this sort of thing (when the governance discussions were going on some people explicitly said they voted for systems that led to less votes which suggests it would need to be an extremely lightweight process).
Perhaps we could expand the options from just “yes” and “no”, replacing “no” with several options reflecting common reasons to vote “no”, e.g. “no: needs more experience”. We’d then also have a “no: other / unspecified reason” option for when the “standard” reasons aren’t a good fit.
5 Likes
That’s a very good point (and I apologise to anyone who felt bad as a result of my original comment). Anonymous comments would be helpful if the technical issues could be sorted out - but obviously that needs someone to do the work, and there are probably better things to spend time on.
However, I do think that the other part of my comment is worth exploring
Obviously the first question is whether that’s true (and I haven’t checked the records). But if it is, why is that? Is it simply that the anonymous voting allows people to more freely express reservations? Or is the more formal voting process resulting in people propose candidates who are less “visible” in the community than previously (when the informal process meant people had to “build a reputation” a bit more)? Or something else?
Again, this may be good or bad. But understanding any biases or limitations in whatever system we’re using can only help us improve.
I’m extremely uneasy about the suggestion to allow anonymous posting. Core developers have a responsibility and I think we should be able to stand by the opinions we express publicly.
4 Likes
Practically speaking, though, we will likely either get no justifications for -1 votes or, if a comment is required for -1, people will be reluctant to cast -1 votes. It may be that we want “core developer” to be a low bar to clear and that we want to discourage -1 votes, but we should probably be aware that this is the dynamic we are encouraging.
Ideally, we would have a mechanism that preserves both the safety of casting a -1 vote without harming your relationship to the candidate while also encouraging people to help the candidate improve for a subsequent promotion.
I think we’re going to have to live with the fact that some people don’t explain their -1 vote (just as some people don’t explain their +1 vote, either). It would just be nice if at least some of the -1 voters did post an explanation.
1 Like
I think @taleinat’s suggestion of adding some/several standard specific “no” options to the poll is probably the best we can do as far as allowing anonymous dissent and getting useful feedback from it.
I think it would also be useful to switch from yes/no to +1/+0/-0/-1 (and add verbose -1 options) to allow those who don’t have strong feelings on the matter to cast a non-binding vote.
But what to do if someone gets mostly lacklustre votes but still gets in because they had just enough +1 votes? That also places the new core dev in a rotten position of knowing they weren’t really wanted that strongly, just that people didn’t vote against them.
If people want some canned “-1 with explanation” options we can try that out, but someone needs to come up with that initial list for the next vote.
Overkill alert
Running a SecureDrop instance to get anonymous feedback from core developers can be done. No way to get understand who said what unless the English gives it away.
2 Likes