Movatterモバイル変換

Important

This is part of aDraft of the Python Contributor’s Guide.Text in square brackets are notes about content to fill in.Currently, the devguide and this new Contributor’s Guide co-exist in therepo. We are using Sphinx include directives to demonstrate the re-organization.The final Contributor’s Guide will replace the devguide with content in only oneplace.We welcome help with this!

Triaging an issue¶

This section of the devguide documents theissue tracker forusers and developers.

Checklist for triaging¶

Read the initial message and the comments.
Check that the title is reasonably concise, while including enough specificsso that those scanning the list of issues can quickly identify its topic.
For pull requests, ensure that the corresponding issue is added beforethe title (gh-NNNNN:Title).
Set all the relevantlabels.
Where appropriate, set theAssignees,Reviewers,Project fields, and possibly @mention relevant people.
You might also leave a brief comment about the proposed next action needed.If there is a long message list, a summary can be very helpful.
If the issue is clearly invalid (unrelated to CPython, duplicate, spam, etc),you can use GitHub’s “Close as not planned” option.

Assignees¶

This field indicates who is expected to take the next step in resolvingthe issue.

It is acceptable to assign an issue to someone if the issue cannot moveforward without their help; for example, they need to make a technical decision onhow to proceed. Also consult theExperts index as certainstdlib modules should always be assigned to a specific person.

Note that in order to assign an issue to someone, that personmust bea team member, likely a triager or a core developer.

Helping triage issues¶

Once you know your way around how Python’s source files arestructured and you are comfortable with the workflow, a great way tocontribute is to help triage issues. Do realize, though, that experienceworking on Python is needed in order to effectively help triage.

Around the clock, new issues are being opened on theissue tracker and existing issues are being updated. Every issue needs to betriaged to make sure everything runs smoothly.

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 forPython:

Try reproducing the bug: if it is not explained clearlyenough for you to reproduce it, then there is a good chance a core developerwon’t be able to either.
See if the issue happens on a different Python version: it is always helpfulto know if a bug not only affects the in-development version of Python, butwhether it also affects other versions in maintenance mode.
Write a unit test: if the bug lacks a unit test that should end up inPython’s test suite, having that written can be very helpful.

This is all helpful as it allows members of thetriage teamto properly classify an issue so it can be handled by the right core developersin a timely fashion.

Reviewing pull requests¶

If an issue has a linked pull request that has not been reviewed,you can help by making sure the pull request:

is a good solution to the problem it is trying to solve
follows the style guides (PEP 7,PEP 8,Style guide, etc.)
includes proper tests
includes proper documentation changes
includes aNEWS entry (if needed)
doesn’t have conflicts with themain branch
doesn’t have failing CI checks

Doing all of this allows core developers andtriagersto more quickly look for subtle issues that only people with extensiveexperience working on Python’s code base will notice.

Finding an issue you can help with¶

If you want to help with triaging, you might also want to search for issuesin modules for which you have a working knowledge. Search for the name of amodule in the issue tracker, filter by label, or use theadvanced searchto find these issues.