[Python-Dev] Encouraging developers

[Stephen J. Turnbull]

Josiah Carlson writes:

 > > And the best way to encourage someone to maintain a package is... 
 > > accepting their patches.
 > 
 > And that's what I think is bull.  Whether or not we want or need
 > maintainers for module or package X is independant of the fact that user
 > Y has submitted a patch for it.  If they say, "I would like to become
 > maintainer of package X", ok, if they are better than not having a
 > maintainer, great.  But to ask them to be a maintainer of an
 > unmaintained package because they submitted a patch?

Actually, I regularly do this (three or four times a year, I'd guess,
it would be more if there were more submitters) if the person seems
sane.  But I *don't* apply the patch!  The condition is that he sign
on to our process and shepherd his own patch through it (including the
risk that a reviewer will ask for changes).  The answer I typically
get is "No, I'd rather wait than work.  But thanks for asking!"  :-)

Caveat: the XEmacs packages where I do this are mostly end-user
applications like MUAs or programmer editor modes, so it doesn't
matter to anyone but the end-users if they break.  Our process
provides multiple workarounds for such a situation, and we do keep an
eye on new maintainers to help out with emergency response in those
cases, so that risk is considered acceptable.  The users themselves
generally accept one or two new maintainer problems with good humor,
since they're proof positive that somebody has taken an interest in
their package.

The cost to this system is that you need people willing to mentor the
new package maintainers.  It works well for XEmacs because the cost is
very low (as I just described).  I think for Python's stdlib the cost
would be substantially higher, but it might very well be worth it.

 > > A little game: without looking at this patch of mine, 
 > > how much are you willing to bet that committing that patch is going to 
 > > cause pain the Python community and other stdlib maintainers, to cause 
 > > headaches like deprecations because of broken interfaces, and whatnot?

I'm glad you asked.  More than half of my commits (and way more than
half the LOC) in February were due to broken previous patches that
were approved merely because they addressed a bug and applied without
fuzz to HEAD. :-(

Committing patches unreviewed is a terrible idea.