Type labels¶

These labels are used to specify the type of issue:

• type-bug: for unexpected behaviors, bugs, or exceptions(not hard crashes).

• type-crash: for hard crashes of the interpreter, possibly with acore dump.

• type-feature: for feature requests or enhancements.Feature requests do not needversion labels;it is implicit that features are added to themain branch only.TheIdeas Discourse category can be used to discuss enhancementsbefore filing an issue.

• type-refactor: for general code refactoring thatdoes not change user-facing behaviour.

• type-security: for security issues.See alsoReporting security issues in Python.

Component labels¶

These labels are mostly used to specify whichpart of the codebase is affected by the issue/PR:

• stdlib: for standard library modules in theLibdirectory (written in Python).

• extension-modules: for standard library modules in theModules directory (written in C).

• interpreter-core: for changes related to the interpreter core intheObjects,Python,Grammar,andParser dirs (written mostly in C).

• docs: for documentation in theDoc directory(written inreStructuredText), docstrings, and code comments.

• tests: for tests in theLib/test directory(written in Python) and other changes related to tests,unittest,ordoctest.

OS labels¶

These labels are used to specify which operating systems are affected.Since most issues either affect all systems or are specific to Unix,we don’t have a dedicated Unix label.

• OS-android

• OS-freebsd

• OS-ios

• OS-linux

• OS-windows

Use theOS-unsupported label for issues on platforms outside thesupport tiers defined inPEP 11. Applying this label adds the issue toa GitHub project whereit can be categorized further.See also thePlatform experts list.

Topic labels¶

These labels are used to denote the specific topic area, if any, ofthe issue/PR. This includes both specific modules/packages and genericinterest areas.

Adding these labels is also a way to notify the relevant experts, sincethey are encouraged to subscribe to them. Depending on the label,this might also automatically add the issue to a GitHub project.

You can see thefull list of topic labels on GitHub.

Version labels¶

These labels are used to indicate which versions of Python are affected.The available version labels (with the form3.N) are updatedwhenever new feature releases are created or retired.

See alsothe branch status pagefor a list of active branches.

Other labels¶

• build/performance: for issues relatedto the build process or performance, respectively.

• easy: for issues that are considered easy.

• infra: for issues related to the infrastructure of theproject (for example, GitHub Actions, dependabot, the buildbots).

• pending: for issues/PRs that will be closed unless furtherfeedback is provided.

• release-blocker/deferred-blocker: for issues/PRsthat, unless fixed, will hold the current or next release respectively.Triagers may set these labels for issues that must be fixed before a release,and thebranch’s release managerwill review them and determine if they indeed qualify,removing or retaining the label as appropriate.

• sprint: for easier filtering of issues/PRs being worked onduring official sprints.

• stale: for issues/PRs that have been inactive for a while.

• triaged: for issues that have been accepted as valid by a triager.

Labels specific to PRs¶

The following labels only apply toPull Requests.They are either set automatically by bots, or added by humansto trigger specific bot behaviors.

• DO-NOT-MERGE: for PRs that shouldn’t be merged in their currentstate. It also preventsmiss-islington from being able to automaticallymerge the PR.

• needsbackporttoX.Y: used to indicate which branches the PRshould be backported to. Once the PR is merged,miss-islington willautomatically attempt to create backport PRs for the versions indicatedby these labels.See alsothe status of the Python branches for a listof branches and the type of PRs that can be backported to them.

• skip issue: for trivial changes (such astypo fixes, commentchanges, and section rephrases) that don’t require a corresponding issue.

• skip news: for PRs that don’t need a NEWS entry.TheUpdating NEWS and What’s New in Python section covers in details in which cases the NEWS entrycan be skipped.

• 🔨 test-with-buildbots: usedto test the latest commit with thebuildbot fleet whenevermore testing is required before merging. This may take multiple hours tocomplete.

• 🔨 test-with-refleak-buildbots:Run the reference leak buildbots on the latest commit. Useful for when thecode might be leaky.

• awaitingaction: these labels are applied and used bybedevereto indicate the stage of a PR and should not be applied manually.