Common bug severity levels

[jasonrhodes]

I'd like to use severity levels on our GitHub bug tickets. Having that information readily available on a bug ticket helps the triage process immensely, and is not really the same as "priority", a product-driven concept.

I'd like to propose these 4-5 severity levels and descriptions. I don't want to use release language, so I've tried to use language that represents urgency. Please suggest updates/improvements!

SEV 1: Urgent, potential blocker
SEV 2: Important, please fix as soon as possible, not a blocker
SEV 3: Must fix, but can wait if necessary
SEV 4: Unsure if this is a problem worth fixing
SEV 5: Close this ticket / wontfix / not worth fixing

Thoughts?

[matschaffer]

+1 to @Zacqary 's notion of not really needing a "5". Though I guess we could keep it since it allows us to have a severity level on all issues. Even those that we just close as wont-fix.

The important/must-fix distinction seems a little close. Maybe like this?

SEV 1: Urgent, potential blocker
SEV 2: Important, please fix as soon as possible, not a blocker
SEV 3: A problem worth fixing as part of the normal work roadmap
SEV 4: Unsure if this is a problem worth fixing
SEV 5: Close this ticket / wontfix / not worth fixing

If we're interested in expanding research, I often look to k8s as a source of well-thought-out issue handling ideas: https://github.com/kubernetes/kubernetes/labels?q=priority

They stick to words rather than numbers which does feel more human/better.

[jasonrhodes]

Thanks! I personally prefer the numbers in the label because it helps immediately compare 2 tickets and rank them without needing to reinterpret the names into a rank.

We can easily add the description to the label so that when you type "sev" into the label chooser, all is the sev labels will appear and their human readable descriptions will show as well, if that helps solve the same problem?

[afgomez]

I see two potential issues with having numbers:

• An issue I see with numbers is that they put things on a scale. We might have two tasks that are important but not blocking, where one of them is more important than the other. We might be tempted to place one in sev:1 and the other in sev:2 to reflect this.
• It adds a level of indirection. People need to know that sev:1 means blocking, whereas sev:blocking is self-explanatory for people both in and outside the team.

I see an advantage of having numbers, and it's automating the sorting of tasks somehow by their severity. maybe we can have our cake and eat it too using sev:1-blocking, sev:2-important, etc

[Zacqary]

If we end up tagging with words over numbers, using a sev:wontfix might be fine.

[matschaffer]

sev:5-wontfix perhaps :)