How we triage Launchpad bugs

M and Ms sorted by colour

If you’ve ever wondered why a particular bug report about the Launchpad project is marked as Low, High or Critical, you should read our bug triage guidelines.

Okay, so, if you’re not directly involved with triaging Launchpad bugs then that may not be the world’s most compelling invitation.

So, here’s the short version: we use only the Critical, High and Low importances. We give each a particular meaning:

  • Critical: Bugs that should be fixed before other bugs. Ideally, we’d have nothing here.
  • High: Bugs we think we can fix in the next six months.
  • Low: Everything else.

That last one can make it appear that we don’t care about your bug but that’s not the case. The reason we use Low is to avoid setting any unrealistic expectations about when someone in the Canonical Launchpad team will get to that bug. That’s not to say we’d complain if someone else fixed that bug. Also, we’re open to persuasion: tell us why we should increase the priority of a bug you care about.

There’s more in our bug triage guidelines, including what we consider to be a Critical bug.

Photo by Mr. T in DC. Licence: CC BY ND 2.0

3 Responses to “How we triage Launchpad bugs”

  1. Martin Pool Says:

    itym, “ideally there would be custard dripping off jono’s face…” 🙂

  2. Matthew Revell Says:

    Haha 🙂

  3. Tony Says:

    I want to thank you for this post, because it’s been something that has annoyed the crap out of me for some time now.

    There is a HUGE problem with the guidelines: they are using one label to describe “importance”, “difficulty”, and “estimated time to completion”.

    It’s not only possible, but completely plausible, that there are bugs & features which are extraordinarily important to Launchpad users that get marked “Low”, simply because they take more time to complete. And conversely, lots of “easy” which users may care very little about get marked as “High” because they’re completed more quickly. It goes on: a task may be important to users and simple but tedious to complete—and so, it’s marked “Low”.

    …Does that seem right?

    What is more, the guidelines are not even applied consistently. There are tons of bugs that fall into what I call the “low-hanging fruit” category—bugs that are quick, easy fixes. According to the guidelines, these should be marked “High”—but instead they are marked as Low because they are “not important”. And I suspect that sometimes, what is passed off as “not important” really means “I don’t feel like working on it, so it gets marked “Low”. As a result, it gets significantly less attention from other developers—regardless of whether it would make a world of difference to users, is a quick-and-easy fix, or both.

    I’m aware that bug heat is supposed to address some of these problems, and I have made an effort to make use of this feature wherever possible. Yes, that even means looking for bugs I didn’t create, but still care about. Sadly, even a bugs with lots of “heat” may get little-to-no attention from devs if it also happens to be marked with “Low” importance.

    The bottom line is that this drives users *absolutely crazy*. It has created a huge disconnect between devs and users, and because of things like those Bug Triage Guidelines user frustrations continue to build each time the Triage Guidelines are applied. I don’t have any statistics to back this up, but I have personally encountered lots of people who have abandoned Launchpad over this. That includes myself; it was *not* an easy decision, and I am keeping an eye on Launchpad in case things get better.

    I really hope that they do. Best wishes.

Leave a Reply