-
Notifications
You must be signed in to change notification settings - Fork 713
Issue Labelling
Neil edited this page Nov 22, 2017
·
10 revisions
Category
- feature - new end user functionality
- chore - Fixes / refinement / improvement of end user or developer functionality, or new developer functionality
- bug - broken end use or developer functionality; not working as the developers intended it
- techdebt - unpleasantness that does (or may in future) affect development
Component
- 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
Other
- 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
- 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, in particular component; 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.