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

Stephen J. Turnbull stephen at xemacs.org
Mon Apr 26 05:48:10 CEST 2010


Tres Seaver writes:

 > I think there is a definite "unpriced externality" to keeping the
 > process barriers high here.

The proposed trial period is not a high barrier, except to those who
really didn't want to being doing the work anyway.  Note that There is
also an externality to having accounts with unused privileges lying
around the server.

The fact is that there just aren't very many people willing to do the
work.  I've considered doing it (especially since Daniel has gone out
of his way to inform me of fixes to the Python tracker, since I
maintain a couple of Roundup instances for other projects), but I just
don't have the time.  Both personally and in general, I really don't
think this barrier is high enough that removal would make a
significant difference.  The example of Daniel Diniz *is* salient.  A
couple of weeks of doing things the long way (which forces the mentor
to look at them, among other things), a week for discussion by the
people who work most closely with the candidate and the administrators
of the host/tracker where privileges will be granted -- if this
matters in the grand scheme of things, the person probably didn't want
to be doing the work in the first place.  They should find a way to
contribute more suited to their capabilities and interests.

 > I am not arguing for "making exceptions for friends" here;  rather that
 > the acknowledged issues with inclusiveness / espansion of the developer
 > community require making changes to the rules to encourage more
 > participation.
 > 
 > BTW, language like "prov[ing] their motivation" is itself demotivating,
 > and likely contributes to the status quo ante.

Unlikely IMHO.  Yes, if you allow anybody to make changes, you'll get
more contributions.  You'll also create a lot of janitorial work for
the people who take care of project hygiene, and *they* will lose
incentive.  That is a *really* big risk.

Remember, because of the sexiness/mission criticality of the Linux
kernel, a couple of *hundred* people world wide get paid to spend
significant amounts of time on it.  That's not the comparison to make
here; Python is a great language, but there are several reasonable
alternatives, and it's not suited to all projects.  Look at the 99.5%
of Sourceforge projects (or the fact that GNU Savannah can't attract
contributions to get the "official" GNU VCS -- Bazaar -- working
properly), and you'll see that Python actually has a really well-
functioning, attractive process.



More information about the Python-Dev mailing list