PEP: 3 Title: Guidelines for Handling Bug Reports Version: $Revision$ Last-Modified: $Date$ Author: jeremy@alum.mit.edu (Jeremy Hylton) Status: Active Type: Informational Created: 25-Sep-2000 Post-History: Introduction This PEP contains guidelines for handling bug reports to the Python project on SourceForge[1]. Still to be done is to collect a list of people willing to handle bug reports and their areas of expertise. These are guidelines for the developers of Python, not the submitters of bugs. Those are at http://docs.python.org/lib/reporting-bugs.html (though this hardly seems the best place). Guidelines 1. Make sure the bug category and bug group are correct. If they are correct, it is easier for someone interested in helping to find out, say, what all the open Tkinter bugs are. 2. If it's a minor feature request that you don't plan to address right away, add it to PEP 42[2] or ask the owner to add it for you. If you add the bug to PEP 42, mark the bug as "feature request", "later", and "closed"; and add a comment to the bug saying that this is the case (mentioning the PEP explicitly). XXX do we prefer the feature request tracker or PEP 42? 3. Assign the bug a reasonable priority. We don't yet have a clear sense of what each priority should mean, except than 9 is highest and 1 is lowest. One rule, however, is that bugs with priority seven or higher must be fixed before the next release. 4. If a bug report doesn't have enough information to allow you to reproduce or diagnose it, ask the original submitter for more information. If the original report is really thin and your email doesn't get a response after a reasonable waiting period, you can close the bug. 5. If you fix a bug, mark the status as "Fixed" and close it. In the comments, include the CVS revision numbers of the affected files. In the CVS checkin message, include the SourceForge bug number *and* a normal description of the change. 6. If you are assigned a bug that you are unable to deal with, assign it to someone else if you think they will be able to deal with it, otherwise it's probably best to unassign it. References [1] http://sourceforge.net/projects/python [2] pep-0042.txt