TriageAtOpenWeek

Summary

  • What is triaging and how it helps:
    • In a hospital "triage" is the process of separating the very badly wounded from those who are lightly wounded. In the Free Software/Ubuntu World, it's the process of separating and identifying bugs that are most severe and most useful for the developers. Bugs become triaged by gathering more information about the bug, setting their status, setting their importance and by identifying duplicates.
  • Joining the team and communicating with them

    • There are multiple teams in the Ubuntu community that triage bugs. The most general of these is the Ubuntu Bug Squad. You can learn about joining the Bug Squad at https://wiki.ubuntu.com/BugSquad/GettingInvolved . In the event that you ever need help triaging a bug or want to discuss a bug or best practices, members of the Bug Squad are usually accessible in #ubuntu-bugs on Freenode or via the ubuntu-bugsquad mailing list.

  • How bugs get reported about Ubuntu

    • One way that bugs are reported about Ubuntu is by someone going to the Launchpad website and finding https://launchpad.net/ubuntu/+filebug . They will be asked for a summary and then for the package and further information regarding the bug. This process is very free form though and can lead to incomplete reports or ones without a package. Another way for a bug to be reported to Launchpad is by someone using an application's Help -> Report a Problem menu item. This process will collect information about the version of Ubuntu the reporter is using, the application and also it's version. A report filed that way may be much more complete and they can be found at https://launchpad.net/ubuntu/+bugs?field.tag=apport-bug .

  • Improving a bug report

    • An important part of triaging bugs is ensuring that the bug is valid, is associated with a package, is well described and contains enough information for a developer to know it is a valid bug and start working on it. This process is detailed at https://wiki.ubuntu.com/Bugs/Improving . Parts of the improvement process include:

    • Identifying the package and version

      • As mentioned previously sometimes bugs are submitted without a package to Malone, the bug tracking system of Launchpad. Untriaged bugs without a package can be found at http://tinyurl.com/22gw9k . In this list of bugs you'll notice that the package is just "--". Actually looking at one of the bug reports we will see that it affects "Ubuntu". One usually easy thing you can do to help these bugs along is assigning them to a package. There is some documentation about how to determine the package at https://wiki.ubuntu.com/Bugs/FindRightPackage . The package that a bug is assigned to can be modified by clicking on the bug's current status, importance or the download arrow in the far right side of the package row. This will reveal a new area of the bug report where you can see the package box is empty. In that box you can type a package name directly or click on the "Choose ..." hyperlink which will reveal a search for a package dialog.

      • There can also be bug reports without a specific version of Ubuntu or the package the bug is about. As there are multiple versions of Ubuntu currently out, Dapper, Edgy, Feisty and Gutsy, finding out the version improves the bug report. One of many ways to do this is my looking at the file '/etc/lsb-release'. Also determining the version of the package affected improves the report. Two ways to find out the package version on an installed system are using 'dpkg -l $pkgname' in a terminal and by using Synaptic to search for the package name and looking in the installed version column.
    • Detailing steps to reproduce the bug
      • Another critical part of improving a bug report is ensuring that there are detailed steps to reproduce the bug. This helps other triagers and developers recreate the bug and study it more. The steps should be broken down individually and as detailed as possible, it is better to have too much information rather than not enough. For example, 1) click on File then go to 2) New Profile etc . . . I've triaged a lot of bugs and one time I saw a reporter actually submit a screencap of there bug. That bug was quite easy for me to recreate.
    • Creating a descriptive summary
      • This is a pet peeve of mine as nondescript bug summaries really bother me. The summary is what you see above the affects row in large font when viewing a bug report. It is also what reporters see in the "Is this your bug" list when submitting a new bug. It is also what shows up in bug listings. It basically shows up everywhere! Yet we have summaries like "no ibernate, no suspend" and "Distro update tool". I realize that the number of characters that will fit well is limited but we should try to make the summary as descriptive as possible. Summaries like "Can not hibernate or suspend with HP laptop model dv6245" and "distribution upgrade from Feisty to Gutsy fails with medibuntu in sources.list" are much more descriptive and help everyone.
      • To actually modify the summary you should click on the pencil icon next to the Bug description. That will show you a new web page where you can edit the summary, description and add tags to the bug report. After clicking change you will then be taken back to the bug report.
  • Bug Statuses

    • The meaning of bug statuses for the Ubuntu project are defined at https://wiki.ubuntu.com/Bugs/Status . When viewing a bug report in Launchpad the Status is shown for each package affected in the Status column. There are currently 9 stasuses available in Launchpad and they include New, Incomplete, Invalid, Confirmed, Triaged, In Progress, Won't Fix, Fix Committed, and Fix Released. We will just cover their meaning briefly.

    • When a bug is first reported the status of the bug is New meaning that the bug report has not been acted upon. These are good candidates for triaging.
    • A bug report that has a state of Incomplete means that the bug report is missing information. Missing information can include the version of Ubuntu or the version of the package, steps to reproduce the bug report.
    • A Confirmed bug report is one that someone, other than the original reporter, has been able to reproduce or one that has the minimum debugging information for that package available.
    • A Triaged bug is one that should have enough information for a developer to start working on a fix for the bug. This status can only be set my a member of the ubuntu-bugcontrol, formerly the ubuntu-qa, team.
    • An In Progress bug is one that a developer is working on fixing the bug.
    • A Fix Committed bug means that a change to the software, that fixes the bug, has been commited to the development branch of that software. This could also include an updated package in the proposed repository or available via PPA. However, a fix is not readily available for everyone.
    • A Fix Released bug means that an updated version of the software is publically available most likely through an official Ubuntu repository.
    • A Won't Fix bug report is one that the developers of the software have determined will not be fixed. This most often happens when the bug is targeted at a specific release of Ubuntu and will not be fixed there.
    • An Invalid bug report is one that was determined not to be a bug or one that did not have enough information whether or not it was a bug.
    • The statuses most commonly set by members of the Bug Squad are Incomplete, Confirmed and Invalid. The status of the bug report can be modified by clicking on the bug's current status at the top of the bug report. This will reveal places for you to assign the bug to a package, mentioned previously, and set the status of the bug report. You can also add a comment to the bug report which will show up in the bug's web page and be e-mailed to subscribers of the bug.
  • Gathering Debugging Information

    • We have made some debugging information for specific packages and problems available at https://wiki.ubuntu.com/DebuggingProcedures . The debugging pages contain questions that you will need to ask the reporter, if they didn't answer them in the initial report, to make the bug report more complete. One helpful thing to do when asking questions are making each question separate line so they are not missed.

  • Assignment & Subscription

    • Since we want to avoid to have more than one triager working on the same bug, it's a good idea to assign the bug to yourself, this is done by selecting the "Me" option in the "Assigned to" area, once you have the bug assigned, you'll be receiving an e-mail of any activity in the report, example: another bug was marked as a duplicate, the reporter responded to your questions, another person can confirm the bug, etc. If you want to see the list of bugs that are assigned to you, Launchpad has a nice page located at https://launchpad.net/people/+me/+assignedbugs . After your job as a triager is done which basically means that the bug has enough info and you moved it to the confirmed status, you should unassign yourself by selecting "Nobody" in the "Assigned to" area. If you want to continue receiving emails about the bug activity you might want to subscribe to the report by activating the "E-mail me about changes to this bug report" option at the bug page and then just clicking on Save changes.

  • Importance - if there is enough time

    • https://wiki.ubuntu.com/Bugs/Importance

    • set by ubuntu-bugcontrol members or developers
    • If you need importance set or think bug is important escalate on the #ubuntu-bugs channel or via the mailing list.
  • Wrap Up
  • Uncertain but maybe mention
    • Identifying the bug's package and creating a descriptive summary for the bug report requires no further work either. You don't need to wait for the reporter to respond and you are still helping the bug move along.
  • Idea needing a home - We might create "What is missing checklists" for triagers

QATeam/TriageAtOpenWeek (last edited 2008-08-06 16:25:53 by localhost)