New label taxonomy

[Tobychev]

Hello everyone,
I've gone trough all the existing labels and tried to think up a more structured collection of labels.

The core observation is that the current set of labels serve many different, and sometimes overlapping purposes. So I identified several different classification purposes, and then created the labels that belong to each purpose, resulting in six groups of labels and 46 labels in total¹, shown below.

I also propose that we think about how to best colour code the various labels, some labels have gotten very attention grabbing colours without there being any obvious need to highlight that label (for example bug and dl1 are equally prominent right now).

Subsystem labels

• build-system
• calibration
• cleaning
• coordinates
• config-system
• core
• data-format
• documentation
• image
• io
• installation
• instrument
• plugins
• reconstruction
• tests
• tools
• visualisation

Problem labels

• wrong-result
• crash
• confusing-behaviour
• inconsistent-behaviour
• bad-performance
• regression
• missing-tests
• missing-documentation

Enhancement labels

• performance-enhancment
• capability-enhancment
• readability-enhancment
• stability-enhancment

Task status labels

• need-info
• need-triage
• need-decision
• solved
• stalled
• outdated

Project management labels

• good-first-issue
• help-needed
• high-priority
• design-problem
• question

Testing need labels

• breaking-change
• algorithm-change
• refactoring-change
• internal-api-change
• documentation-only-change
• no-changelog-needed

Footnotes

1. Completing the set of subsystem labels, and splitting the too generic labels into usefully specific labels ate up most of the gains from rejecting many of the existing labels. ↩

[Tobychev]

Here is the current set of labels and how many are currently in use in open issues or pull requests:

Label	Issues	PRs
algorithm	2	0
API change	3	2
Breaking change	2	1
bug	18	0
build	0	1
build failure	0	0
calibration	4	1
cleaning	0	0
chain	0	0
coordinates	1	0
config system	2	1
core	0	1
data model change	5	1
design problem	8	0
discussion	6	0
dl1	2	0
documentation	12	4
duplicate	0	0
Dual Mirror Telescopes	2	0
enhancement	45	2
fix	0	0
FLASH Cam	1	0
good first issue	1	0
hdf5 data format	1	0
help wanted	5	0
invalid	0	0
installation	0	0
input/output	0	1
IO	2	0
maintenance	4	1
missing tests	0	0
muons	1	0
new functionality	5	3
no-changelog-needed	0	5
optimization	0	2
performance	2	0
plugins	1	0
physics	1	0
proposal	3	0
PROD6	0	0
question	3	0
reconstruction	1	2
refactoring	7	3
subarrays	3	0
summary issue	0	0
use case	1	0
visualisation	0	0
wontfix	0	0
workinprogress	0	0

[maxnoe]

Hi,

I'd reduce the number of labels a bit more, e.g. by deduplicating things like "documentation" and "missing-documentation" or "bad-performance" and "performance-enhancement", since these should be clear by context.

If applied to an issue, it's clear that documentation refers to bad or missing documentation and applied to a PR it is clear that it improves or adds to the docs. Same for "performance", in an issue it should be clear that it is a performance problem and on a PR its a performance "improvement". Similar for "tests" and some of the others.

I also think that we might not need that fine-grained labeling of what is wrong like "wrong result" or "crash": "bug" is probably enough here.
I think we should aim for the least amount of labels possible, otherwise we will not use all of them appropriately.

Concerning the colors: we should probably assign a hue to the different categories and use different shades of the same hue inside the categories.