Re-organize issue labels

[dokterbob]

Currently there are 13 labels with only few of them used. This is too many; the meaning of the labels is sometimes unclear and/or overlappen (i.e. preventing boring tasks is always an enhancement).

I'd like to propose reducing this to a maximum of 5 clearly defined labels, the meaning of which should be largely evident but should be documented on the wiki nonetheless.

This is by no means a definite proposal but I think the following classification should suffice - actually I think we should narrow it down even more though having usability and documentation issues categorized is good for the division of labour.

• Urgent: an issue that is blocking further development or severely breaks the production environment. These should be fixed before any of the other issues.
• Bug: broken functionality. Clear description of: attempted action, expected result and actual result.
• Wontfix: a feature which will not be implemented by the developers (but might be implemented by contributors nonetheless).
• Feature: new functionality or enhancement to existing functionality.
• Usability: feature related to usability.
• Documentation: issues regarding documentation of the development workflow or the actual product.
• Low-priority: feature which might be implemented in the future but has less priority than other items.

In any case I would like to propose dumping the following labels:

• Invalid, duplicate: simply close the ticket.
• Question: discussions of this type should take place through other channels such as e-mail or IRC.
• Prevent boring tasks: that's what every single letter of code should be about - so in it's current phrasing this is confusing/redundant information.
• Enhancement, Refactoring, Reduce mistakes: these seem like different ways to say 'feature' and it is very likely that different people will categorize issues differently, making the filtering ineffective.
• Small issue: we could retain this as 'easy picks' or 'easy wins'; stuff that is easy to do but would benefit a lot though I think at this early stage of development I think we should just burn as many issues as we can, regardless of size. In it's current phrasing it is unclear whether 'small issue' is simply a problem which is 'not so bad' or whether it is something which is 'easy to fix'. In the former case I think low-priority might be a better phrasing.

The goal of these labels should be to improve the workflow by providing oversight. As human brains have difficulty dealing with longer lists overcategorization provides a real risk.

[fsmanuel]

sounds good to me

[wvengen]

Thanks, @dokterbob, I agree. I introduced 'small issue' (rename it to 'easy to fix' or 'bitesize'), so that new developers know where to get started. Keep that one? Documenting this is definitely a good idea - wiki or a file in doc.

[dokterbob]

Okay. Want me to go ahead and trash some of the labels?

[wvengen]

Please! If you don't have access, let me know.

[dokterbob]

There is still a 'duplicate' label which is nonesense. Simply close a ticket with a reference (#) and a short notice that it's a dup. GH will automagically create a reference back from the ticket you're referencing to.

[fsmanuel]

removed dublicate