Skip to content

Label Issues

Permission Required: Contributor

One of the most important tasks in handling issues is labeling them usefully and accurately. All other tasks involving issues ultimately rely on the issue being classified in such a way that relevant parties looking to do their own tasks can find them quickly.

In order to label issues, open up the list of unlabeled issues and, from newest to oldest, read through each one and apply issue labels according to the table below. If you’re unsure about what label to apply, skip the issue and try the next one: don’t feel obligated to label each and every issue yourself!

LabelApply WhenNotes
blockedAdded to issues or pull requests that are blocked by either some other feature or bug fix required to complete the workCan be combined with other labels such as fix, feat and critical.
choreAdded to issues or pull requests that affect any of the documentation, tests or attempt to refactor the project.These issues should not change code such that a version bump would be required.
criticalAdded to fix issues if the problem described makes the code completely unusable in a common situation.
duplicateAdded to issues or PRs that refer to the exact same issue as another one that’s been previously labeled.Duplicate issues should be marked and closed right away, with a message referencing the issue it’s a duplicate of (with #123)
featAdded to feature requests, PRs, or documentation issues that are purely additive: the code or docs currently work as expected, but a change is being requested or suggested.
fixCases where the code (or documentation) is behaving in a way it wasn’t intended to.If something is happening that surprises the user but does not go against the way the code is designed, it should use the feat label.
good first issueApplied by Contributors or higher to issues that they consider good introductions to the project for people who have not contributed before. These are not necessarily “easy”, but rather focused around how much context is necessary in order to understand what needs to be done for this project in particular.Existing project members are expected to stay away from these unless they increase in priority.
help wantedApplied by Contributors or higher to issues and PRs that they would like to get outside help for. Generally, this means it’s lower priority for the maintainer team to itself implement, but that the community is encouraged to pick up if they canNever applied on first-pass labeling.
in progressApplied by Contributors or higher to PRs that are pending some work before they’re ready for review.The original PR submitter should @mention the team member that applied the label once the PR is complete.
needs clarificationApplied by Contributors or higher to issues or PRs that require a bit more information in order to move forward.The original submitter should @mention the team member that applied the label once clarification has been provided.
next releaseApplied by Maintainers or higher to PRs that have been approved and are tagged for the next release.Generally we don’t hold up PRs as we release as soon as possible, but in cases where we can’t, this is handy to call out.
supportThis issue is either asking a question about how to use the project, clarifying the reason for unexpected behavior, or possibly reporting a bug but does not have enough detail yet to determine whether it would count as such.The label should be switched to fix if reliable reproduction steps are provided. Issues primarily with unintended configurations of a user’s environment are not considered bugs, even if they cause issues.
wontfixLabelers may apply this label to issues that have nothing at all to do with the project or are otherwise entirely outside of its scope/sphere of influence. Committers may apply this label and close an issue or PR if they decide to pass on an otherwise relevant issue.The issue or PR should be closed as soon as the label is applied, and a clear explanation provided of why the label was used. Contributors are free to contest the labeling, but the decision ultimately falls on committers as to whether to accept something or not.