The release of Python 2.4alpha1 is currently scheduled for around July 1st. An organized effort to go through the bug database and close irrelevant bugs or apply fixes would be very useful.

Proposed schedule

The bug day will be on June XXX, 2004, from 9AM to 9PM EDT (1PM to 1AM GMT).

Participants will convene in the #python-dev IRC channel on irc.freenode.net. (XXX should we use a different channel?)

Procedures

Bugs should be processed in the fashion described by [http://www.python.org/peps/pep-0003.html PEP 3].

Someone with write access to the bug database needs to be around at all times. Having people around with CVS write access would be nice so that fixes can get checked in,but is not necessary; the primary purpose is to improve bug reports, and if the fixes are applied later, that's fine.

XXX How do people indicate which bugs they're working on? A wiki page? A channel message? The assigned-to field?

• - Maybe by setting the #channel title. (Not suitable, since there are multiple workers but only a single channel title)

XXX do we need to set up a web transcript of the channel? Perhaps a [http://usefulinc.com/chump/ chump bot?]

What to do:

• If a problem isn't logged on SF, log it.
• If it's logged, consider providing a patch that fixes the problem, or at least a simple test case that demonstrates the bug.
• If someone else has supplied a fix, see if this fix works for you, and post your results to the bug.
• Read the text of proposed patches and assess them for correctness and code quality.
• If there's a working fix, feel free to add a note asking for the fix to go into CVS. The SF bug tracker for Python has a _lot_ of bugs in it, and it's easy for bugs to be overlooked.

Other processes

The [http://dev.zope.org/CVS/BugDays Zope bug day] has a good description of what to do, though the details of the bug tracker are specified to the Zope project.

The GNOME community holds regular Bug Days; the procedures are described in [http://developer.gnome.org/projects/bugsquad/triage/faq.html their FAQ].