From a31b61dea742a3829eb9b83a0b1bae005fee554f Mon Sep 17 00:00:00 2001
From: Barry Warsaw <barry@python.org>
Date: Mon, 25 Sep 2000 16:08:03 +0000
Subject: [PATCH] PEP 3, Guidelines for Handling Bug Reports, assigned Jeremy
 Hylton.

---
 pep-0003.txt | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 pep-0003.txt

diff --git a/pep-0003.txt b/pep-0003.txt
new file mode 100644
index 000000000..cb7513596
--- /dev/null
+++ b/pep-0003.txt
@@ -0,0 +1,56 @@
+PEP: 3
+Title: Guidelines for Handling Bug Reports
+Version: $Revision$
+Author: jeremy@beopen.com (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.
+
+
+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).
+
+    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, send email to the original submittor
+       and ask 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, including 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.  The guys at PythonLabs get paid to
+       fix these bugs, so pick one of them if there is no other
+       obvious candidate.
+
+
+References
+
+    [1] http://sourceforge.net/projects/python
+    [2] pep-0042.txt