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.
- Wrong or unexpected behavior, result, or exception. This includes most of
- Hard crashes of the Python interpreter – possibly with a core
dump or a Windows error box.
- compile error
- Errors reported by the compiler while compiling Python.
- resource usage
- Situations where too many resources (e.g. memory) are used.
- Issues that might have security implications. If you think the issue
should not be made public, please report it to firstname.lastname@example.org instead.
- Situations where too much time is necessary to complete the task.
- Issues that propose the addition of new functionality, such as new
functions, classes, modules, or even new arguments for existing functions.
Also used for improvements in the documentation and test suite and for
What is needed next to advance the issue. The stage needn’t be set until
it is clear that the issue warrants fixing.
- test needed
- The bug reporter should post a script or instructions to let a triager or
developer reproduce the issue.
- needs patch
- The issue lacks a patch to solve the problem (i.e. fixing the bug, or
adding the requested improvement).
- patch review
- There is a patch, but it needs reviewing or is in the process of being
reviewed. This can be done by any triager as well as a core developer.
- commit review
- A triager performed a patch review and it looks good to them, but a core
developer needs to commit the patch (and do a quick once-over to make sure
nothing was overlooked).
- The issue is considered closed and dealt with.
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?
- This is for low-impact bugs, or feature requests of little utility.
- The default value for most issues, which deserve fixing but without
any urgency to do so.
- Make some effort to fix the issue before the next final release.
- This issue should definitely be fixed before the next final release.
- deferred blocker
- The issue will not hold up the next release, but will be promoted to a
release blocker for the following release, e.g., won’t block the next
release of a1 but will block a2.
- release blocker
- The issue must be fixed before any release is made, e.g., will block the
next release even if it is an alpha release.
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 buildbot triggered the issue being reported.
- Fixing the issue should not take longer than a day for someone new to
contributing to Python to solve.
- The issue would fit as, or is related to, a GSoC project.
- needs review
- The patch attached to the issue is in need of a review.
- There is a patch attached to the issue.
- The issue is a regression in 3.3.
11.1.8. Nosy List
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 Index to know who wants to be added to the nosy
list for issues targeting specific areas.
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 Index. 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.
11.1.9. Assigned To
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 Index 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
The issue is a duplicate of the listed issue(s).
- Issue is not resolved.
- The issue has no clear solution , e.g., no agreement on a technical
solution or if it is even a problem worth fixing.
- The issue is blocked until someone (often the
OP) provides some critical information;
the issue will be closed after a set amount of time if no reply comes in.
Useful when someone opens an issue that lacks enough information to
reproduce the bug reported. Requesting additional information and setting
status to pending indicates that the issue should be closed if the
necessary information is never provided.
- The issue has been resolved (somehow).
Why the issue is in its current state (not usually used for “open”).
- Duplicate of another issue; should have the Superseder field filled out.
- A fix for the issue was committed.
- For some reason the issue is invalid (e.g. the perceived problem is not
a bug in Python).
- Issue is to be worked on at a later date.
- out of date
- The issue has already been fixed, or the problem doesn’t exist anymore
for other reasons.
- Issue will not be worked on at the moment.
- Issue was rejected (especially for feature requests).
- The issue is acting as a reminder for someone.
- wont fix
- Issue will not be fixed, typically because it would cause a
- works for me
- Bug cannot be reproduced.
11.1.14. Mercurial Repository
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.