Concerns about how we vote on new core developers

BTW, I’m mentoring Karthikeyan aka xtreak and want to promote him.
He is ready from my perspective, and I expect that his work with “Core Dev” hat on can make Python a little better without any harm.
He has triage permissions now and very active on PRs reviews already for areas if his expertise.

I believe that committer rights motivate for more reviews.
The review is done more carefully if the reviewer cares a responsibility on committing the PR and fixing possible outcome problems.
At least it is true for myself and, I believe, for all core devs.
If a new committer merges a PR that is not good a seasoned developer can fix it, e.g. by asking for reversion in a comment; it works well already.

We are all humans, this year I see a lot of revert commits done by very respected guys when an initial commit produced regressions on our build-bot fleet for example.
I did it a few times myself, that works fine I think.
Moreover, five or six years ago I’ve committed a patch from a newbie that introduced a regression in random.triangular without waiting from others review.
Raymond Hettinger corrected me, the patch was reverted by myself.
The lesson is learned: ask for the review from domain expert.

I’d like to have more responsible people in our team. A permissive policy can help to make Python better I think. The procedure is good now: a core developer takes a mentorship on a newbie and promote his a she after some period.

The question is: what formal requirements we have to a candidate?

Frankly, I did not review PRs of most of candidates that was elected last years.
I usually voted positively after looking on the candidate history and I saw the candidate activity for a long enough time on bugs tracker and reviews, the candidate is polite and responsive.

P.S.
Anyway, Karthikeyan and I decided to postpone his election until this discussion is finished.

9 Likes

I believe that Nathaniel’s summary of PEP 13 is a good summary of the “requirements”.

I enjoyed seeing Karthikeyan at the recent sprint, and I agree he would be a fine addition to the core dev team.

7 Likes

It seems like this discussion has petered off a bit. Are we just going to stick with the PEP 13 requirements? Stick with status quo ante where everyone votes based on their own criteria? Should we request a SC ruling on it to put this to bed, at least for now?

Well, you cannot prevent people from voting with their own criteria, even if they’re not what the standard says. So the best there can be is a list of guidelines that each core developer can follow, or not, to their wish.

2 Likes

Well, some discussions were heated, but it seems like the process is not stuck: many contributors have been promoted as core developers. It seems like the votes are closer to private people opinions than previously, thanks to anonymous votes. I think that it’s a sane process to discuss in public how we vote.