-
Notifications
You must be signed in to change notification settings - Fork 715
Issue Labelling
David edited this page Feb 1, 2017
·
10 revisions
-
feature - new end user functionality, available sublabels for estimates:
- estimate/hours, estimate/days, estimate/weeks - ballpark estimate for feature
-
bug - broken end use or developer functionality; not working as the developers intended it, available sublabels for priority:
- bug/P0 - Urgent issue that caused someone to be paged, must be updated hourly
- bug/P1 - High impact issue, must be updated daily, must be resolved before resuming milestone work
- bug/P2 - Issue is affecting users, should be resolved before resuming milestone work
- techdebt - unpleasantness that does (or may in future) affect development
- chore - refinement / improvement of end user or developer functionality, or new developer functionality
- dogfood - important for the developer's own use of the project
- performance - excessive resource usage and latency; usually a bug or chore
- accuracy - incorrect information is being shown to the user; usually a bug
- component/build - an issue concerning compilation, testing, packaging, distribution
- component/docs - a documentation issue
- component/ui - predominantly a front-end issue; most/all of the work can be completed by a f/e developer
- k8s - pertains to integration with Kubernetes
- ecs - pertains to integration with Amazon ECS
- help-wanted - small, well-defined and self-contained
- needs-design - UI representation/flow requires a fair amount of thought
NB: suggestions for refining the above explanations based on edge cases / examples from the current issue list are welcome.
There are a few guidelines to follow when labelling issues:
- every issue should be labelled with exactly one of 'feature', 'bug', 'techdebt', 'chore' (aka "category labels")
- apply other labels as appropriate (component, estimates, bug priority); avoid attaching a large number of labels - that typically indicates that the issue should be split up
- Only create labels that apply to a non-trivial number of open issues, and when you create the label, do actually apply it to these issues.
- Avoid sub-labels, i.e. labels that apply only to (some of the) issues that already have some specific other label.
- Choose pastel colours; the "bold" colours are reserved for the category labels.