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.