Over the last few times we have voted on giving someone commit rights, I have been developing an uneasiness that I mostly do not know how to resolve. So I wanted to bring it up here.
tl;dr Our current approach to “voting” on new committers is a potential deterrent to contribution. We should find a better way.
My fundamental concern is that our current process is adding to the barrier-to-entry for aspiring core developers. They may see the description of the candidate’s strengths and weaknesses and feel uncomfortable in continuing any effort to become a core developer. Specifically:
- they may think “what do I have to go through to become a core developer?”
- every negative vote in such a public forum is a potential source of embarrassment to the candidate
- the vote makes subjective evaluations (negative or positive) of the candidate very public (another source of embarrassment)
- people measure themselves against the descriptions of candidates and may erroneously conclude they aren’t good enough
All those things can be a strong deterrent to an aspiring core developer. The process almost feels like a right-of-passage sort of thing. For whatever reason it feels more public and adversarial than it used to. I realize we want more visibility for folks into the process of becoming a core developer, but I’m concerned that our current process for the final step (voting) is a potential deterrent.
Criteria to Get Commit Rights
What we really care about are the following:
- do we trust the candidate core developer?
- have they demonstrated that they really care about Python and its community?
- do they take the responsibility seriously?
- do they work well with others?
- are they willing to seek help when needed?
- are they willing to be accountable and fix their mistakes?
- do they respect the time of other volunteers?
- will giving them commit rights benefit Python?
Things we shouldn’t require, IMHO (expressed as extremes):
- mastery of our processes
- technical expertise on anything
- unlimited time to work on Python
- an expansive portfolio of past contributions
If we aren’t already, we should be extremely clear (in the devguide) about the criteria.
Favor the Mentor
One problem with our current process is that it operates on the premise that existing committers have informed opinions on viability of the candidate. I believe that most committers actually do not have enough context in order to make a definitive vote. Instead, we should rely more on the position of the person recommending the candidate (typically their mentor). We already trust them as a committer and we can count on the steering council to safeguard against a mentor’s judgement being clouded by over-exuberance. On top of that, any strong objections can be handled privately.
Ultimately we want to be inviting to new contributors, so we need to consider that relative to the process. I have some rough ideas on what we can do better, but have no illusions that they are the best approach nor a complete one.
Here are things I believe we could do to improve the process:
- drop the voting or make it permanently private (e.g. visible only to core developers)
- introduce an arbiter (e.g. steering council) for the promotion process, to manage feedback privately and announce result
- require a post-promotion mentor for every new core developer
- introduce a fixed probation period for new contributors
- adjust the promotion process to find a middle-ground between how we used to do it and how we do it now
A possible new process:
- existing committer publicly proposes giving commit rights to an active contributor
- provides brief summary
- solicits feedback on “voting” thread (see below)
- strong objections to be sent to steering council privately
- recognizes probation period
- accepts responsibility to mentor and monitor during probation period
- (maybe) voting thread like now, but non-binding and never made public
- strong objections sent to steering council privately
- allows steering council to measure negative response against positive one
- steering council communicates with mentor as necessary
- after set period of time steering council announces result
- decline only if any significant negative feedback
- encourage mentor to communicate feedback with candidate and work with them to address any concerns
- mentor announces publicly at end of promotion period
Regardless of the practical outcome of this discussion, the above captures my point of view. Thanks!