Category Archives: triage

Last rites

When I gave my presentation on Ubuntu Bug Triage Basics at Penguicon (or whenever anybody asks what triage is), I likened bug triage to the TV show M*A*S*H in which the wounded come in, go through triage, and then are operated on according to their triaged status. While the analogy between software bug triage and human triage isn’t perfect, it’s fairly close.

Lately, I’ve been feeling a lot like Father Mulcahy. As the Army minister of the 4077th, he had the unenviable task of performing last rites on those who could not be saved. In much the same fashion, I’ve been invalidating bug reports that have sat around for several months in need of more information. If we don’t have enough information, we can’t operate. If we are unable to operate for too long, the bug report dies. It may not seem like the most useful triage function, but I like to do it for two reasons:

  1. It’s quick and (usually) simple. I can crunch out a lot of these is a small amount of time.
  2. It’s a good way to decrease the number of open bugs, of which there are way too many for our team of dedicated (mostly volunteer) developers to address them all.

In addition to those obvious reasons, though, there’s some other good that comes out of these “last rites”. Sometimes (in fact, twice in the past two days) the bug filer will get my invalidation notice, and suddenly wake up, see the questions that have been needing answers, and answer them! Kind of like that one episode of M*A*S*H… “This one’s not dead!”

And this, to answer a question from the Penguicon presentation, is another reason we don’t just script the process of invalidating old incomplete bugs.

Ubuntu Bug Triage Basics

Finished my Google doc that goes along with my presentation this evening. Here is the link to it, and here is the inline version: (edit: wordpress.com didn’t like the inline)

New canned response?

Despite my previous stated distaste for canned responses, they are very useful (and I admitted that last time). So I’m considering adding one to the wiki. In the past few days I’ve seen a number of bugs that were set to “Incomplete” for no comprehensible reason. No questions asked, no data requested. I even saw a bug marked incomplete from the start, apparently by the person filing the bug. The problem is, nobody who wants to fix bugs is looking at incomplete bugs. They’re looking at “New” and “Confirmed”. Setting it as “Incomplete” means we are waiting on more info before we can do anything useful, and so the people who do useful* things don’t often look at incomplete bugs. I’ve seen the problem so much, that I’ve been copying and pasting one response over and over again:

Not seeing why this bug was marked “incomplete”. You should only set “incomplete” if:
  -you have to ask the reporter questions
  -you ask the submitter to provide any necessary information in a comment

I am marking it “new” again in the hopes somebody will pay attention to it.

Opinions are welcome. Particularly by my fellow triagers.

P.S. The Michigan LoCo is kicking butt in the 5-a-day stats, with at least 3 of us in the top 15. Way to go, guys!

*this isn’t to say triage isn’t useful… it’s just not as useful as troubleshooting/patching bugs.