This is very much work in progress
I want to understand how to do useful labeling. I always have various projects in parallel, and they start to feel disorganized at times. It’s time to put stickers on them to truly see their purpose and urgency.
You can find no shortage on people showing their styleguide for labeling -or tagging- issues, for their specific way of working. I have read through various sources to get to my own special flavor, as I shall present here today. Since I have my own way of working, see this as my documentation on how to organize my own labels. So this post will change over time whenever my ideas change.
Use it as inspiration for your own.
Scoped labels
I very much like the scoped labels feature in GitLab, as it helps making sure your issues have a single status for any given type. This is a paid feature, that can easily be done manually. It’s mostly useful when working with people who like your labels, but care too little about doing it ‘right’.
Label types
You don’t need many labels to have an organized overview of the state of your project. Just having labels depicting the status, type and priority is enough to have a global overview on how things are going.
You can expand this by adding labels such as product, language, feature, department, etc. To prevent label sprawl, make use of other methods to keep them useful. Colors create an overview which is much faster and clear than any words you can place in your labels.
Color
Using colors can be useful for categorizing issues, but another much more interesting use is having them indicate urgency. For this you can have labels appeal to the viewer who can have differing requirements.
Something current No need to look here Something is great This needs your attention, now! Have a look when time permits Contextual information, perhaps the language, feature, or specialism More contextual information No longer needed
Label text
Keep it short
The viewer
Regardless of what you choose, it’s not about picking pretty colors, and feeling proud of having labels everywhere. These labels are for others to understand if something needs to be done, and if the someone to do it is them. There are various viewers, and I will show some examples below.
- The coder who wants to know the most important bug to fix, and to which he or she can contribute.
- The product owner who wants to know about any problems that need attention, but also how the project is going overall
- The specialist who wants to know if there’s a project
- etc. etc. etc.
Ask these people how they might look at labels, provide them examples and see if that works for them. Since you’re probably one or more of those too, ask yourself the same. Does red really look urgent to you, or is it just distracting and unreadable?
Scoping
Issues are usually seen within the scope of a project, yet few people have just one project at a time. Consistency truly helps, but might not always be achievable. Using the same labels for all issues in a project is obvious, using them in a (more or less) same team for different project will truly help acceptance. Using them at larger scale, such as a department, or if you’re a true change king, a (large) organisation, may become unfeasible. For those, focus on having consistency in colors and types, but not necessarily naming.
Time
Take your time organizing labels. It is a chore, yet will save you many hours in catch-up-meetings, and remembering what was done and when.
Label text
Really, keep it short.