[Python-Dev] Moving bugs and patches through the pipeline more quickly

[Skip Montanaro]

I'm giving this message a new subject and redirecting it to python-dev,
mostly to consider the last two paragraphs.  It was originally part of a
thread about raw_input() not flushing stdout before emitting its prompt in
certain situations.

JG == Jonathan Gardner, MH == Michael Hudson.

    JG> I will write another bug report about the unresponsiveness to bug
    JG> reports as well, as there are a lot of bugs that aren't even
    JG> addressed at sourceforge.

    MH> Oh, that will help, sure.

    Jonathan> It is a bug. There needs to be a fix for it. Do you need more
    Jonathan> volunteers?  How do we get involved? Where do we sign up? What
    Jonathan> needs to be done? Maybe there needs to be more coordination
    Jonathan> and less coding at the top.

Two things should help move things through the mill faster:

    * If you think you know how to fix the bug, submit a patch along with
      your bug report to SF.

    * Assign it to just about anybody so someone is notified.  The
      exceptions here are that I don't think you should assign bugs to one
      of the PythonLabs Five (Guido, Tim, Barry, Jeremy, Fred).  Let one of
      the other developers decide if it warrants their attention.

As the Python user base grows I think we do need a way to expand the
developer pool without a lot of effort because the amount of feedback is
always going to be proportional to the number of users.  It's not
immediately obvious to me how this should happen.  The first expansion from
the original five to roughly the current crop of developers wasn't terribly
difficult, because for the most part Guido et al either knew them personally
or had a long enough exposure to them on the net to feel confident they
would make positive contributions.  The overall community is large enough
now that not all potentially good developers become visible easily.
Requiring a somewhat rigorous vetting process will consume more time for the
current developers and distract people from time working on the code base.
On the other hand, not requiring any vetting is likely to allow the
occasional donkey into the corral with the horses.

There are people here with experience in other large(r) open source projects
(Perl, Apache, Mozilla).  How do they handle this problem?

-- 
Skip Montanaro (skip@pobox.com - http://www.mojam.com/)