[Python-Dev] Enhanced tracker privileges for dangerjim to do triage.

[Steven D'Aprano]

On Tue, 27 Apr 2010 01:42:10 am R. David Murray wrote:
> On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord 
<fuzzyman at voidspace.org.uk> wrote:
> > So the question remains - for *tracker* privileges, should the
> > recommendation and commitment to mentor from an established
> > commiter be sufficient (and therefore a standard part of our
> > process)?
>
> I think that in a technical sense a commitment to mentoring by an
> established contributor would be enough.  But it seems to me that
> there are a couple of arguments against it being sufficient in the
> wider picture.
>
> The first is that open source projects tend to be meritocracies.
> An otherwise unknown person being introduced to the community and
> immediately given privileges *just* because of the recommendation of
> another person may feel (especially to the non privileged) like a
> kind of nepotism.  ("It's not what you contribute, it's who you
> know").

Hang on, are we talking about paying these people? Giving them keys to 
the executive washroom? Flying them around the world on First Class 
flights on expensive junkets? Fame and fortune? What privileges are we 
giving them?

Oh yeah, the privilege of working for nothing in a thankless job that 
takes time and effort and returns nothing but a bullet point on your 
resume and the knowledge that you've given back to an Open Source 
project.

Who are we worried about offending? The crowds on the Internet who never 
volunteer for anything, who never submit patches, let alone offer to do 
the unglamourous work? I think we worry too much about them -- they 
complain about everything, and have the attention span of a gnat. (Yes, 
I have had a bad day, why do you ask? *wink*)

Other committers? I would hope that, being members of good standing in a 
meritocracy, they can recognise the difference between "I want my mate 
to be given triaging privileges because he's my mate", and "I want him 
to have triaging privileges because I trust him to do a good job".

As I see it, the only people who might have a valid reason to be 
offended or annoyed are those who have volunteered but were rejected 
for some reason --perhaps because their skills aren't good enough, 
perhaps because nobody could vouch that their skills are good enough. 
Well, life is hard, get over it. In a meritocracy it isn't enough to be 
good at what you do, you also have to be known to be good. DangerJim 
has (apparently -- I don't know him myself) spent years building *both* 
his technical skills and his reputation.

Sean is willing to vouch for him and mentor him, and if Sean himself has 
a sufficiently high reputation that Python-Dev is willing to trust his 
judgement, then I can't see any reason to reject the offer. What's the 
worst that could happen? He'll do a bad job of triaging bugs, other 
committers will have to step in and fix it, and Sean will be 
embarrassed. Nothing irreparable, except possibly Sean's reputation as 
a judge of others. I don't see this as a high risk move: we're not 
making him BDFL on Sean's say-so.


> The second is in some ways a subtle variation on the first.  If a new
> person, even with a well respected mentor standing behind them, first
> approaches the tracker by reviewing and commenting without
> privileges, it does two things: it allows people in the community who
> are not the mentor to get a sense of them, 

Yes, they will have the opportunity, but will they take it?

I've submitted two recent patches which have apparently been swallowed 
by the black hole of "too much to do, too little time to do it". Am I 
bitter? No, of course not -- I understand that the committers have much 
to do, I'm a comparative unknown, and while the patches scratch my 
itch, they obviously don't scratch anyone else's. But this does 
demonstrate that just because people have the opportunity to "get a 
sense of them", doesn't mean that they actually will do so -- if 
anything, the opposite is the case. By increasing the number of 
untrusted contributors relative to trusted committers, you increase the 
burden on committers and lower the chances that they will actually 
review patches. This in turn discourages people from contributing, and 
the cycle continues.

Instead of this vicious circle, I believe that fast-tracking people on 
the strength of recommendations from *trusted* members is a good way of 
getting a virtuous circle: more people available to review patches, 
which means more competent contributors will gain enough of a 
reputation to be given committer privileges.


> and it gives them the 
> benefit of input from people other than the mentor, and all of this
> happens *before* they have the opportunity (and the worry) of making
> mistakes(*). Both of these things serve to build community, and the
> second, IMO, results in a stronger, more confident contributor.

Surely this will depend on the personality of the contributor? Not 
everyone appreciates being examined like that, even in an informal 
ad-hoc way, and while they might suck it up and accept it, they don't 
necessarily benefit from it. I reckon that for every one or two 
would-be contributors who value having that early oversight, you 
probably alienate a third enough that he goes elsewhere.


-- 
Steven D'Aprano