Label categories

When doing issue refinement, we typically start from these steps:

Add kind labels to communicate what kind of issue this is.
Add impact labels to communicate how this will impact the project.
Potentially add needs labels
Add sizing with size labels
if bug) add a pX label

Tip: search for kind/ etc. to open the alternatives.

kind

Generally the kind labels are used to communicate what kind of tasks they are. This is useful mainly to help the team prioritize and put the right resources on (and figure out if they need something outside of the team).

kind/bug
Used for some behavior that is incorrect or out of spec
kind/design
Used for design or user experience related issues
kind/engineering
Work that is not visible to an external user
kind/enhancement
Improvements or new features
kind/dependencies
Bumping dependencies
kind/epic
Large new features or investments
kind/question
Questions about existing features

impact

The idea behind the impact labels is to clearly show what this issue impacts, so it's clearer to everyone. Stuff like costs or breaking changes needs to be visible so the right people know, using impact labels is how.

impact/breaking
Backwards incompatible
impact/approved-breaking-change
Backwards incompatible changes that are approved
impact/changelog
Changelog related
impact/cost
Cost related
impact/no-changelog-required
Issue does not require changelog changes
impact/performance
Performance related
impact/reliability
Reliability related
impact/security
Security related
impact/usability
Usability related

needs

Needs are requirements/needs that this issue has to be completed.

The needs are a bit different in how they are written. Instead of needs/ it is needs-. Don't know why.

needs-design
Needs input from design/UX
needs-refinement
Needs grooming to become refinement
needs-product
Needs input from product management
needs-repro
Needs repro steps before it can be triaged or fixed
needs-triage
Needs attention from the triage team
needs-feedback
Needs some feedback from user or end-user
needs-upstream
Needs a change in an upstream dependency

(optional) size

size/L
Estimated effort to complete (up to 10 days).
size/M
Estimated effort to complete (up to 5 days).
size/S
Estimated effort to complete (1-2 days).

(optional) resolution

We use resolution to communicate how what closed the issue. This is useful when trying to report on issues, and how they are resolved.

resolution/duplicate
Duplicate of another issue
resolution/fixed
Fixed
resolution/invalid
Nulled/invalid
resolution/no-repro
Could not reproduce the issue
resolution/wont-fix
Will not fix for some reason