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.