Warning
Some of these instrctions do not yet apply to Jython and are just a copy from CPython devguide We are planning to update our tracker so that these instructions do fully apply in the future.
When you have the Developer role on the issue tracker you are able to triage issues directly without any assistance.
Should be properly descriptive of what the issue is about. Occasionally people file an issue that either has too generic of a title or end up thinking they filed about X but in fact it turns out to be about Y and thus the title is now wrong.
Describes the type of issue. If something does not fit within any specific type then simply do not set it.
What is needed next to advance the issue. The stage needn’t be set until it is clear that the issue warrants fixing.
What part of Python is affected by the issue. This is a multi-select field. Be aware that what component is chosen may cause the issue to be auto-assigned, i.e. the issue tracker may automatically fill in the Assigned To field after you press Submit changes.
The following component(s) should be selected if the issue applies to:
The unittest and doctest frameworks in Lib/unittest and Lib/doctest.py.
The CPython tests in Lib/test, the test runner in Lib/test/regrtest.py and the Lib/test/support package.
The known versions of Python that the issue affects and should be fixed for. Thus if an issue for a new feature is assigned for e.g., Python 3.3 but is not applied before Python 3.3.0 is released, this field should be updated to say Python 3.4 as the version and drop Python 3.3.
How important is this issue?
As a guideline, critical and above are usually reserved for crashes, serious regressions or breakage of very important APIs. Whether a bug is a release blocker is a decision better left to the release manager so, in any doubt, add him or her to the nosy list.
Various flags about the issue. Multiple values are possible.
A list of people who may be interested in an issue. It is acceptable to add someone to the nosy list if you think the issue should be brought to their attention. Use the experts to know who wants to be added to the nosy list for issues targeting specific areas.
If you are logged in and have JavaScript enabled, you can use the [+] button to add yourself to the nosy list (remember to click on “Submit Changes” afterwards). Note that you are added to the nosy automatically when you submit a message. The nosy list also has an autocomplete that lets you search from the lists of developers and experts. The search is case-insensitive and works for real names, modules, interest areas, etc., and only adds the username(s) to the nosy once an entry is selected.
Who is expected to take the next step in resolving the issue. It is acceptable to assign an issue to someone if the issue cannot move forward without their help, e.g., they need to make a technical decision to allow the issue to move forward. Also consult the experts as certain stdlib modules should always be assigned to a specific person.
The issue requires the listed issue(s) to be resolved first before it can move forward.
The issue is a duplicate of the listed issue(s).
Why the issue is in its current state (not usually used for “open”).
HTTP link to a Mercurial repository that contains a patch for the issue. A Create Patch button will appear that computes a diff for the head revision of the remote branch and attaches it to the issue. The button supports only CPython patches.
If you don’t indicate a remote branch, default is used. You can indicate a remote branch by adding #BRANCH to the end of the URL.
Comments can automatically generate a link to various web pages if formatted properly.