83 captures
25 Jun 2018 - 29 Dec 2025
Oct NOV Dec
25
2019 2020 2021
success
fail

About this capture

COLLECTED BY

Collection: Common Crawl

Web crawl data from Common Crawl.
TIMESTAMPS

The Wayback Machine - http://web.archive.org/web/20201125082614/https://devguide.python.org/tracker/
  

Navigation



● index
● next |
● previous |

●Python »
   Python Developer's Guide »  
|  






10. Issue Tracking


10.1. Using the Issue Tracker


If you think you have found a bug in Python, you can report it to the issue tracker. The issue tracker is also commonly referred to as bugs.python.org and bpo. Documentation bugs can also be reported there.
You can report bugs with the issue tracker itself to the meta tracker.
If you would like to file an issue about this devguide, please do so at the devguide repo.

10.1.1. Checking if a bug already exists


The first step before filing an issue report is to see whether the problem has already been reported. Checking if the problem is an existing issue will:

●help you see if the problem has already been resolved or has been fixed for the next release
●save time for you and the developers
●help you learn what needs to be done to fix it
●determine if additional information, such as how to replicate the issue, is needed

To do see if the issue already exists, search the bug database using the search box on the top of the issue tracker page. An advanced search is also available by clicking on “Search” in the sidebar.

10.1.2. Reporting an issue


If the problem you’re reporting is not already in the issue tracker, you need to log in by entering your user and password in the form on the left. If you don’t already have a tracker account, select the “Register” link or, if you use OpenID, one of the OpenID provider logos in the sidebar.
It is not possible to submit a bug report anonymously.
Once logged in, you can submit a bug by clicking on the “Create New” link in the sidebar.
The submission form has a number of fields, and they are described in detail in the Triaging an Issue page. This is a short summary:

●in the Title field, enter a very short description of the problem; less than ten words is good;
●in the Type field, select the type of your problem (usually behavior);
●if you know which Components and Versions are affected by the issue, you can select these too; otherwise, leave them blank;
●last but not least, you have to describe the problem in detail, including what you expected to happen, what did happen, and how to replicate the problem in the Comment field. Be sure to include whether any extension modules were involved, and what hardware and software platform you were using (including version information as appropriate).


10.1.3. Understanding the issue’s progress and status


The triaging team will take care of setting other fields, and possibly assign the issue to a specific developer. You will automatically receive an update each time an action is taken on the bug.


10.2. Disagreement With a Resolution on the Issue Tracker


As humans, we will have differences of opinions from time to time. First and foremost, please be respectful that care, thought, and volunteer time went into the resolution.
With this in mind, take some time to consider any comments made in association with the resolution of the issue. On reflection, the resolution steps may seem more reasonable than you initially thought.
If you still feel the resolution is incorrect, then raise a thoughtful question on python-dev. Further argument and disrespectful discourse on python-dev after a consensus has been reached amongst the core developers is unlikely to win any converts.
As a reminder, issues closed by a core developer have already been carefully considered. Please do not reopen a closed issue.

10.3. Helping Triage Issues


Once you know your way around how Python’s source files are structured and you are comfortable working with patches, a great way to contribute is to help triage issues. Do realize, though, that experience working on Python is needed in order to effectively help triage.
Around the clock, new issues are being opened on the issue tracker and existing issues are being updated. Every issue needs to be triaged to make sure various things are in proper order. Even without special privileges you can help with this process.

10.3.1. Classifying Reports


For bugs, an issue needs to:

●clearly explain the bug so it can be reproduced
●include all relevant platform details
●state what version(s) of Python are affected by the bug.

These are things you can help with once you have experience developing for Python:

●try reproducing the bug: For instance, if a bug is not clearly explained enough for you to reproduce it then there is a good chance a core developer won’t be able to either.
●see if the issue happens on a different Python version: It is always helpful to know if a bug not only affects the in-development version of Python, but whether it also affects other versions in maintenance mode.
●write a unit test: If the bug lacks a unit test that should end up in Python’s test suite, having that written can be very helpful.

This is all helpful as it allows triagers (i.e., people with the Developer role on the issue tracker) to properly classify an issue so it can be handled by the right core developers in a timely fashion.

10.3.2. Reviewing Patches


If an issue has a patch attached that has not been reviewed, you can help by making sure the patch:

●follows the style guides
●applies cleanly to an up-to-date clone
●is a good solution to the problem it is trying to solve
●includes proper tests
●includes proper documentation changes
●submitter is listed in Misc/ACKS, either already or the patch adds them

Doing all of this allows core developers and triagers to more quickly look for subtle issues that only people with extensive experience working on Python’s code base will notice.

10.3.3. Finding an Issue You Can Help With


If you want to help triage issues, you might also want to search for issues in modules which you have a working knowledge. Search for the name of a module in the issue tracker or use the advanced search to search for specific components (e.g. “Windows” if you are a Windows developer, “Extension Modules” if you are familiar with C, etc.). Finally you can use the “Random issue” link in the sidebar to pick random issues until you find an issue that you like. You may find old issues that can be closed, either because they are no longer valid or they have a patch that is ready to be committed, but no one has had the time to do so.
In the sidebar you can also find links to summaries for easy issues and issues with a patch.


10.4. Gaining the “Developer” Role on the Issue Tracker


When you have consistently shown the ability to properly help triage issues without guidance, you may request that you be given the “Developer” role on the issue tracker. You can make the request of any person who already has the Developer role. If they decide you are ready to gain the extra privileges on the tracker they will then act as a mentor to you until you are ready to do things entirely on your own. There is no set rule as to how many issues you need to have helped with before or how long you have been participating. The key requirements are that you show the desire to help, you are able to work well with others (especially those already with the Developer role), and that have a firm grasp of how to do things on the issue tracker properly on your own.
Gaining the Developer role will allow you to set any value on any issue in the tracker, releasing you from the burden of having to ask others to set values on an issue for you in order to properly triage something. This will not only help speed up and simplify your work in helping out, but also help lessen the workload for everyone by gaining your help.

10.5. The Meta Tracker


If you find an issue with the issue tracker, you can report it to the meta tracker. The meta tracker is where you file issues against anything you come across when working with the issue tracker itself (e.g you can’t attach a file, the layout is broken on your browser, Rietveld gave you an error, etc.).
If you want to contribute to the tracker you can get a checkout of the source and install a local instance where to experiment. You can find detailed instructions on the Tracker Development page.

See also

Issues with Python and documentation


The Python issue tracker
Where to report issues about Python.
The New-bugs-announce mailing list
Where all the new issues created on the tracker are reported.
The Python-bugs-list mailing list
Where all the changes to issues are reported.

The meta tracker and its development

The meta tracker
Where to report issues about the tracker itself.
The Tracker development wiki page
Instructions about setting up a local instance of the bug tracker.
The Tracker-discuss mailing list
Discussions about the bug tracker.



 



Table of Contents



●10. Issue Tracking

●10.1. Using the Issue Tracker

●10.1.1. Checking if a bug already exists
●10.1.2. Reporting an issue
●10.1.3. Understanding the issue’s progress and status


●10.2. Disagreement With a Resolution on the Issue Tracker
●10.3. Helping Triage Issues

●10.3.1. Classifying Reports
●10.3.2. Reviewing Patches
●10.3.3. Finding an Issue You Can Help With


●10.4. Gaining the “Developer” Role on the Issue Tracker
●10.5. The Meta Tracker


Sections



●1. Getting Started
●2. Where to Get Help
●3. Lifecycle of a Pull Request
●4. Running & Writing Tests
●5. Increase Test Coverage
●6. Helping with Documentation
●7. Documenting Python
●8. Silence Warnings From the Test Suite
●9. Fixing “easy” Issues (and Beyond)
●10. Issue Tracking

●10.1. Using the Issue Tracker

●10.1.1. Checking if a bug already exists
●10.1.2. Reporting an issue
●10.1.3. Understanding the issue’s progress and status


●10.2. Disagreement With a Resolution on the Issue Tracker
●10.3. Helping Triage Issues

●10.3.1. Classifying Reports
●10.3.2. Reviewing Patches
●10.3.3. Finding an Issue You Can Help With


●10.4. Gaining the “Developer” Role on the Issue Tracker
●10.5. The Meta Tracker


●11. Triaging an Issue
●12. Following Python’s Development
●13. Porting Python to a new platform
●14. How to Become a Core Developer
●15. Developer Log
●16. Accepting Pull Requests
●17. Development Cycle
●18. Continuous Integration
●19. Adding to the Stdlib
●20. Changing the Python Language
●21. Experts Index
●22. gdb Support
●23. Exploring CPython’s Internals
●24. Changing CPython’s Grammar
●25. Design of CPython’s Compiler
●26. Design of CPython’s Garbage Collector
●27. Updating standard library extension modules
●28. Coverity Scan
●29. Dynamic Analysis with Clang
●30. Running a buildbot worker
●31. Core Developer Motivations and Affiliations
●32. Git Bootcamp and Cheat Sheet
●33. Appendix: Topics

Previous topic


9. Fixing “easy” Issues (and Beyond)

Next topic


11. Triaging an Issue

This Page



● Show Source  







Navigation



● index
● next |
● previous |

●Python »
   Python Developer's Guide »  
|  


© Copyright 2011-2020, Python Software Foundation.  
 The Python Software Foundation is a non-profit corporation. Please donate.
 
 Last updated on Nov 10, 2020.  Found a bug?
  Created using Sphinx 1.8.5.