I've received just two requests from people to become developers:

Jeff Bauer (jeff@rubic.com) Bernard Yue (bernie@3captus.com)

Jeff I know personally, as the Developer's Day chair and the WinCE port maintainer. I don't know Bernie though I recognized his name. The posts I saw from him on google were all answers to questions other people had. Sort of looked like a mini-python-help archive. Bernie is the chief architect at 3captus in Hong Kong. They produce a product in Python that takes data feeds from other sources and creates XML-RPC or SOAP servers that can be used to generate subscription-based services.

I don't have a problem with either Jeff or Bernie being granted developer privileges. Feel free to add your two cents.

Great! I have one reservation, but maybe I should be talked out of it: I don't recall seeing patches submitted to SF by either of these. Maybe we need to give them a trial period where they submit their work to SF first? Soon enough we'll see if they're worth giving commit privileges based upon the volume of their output. Or am I being too conservative? It could be that the chore of uploading to SF is enough of a deterrent to make these good folks unproductive... Chicken or egg, really. Should we just go for it? --Guido van Rossum (home page: http://www.python.org/~guido/)

On Sat, 09 Mar 2002 11:05:59 -0500 Neal Norwitz wrote:

The breaking-in period is a good introduction and provides important feedback in the early stages of getting to know the code.

I agree. There is so little written down about how we operate, that it's probably hard for a new participant to get things right, regardless of interest or ability. Jeremy

I definitely pay special attention to checkins coming from people I don't have a long history with. Indeed, I caught the recent failure in imaplib.py first just because seeing a patch come by from a rare committer made me eager to update and test immediately. [Guido]

Or am I being too conservative? It could be that the chore of uploading to SF is enough of a deterrent to make these good folks unproductive... Chicken or egg, really. Should we just go for it?

I'd go for it, *provided* we aren't shy about revoking dev status when it doesn't work out. Revoke first, argue later <0.5 wink>.

Tim Peters writes:

I'd go for it, *provided* we aren't shy about revoking dev status when it doesn't work out. Revoke first, argue later <0.5 wink>.

+1. Martin

[Tim]

I'd go for it, *provided* we aren't shy about revoking dev status when it doesn't work out. Revoke first, argue later <0.5 wink>.

[Skip Montanaro]

I hope we don't have to get that harsh.

Locking out someone who's screwing up isn't harsh, it's healthy self-preservation. Don't be so fucking nice <wink>.

I wonder more about the people who are already listed as developers but never exercise their privilege.

So long as they don't get in the way, I don't mind. It's *silly* to keep inactive developers on the list, but until someone hacks the code base from an account they've forgotten they had, I don't think it's doing any real harm.

>> I wonder more about the people who are already listed as developers >> but never exercise their privilege. Tim> So long as they don't get in the way, I don't mind. It's *silly* Tim> to keep inactive developers on the list, but until someone hacks Tim> the code base from an account they've forgotten they had, I don't Tim> think it's doing any real harm. I was thinking more along the lines of someone seeing a bug and thinking, "this is really John Doe's specialty - i'll assign it to him", and then having the bug languish for ages. Skip

[Skip Montanaro]

I was thinking more along the lines of someone seeing a bug and thinking, "this is really John Doe's specialty - i'll assign it to him", and then having the bug languish for ages.

Well, on that basis nobody would have commit privs. That is, I've pretty much given up on assigning bugs to anyone, because they languish anyway, and better to have them unassigned than to make it look like someone specific is actually going to do something about them. Alas, for the most part, developers don't unassign themselves either.

Martin v. Loewis writes:

I think nobody would object if somebody goes through the bug database and unassigns any bug where the assignee never commented on, atleast for those bugs that are older than 6 months or some such. Could be even performed automatically.

Not a bad idea. It would need to check that the status isn't "pending", since those are waiting for submitter comment. We wouldn't want to unassign a bug assigned to a responsive developer who needs information from the submitter. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation