| Fred Drake | cb0a0b3 | 2000-09-21 21:32:14 +0000 | [diff] [blame] | 1 | \label{reporting-bugs} |
| 2 | |
| 3 | Python is a mature programming language which has established a |
| 4 | reputation for stability. In order to maintain this reputation, the |
| 5 | developers would like to know of any deficiencies you find in Python |
| 6 | or its documentation. |
| 7 | |
| Fred Drake | c121745 | 2002-02-04 21:43:08 +0000 | [diff] [blame] | 8 | Before submitting a report, you will be required to log into SourceForge; |
| 9 | this will make it possible for the developers to contact you |
| 10 | for additional information if needed. It is not possible to submit a |
| 11 | bug report anonymously. |
| 12 | |
| Fred Drake | cb0a0b3 | 2000-09-21 21:32:14 +0000 | [diff] [blame] | 13 | All bug reports should be submitted via the Python Bug Tracker on |
| 14 | SourceForge (\url{http://sourceforge.net/bugs/?group_id=5470}). The |
| 15 | bug tracker offers a Web form which allows pertinent information to be |
| 16 | entered and submitted to the developers. |
| 17 | |
| Fred Drake | cb0a0b3 | 2000-09-21 21:32:14 +0000 | [diff] [blame] | 18 | The first step in filing a report is to determine whether the problem |
| 19 | has already been reported. The advantage in doing so, aside from |
| 20 | saving the developers time, is that you learn what has been done to |
| 21 | fix it; it may be that the problem has already been fixed for the next |
| 22 | release, or additional information is needed (in which case you are |
| 23 | welcome to provide it if you can!). To do this, search the bug |
| 24 | database using the search box near the bottom of the page. |
| 25 | |
| 26 | If the problem you're reporting is not already in the bug tracker, go |
| 27 | back to the Python Bug Tracker |
| 28 | (\url{http://sourceforge.net/bugs/?group_id=5470}). Select the |
| 29 | ``Submit a Bug'' link at the top of the page to open the bug reporting |
| 30 | form. |
| 31 | |
| 32 | The submission form has a number of fields. The only fields that are |
| 33 | required are the ``Summary'' and ``Details'' fields. For the summary, |
| 34 | enter a \emph{very} short description of the problem; less than ten |
| 35 | words is good. In the Details field, describe the problem in detail, |
| 36 | including what you expected to happen and what did happen. Be sure to |
| 37 | include the version of Python you used, whether any extension modules |
| 38 | were involved, and what hardware and software platform you were using |
| 39 | (including version information as appropriate). |
| 40 | |
| 41 | The only other field that you may want to set is the ``Category'' |
| 42 | field, which allows you to place the bug report into a broad category |
| 43 | (such as ``Documentation'' or ``Library''). |
| 44 | |
| 45 | Each bug report will be assigned to a developer who will determine |
| Fred Drake | c121745 | 2002-02-04 21:43:08 +0000 | [diff] [blame] | 46 | what needs to be done to correct the problem. You will |
| Fred Drake | cb0a0b3 | 2000-09-21 21:32:14 +0000 | [diff] [blame] | 47 | receive an update each time action is taken on the bug. |
| 48 | |
| 49 | |
| 50 | \begin{seealso} |
| 51 | \seetitle[http://www-mice.cs.ucl.ac.uk/multimedia/software/documentation/ReportingBugs.html]{How |
| 52 | to Report Bugs Effectively}{Article which goes into some |
| 53 | detail about how to create a useful bug report. This |
| 54 | describes what kind of information is useful and why it is |
| 55 | useful.} |
| 56 | |
| 57 | \seetitle[http://www.mozilla.org/quality/bug-writing-guidelines.html]{Bug |
| 58 | Writing Guidelines}{Information about writing a good bug |
| 59 | report. Some of this is specific to the Mozilla project, but |
| 60 | describes general good practices.} |
| 61 | \end{seealso} |