Original Guidelines

1. Make sure the bug category and bug group are correct. If they arecorrect, it is easier for someone interested in helping to findout, say, what all the open Tkinter bugs are.
2. If it’s a minor feature request that you don’t plan to addressright away, add it toPEP 42 or ask the owner to add it for you.If you add the bug toPEP 42, mark the bug as “feature request”,“later”, and “closed”; and add a comment to the bug saying thatthis is the case (mentioning the PEP explicitly).

   XXX do we prefer the tracker or PEP 42?

3. Assign the bug a reasonable priority. We don’t yet have a clearsense of what each priority should mean. One rule, however, isthat bugs with priority “urgent” or higher must be fixed beforethe next release.
4. If a bug report doesn’t have enough information to allow you toreproduce or diagnose it, ask the original submitter for moreinformation. If the original report is really thin and your emaildoesn’t get a response after a reasonable waiting period, you canclose the bug.
5. If you fix a bug, mark the status as “Fixed” and close it. In thecomments, include the SVN revision numbers of the commit(s). Inthe SVN checkin message, include the issue numberand anormal description of the change, mentioning the contributor if apatch was applied.
6. If you are assigned a bug that you are unable to deal with, assignit to someone else if you think they will be able to deal with it,otherwise it’s probably best to unassign it.

References

• https://bugs.python.org