| \label{reporting-bugs} |
| |
| Python is a mature programming language which has established a |
| reputation for stability. In order to maintain this reputation, the |
| developers would like to know of any deficiencies you find in Python |
| or its documentation. |
| |
| Before submitting a report, you will be required to log into SourceForge; |
| this will make it possible for the developers to contact you |
| for additional information if needed. It is not possible to submit a |
| bug report anonymously. |
| |
| All bug reports should be submitted via the Python Bug Tracker on |
| SourceForge (\url{http://sourceforge.net/bugs/?group_id=5470}). The |
| bug tracker offers a Web form which allows pertinent information to be |
| entered and submitted to the developers. |
| |
| The first step in filing a report is to determine whether the problem |
| has already been reported. The advantage in doing so, aside from |
| saving the developers time, is that you learn what has been done to |
| fix it; it may be that the problem has already been fixed for the next |
| release, or additional information is needed (in which case you are |
| welcome to provide it if you can!). To do this, search the bug |
| database using the search box near the bottom of the page. |
| |
| If the problem you're reporting is not already in the bug tracker, go |
| back to the Python Bug Tracker |
| (\url{http://sourceforge.net/bugs/?group_id=5470}). Select the |
| ``Submit a Bug'' link at the top of the page to open the bug reporting |
| form. |
| |
| The submission form has a number of fields. The only fields that are |
| required are the ``Summary'' and ``Details'' fields. For the summary, |
| enter a \emph{very} short description of the problem; less than ten |
| words is good. In the Details field, describe the problem in detail, |
| including what you expected to happen and what did happen. Be sure to |
| include the version of Python you used, whether any extension modules |
| were involved, and what hardware and software platform you were using |
| (including version information as appropriate). |
| |
| The only other field that you may want to set is the ``Category'' |
| field, which allows you to place the bug report into a broad category |
| (such as ``Documentation'' or ``Library''). |
| |
| Each bug report will be assigned to a developer who will determine |
| what needs to be done to correct the problem. You will |
| receive an update each time action is taken on the bug. |
| |
| |
| \begin{seealso} |
| \seetitle[http://www-mice.cs.ucl.ac.uk/multimedia/software/documentation/ReportingBugs.html]{How |
| to Report Bugs Effectively}{Article which goes into some |
| detail about how to create a useful bug report. This |
| describes what kind of information is useful and why it is |
| useful.} |
| |
| \seetitle[http://www.mozilla.org/quality/bug-writing-guidelines.html]{Bug |
| Writing Guidelines}{Information about writing a good bug |
| report. Some of this is specific to the Mozilla project, but |
| describes general good practices.} |
| \end{seealso} |