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
- How bugs get reported about Ubuntu
One way that bugs can be reported to Launchpad 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 associate with a package, well described and contains enough information for a developer to start working on it. This process is detailed at https://wiki.ubuntu.com/Bugs/Improving .
- Identifying package and version
As mentioned previously sometimes bugs are submitted without a package to Malone, the bug tracking portion of Malone. Untriaged bugs without a package can be found at http://tinyurl.com/22gw9k . One sometimes easy thing to 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 . There can also be bug reports without a specific version of Ubuntu or a package. As there are multiple versions of Ubuntu currently out, Dapper, Edgy, Feisty and Gutsy, finding out the version improves the bug report. Also determining the version of the package affected improves the report. Two ways to find out the package version on an installed system are 'dpkg -l $pkgname' a terminal and by using Synaptic to search for the package name and looking in the installed version column.
- Steps to reproduce it
- 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 as detailed as possible, it is better to have too much information rather than not enough. I've triaged a lot of bugs and only one time have a seen a reporter actually submit a screencap of there bug. But boy that was the easiest bug for me to recreate.
- Descriptive summary
- This is a pet peeve of mine because 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. Something like "Can not hibernate or suspend with HP laptop model dv6245" and "distribution upgrade from Feisty to Gutsy fails with medibuntu in sources.list". The summary can be modified by clicking on the pencil icon next to the Bug description. Following that link will show you a new 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.
- Status and gathering more info/ getting help
Assignment & Subscription
- 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.