Cleanup labels

[daniel-jettka]

Current labels and number of open/closed issues:

[daniel-jettka]

Deletion candidates:

• Admin: drop-candidate (0/1)
• duplicate (0/1) -> when duplicate is encountered this can be cleaned right away
• Feature: shortcuts (2/0) -> no other "Feature: *" and two is not much
• MEI support (1/0) -> only one; and title can say this MEI support: annotation title and eutil:getLocalizedTitle #311
• Status: fixed (0/3) -> when fixed, issue can be closed
• Status: needs decision (1/2) -> assign and mention people
• Status: needs discussion (2/0) -> assign and mention people
• Status: needs evaluation (2/0) -> assign and mention people
• Status: wontfix (0/0) -> no issue and could be just closed
• Type: support request (0/1) -> only one Installation instructions for installing Edirom-Online as-a-service on Linux #106

[daniel-jettka]

Concept for labels:

• there can be a (rather small) number groups of labels, in this case Area, Status, Type, View
• there can be a (rather small) number of free labels which are not part of a group, in this case bugfix, high priority
• labels of one group have similar color tone (brightness), and same font color
• colors of labels can reflect meaning, importance, complexity but don't have to - in this case only red is used for a small number of labels to indicate their importance

[bwbohl]

I always think, GitHub makes it a bit complicated to structure labels because they are used both, for issues and pull requests. For example (at least from my point of view) a "bug report" should be a label for an issue, while "bugfix" should be a label for pull requests.

[bwbohl]

@daniel-jettka what do you mean with cleaning-up a "duplicate"?

[bwbohl]

I did the following cleanups:

• remove "View: *" labels -> added the view name as prefix in the issue title
• rename "bugfix" label to "Type: bugfix" and added a description
• remove "high priority" label and added the priority in the Edirom Development project

[bwbohl]

I think for now we can live withe the current labels. Future work will show how they are being used and whether some of them would better be managed with custom fields in the project or with prefixes in the issue or pull request title.