On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord firstname.lastname@example.org 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").
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, 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.
I think that someone who has a mentor sponsoring them from the first should be able to go from zero to privileged in a very short period of time (a couple weeks perhaps, mostly depending on their activity level).
Someone without a pre-existing mentor could do the same, if their activity level is high enough, and would probably pick up a mentor along the way...or be mentored by #python-dev as a whole if they hang out there.
In other words, I think the goal is not just to add new developers to the community, but to continue to build a strong community of developers.
-- R. David Murray www.bitdance.com
(*) Even a seasoned developer from another project will make mistakes because some of our development process is a part of our culture and not written down, and even that which is written down is not necessarily easy for a newcomer to absorb by reading.