diff --git a/pep-0003.txt b/pep-0003.txt index daca70295..a1dbda4a8 100644 --- a/pep-0003.txt +++ b/pep-0003.txt @@ -11,7 +11,7 @@ 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 + Python project at the tracker [1]. Still to be done is to collect a list of people willing to handle bug reports and their areas of expertise. @@ -35,12 +35,12 @@ Guidelines 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? + XXX do we prefer the 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. + clear sense of what each priority should mean. One rule, + however, is that bugs with priority "urgent" 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 @@ -49,10 +49,10 @@ Guidelines 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. + the comments, include the SVN revision numbers of the commit(s). + In the SVN checkin message, include the issue number *and* a + normal description of the change, mentioning the contributor + if a patch was applied. 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 @@ -61,4 +61,4 @@ Guidelines References - [1] http://sourceforge.net/projects/python + [1] http://bugs.python.org/