Triage

Revision 4 as of 2006-10-10 18:18:24

Clear message

In a hospital, triage happens the instant a patient arrives through the emergency room doors. His vital signs are checked, his status assessed, and he gets sorted in amongst all the other patients waiting for treatment.

Bug triage is a lot like that. Without any risk of death.

Ubuntu receives an incredibly large number of bug reports every day through our BugTrackingSystem. Each one of these needs to be read, accessed, and sorted before being fixed. This is where we could use your assistance with HelpingWithBugs.

New bugs

Every bug report is a conversation with the reporter. The first contact any reporter usually has with Ubuntu is through a bug triager, who tries to put together a complete bug report. It's fairly important that we give a good impression, so please be polite and try to use your best English.

In order to help triage bugs, you have to be able to find them. Fortunately, this is easy. You can find out about new reports in one of two ways:

The first method is far more preferable, as you won't get a mailbox stuffed full of mail each time you read it. I tried the second option for a while and couldn't keep up at all.

When you enter #ubuntu-bugs, you'll soon see the following types of messages fly by: 

New bug: #1 in Ubuntu "Microsoft has a majority market share" [Undecided,Unconfirmed] http://launchpad.net/bugs/1

To start, just pick one of the recent ones and open the link in your favourite browser. If no one else has commented yet, then this bug could be yours!

Duplicates

Many of the reports filed against Ubuntu are actually duplicates of known reports. This usually happens after a high profile bug has been introduced into Ubuntu, causing a lot of users to report it. Other times, users will file a report that duplicates an older bug, but has different symptoms.

Bugs are duplicates when they have the same root cause. Determining this is a skill that you'll pick up as you become more familiar with a particular program or package. Bugs are not necessarily duplicates if they have the same effects. If in doubt, ask for another opinion.

When you first look at a new bug, try to find an existing bug in the system that describes this one. Here's how:

  • On the right-hand side of the page, click the "Show all open bugs" link.
  • Look for bugs with similar descriptions or related topics.
  • If they describe the same root cause, decide which report should be the primary one. This should be the one that's clearest.
  • For the other report, click the "Mark as Duplicate" link on the left-hand side of the page.

Complete reports

We want to make sure that every triaged bug is complete before it gets examined by someone who will fix it. When a bug is complete, it's much easier to isolate the cause of the problem and write a fix. Which means more bugs get fixed faster.

A complete bug report must contain the following things:

  • The steps the user performed to produce the problem.
  • The expected result of these actions.
  • The actual result of these actions.
  • The version of Ubuntu the user is running.

As a triager, you'll learn to ask for additional information when it's relevant. For instance:

  • The version numbers of the affected programs.
  • Any crash dumps produced by these programs.
  • [:Backtrace]s and other debugging output.
  • Any log files that are related to the problem.

Our DebuggingProcedures can tell you what extra information should be included for particular classes of bugs.

Since most reports probably won't be complete, you'll have to start a conversation. Ask the reporter for more information like so:

  • Click on the task name, which is usually the package name.
  • Change the "Status" field to "Needs Info".
  • Select "Me" for the "Assigned to" field.
  • Check "E-mail me about changes to this bug report".
  • Ask for more information in the "Comment on this change" field.
  • Click "Save changes".

You assign this report to yourself so you know which conversations you're having. And you subscribe to this bug so you will be e-mailed when the reporter responds.

Confirming

When you have a complete report, and there is enough information to debug the program, you can confirm the report. How do you know there is enough information? Here are some example criteria, any of which is sufficient:

  • Is there a patch that claims to fix the bug?

  • Are there sufficient log files and crash dumps, as outlined in DebuggingProcedures?

  • Can you reproduce the bug yourself?
  • Does another distribution have a complete and confirmed bug?
  • Does the upstream author have a complete and confirmed bug?

If any of these conditions are satisfied, you can Confirm the report. To do this:

  • Change the "Status" field to "Confirmed".
  • Assign the appropriate "Importance" value, according to ["Bugs/Importance"].
  • Select "Nobody" for the "Assigned to" field.
  • Click "Save changes".

Forwarding upstream

Much of the software in Ubuntu is not actually written by us. We package many pieces of free and open source software, collect them in a distribution, and integrate them. As such, many bugs are actually in programs we've never written.

In order to be good citizens, we want to forward good bug reports to the original (or upstream) authors. This helps the author track down bugs in their software. And it helps Ubuntu when they fix the bug.

Forwarding a bug is a bit of work, but it's well worth it. Here's what you do:

  • Find the upstream author.
  • If they have a bug tracking system,
    • Sign up for it, if necessary.
    • Search for this bug report in the upstream system.
    • If it doesn't exist, report a new bug in their system.
    • Link their bug report to ours.
  • If they have a mailing list or e-mail address,
    • Report the bug by sending an e-mail to the appropriate address.

When you report a new bug, please include the following information:

Linking a bug report is much easier:

  • Click the "+ Upstream..." or "+ Distribution..." link, as appropriate.
  • Choose the correct "Product" or "Distribution".
  • Check the "Link to a bug in another bug tracker:" box.
  • Select the proper "Remote Bug Tracker".
  • Enter the bug identification number in the "Remote Bug" field.
  • Click "Continue".

If the remote bug tracker is not [https://launchpad.net/malone/bugtrackers already registered] with Malone, you should [https://launchpad.net/malone/bugtrackers/+newbugtracker add it].

Rejecting

Sometimes, you will have to reject a bug report. This may be because the problem is not reproducible, the program was designed to behave a certain way, or the report is actually a feature request.

The best thing to do here is to politely decline the report while thanking the user for submitting it. There are some useful ["Bugs/Responses"] that you can use in these cases.

Go back to [:HelpingWithBugs].BRBR CategoryBugSquad