Use your labels

Four blank paper gift tags — white, brown, black, and white — hanging from the top of the frame.

Most modern issue trackers offer a label mechanism (sometimes called “tags” or a similar name) that allow you or your users to set metadata on issues and pull/merge requests. It’s fun to set them up and anticipate all of the cool things you’ll do. But it turns out that labels you don’t use are worse than useless. As I wrote a few years ago, “adding more labels adds cognitive overhead to creating and managing issues, so you don’t want to add complexity when you don’t have to.”

A label that you don’t use just complicates the experience and doesn’t give you useful information. A label that you’re not consistent in using will lead to unreliable analysis data. Use your labels.

Jeff Fortin Tam highlighted one benefit to using labels: after two years of regular use in GNOME, it was easy to see nearly a thousand performance improvements because of the “Performance” label. (As of this writing, the count is over 1,200.)

How to ensure you use your labels

The problem with labels is that they’re either present or they’re not. If your process requires affirmatively adding labels, then you can’t treat the absence of a label as significant. The label might be absent because it doesn’t apply, or it might be absent because nobody remembered to apply it. By the same token, you don’t want to apply all the labels up front and then remove the ones that don’t apply. That’s a lot of extra effort.

There are two parts of having consistent label usage. The first is having a simple and well-documented label setup. Only have the labels you need. A label that only applies to a small number of issues is probably not necessary. Clearly document what each label is for and under what conditions it should be applied.

The other part of consistent label usage is to automatically apply a “needs triage” label. Many ticket systems support doing this in a template or with an automated action. When someone triages an incoming issue, they can apply the appropriate labels and then remove the “needs triage” label. Any issue that still includes a “needs triage” label should be excluded from any analysis, since you can reasonably infer that it hasn’t been appropriately labeled.

You’ll still miss a few here and there, but that will help you use your labels, and that makes the labels valuable.

This post’s featured photo by Angèle Kamp on Unsplash.

Ben is the Open Source Community Lead at Kusari. He formerly led open source messaging at Docker and was the Fedora Program Manager for five years. Ben is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.