Ubuntu Open Week - Triaging Bugs With Launchpad - Bjorn Tillenius - Mon, Apr 23, 2007

see also Thursday Session. TZ UTC-4

(01:03:13 PM) BjornT: ok, let's get started with the next session then.
(01:03:23 PM) BjornT: I'm Bjorn Tillenius, the lead developer for the bug tracking part of Launchpad, and I'll be your host for this session about triaging bugs with Launchpad.
(01:03:37 PM) BjornT: For those of you that don't already know, Launchpad (https://launchpad.net) is a web application for managing software projects, i.e. it provides bug tracking, feature tracking, code hosting, and more.
(01:03:51 PM) BjornT: A lot more could be said about Launchpad, so you should stay for the next session, where mrevell will give you an excellent introduction to Launchpad.
(01:04:05 PM) BjornT: Now, let's talk about getting started with triaging bug.
(01:04:11 PM) BjornT: Triaging bugs is a great way of getting involved with a project. It doesn't require that you know how to code, and pretty much anyone can learn how do it.
(01:04:19 PM) enervation left the room (quit: Remote closed the connection).
(01:04:25 PM) BjornT: Doing this session actually made me realize that it can be quite hard to know how to get involved with triaging bugs, but don't let that put you off!
(01:04:39 PM) BjornT: If you just contact the right people, they will most of the time be happy that you want to help, since that can improve the experience for their bug reporters.
(01:04:54 PM) BjornT: As a bug reporter, you want that someone cares about your bug report, so having bug triagers that can reply promptly to new bug reports is a great asset for a project.
(01:05:07 PM) BjornT: By triaging bugs you'll also help the developers focus more on bug fixing, and less on talking.
(01:05:25 PM) BjornT: There are a few different ways you can triage bugs; some require more knowledge and authority than the others.
(01:05:34 PM) BjornT: I'd say the two most common meanings of triaging are:
(01:05:38 PM) BjornT:     - making sure that the bug report contains enough information
(01:05:42 PM) BjornT:     - prioritize the bug
(01:05:51 PM) BjornT: The latter can be quite difficult to do, and it requires that you are trusted by the project, so i'll be concentrating on the first point, which basically means to make the bug report good enough so that more experienced people can prioritize and fix the bug.
(01:06:18 PM) BjornT: So, what kind of information should the bug report contain?
(01:06:23 PM) BjornT: Basically it should contain enough information so that someone could reproduce the bug, and it should also clearly state what the actual bugs is.
(01:06:32 PM) BjornT: i.e., it should contain the answers to the following questions:
(01:06:35 PM) BjornT:     - what did you do?
(01:06:38 PM) BjornT:     - what happened?
(01:06:43 PM) BjornT:     - what did you expect to happen?
(01:07:03 PM) BjornT: But this is not the only information that is needed;  each project have their set of requirements and guidelines as to what exactly a bug report should contain.
(01:07:20 PM) BjornT: So before starting to triage bugs for a project, you should get in contact with the people that are dealing with bugs within the project.
(01:07:23 PM) BjornT: Your best bet is usually to look at who's the designated "Bug Contact"
(01:07:25 PM) BjornT: of the project, find them on IRC or drop them an e-mail.
(01:07:46 PM) BjornT: Since this is *Ubuntu* Open Week, let's take Ubuntu as an example. Note that most of the things I will talk about here apply to any project using Launchpad, not just Ubuntu.
(01:08:08 PM) BjornT: If you look at https://launchpad.net/ubuntu you can see that the 'Ubuntu Bugs' team is the bug contact. If you follow that link to https://launchpad.net/~ubuntu-bugs, you can see that you shouldn't join that team, though!
(01:08:30 PM) BjornT: The ubuntu-bugs team is used mostly to get all the bug notifications sent to a mailing list.
(01:08:44 PM) BjornT: On the same page you can see that the Ubuntu QA Team is listed as the owner, so if you'd follow that link you'd be pointed to the Ubuntu BugSquad, which is that team that deals with bugs in Ubuntu.
(01:09:07 PM) BjornT: https://wiki.ubuntu.com/BugSquad contains all information you need to join the team and start triaging Ubuntu bugs. Don't be shy, they will appreciate any help you can give them. :) They usually hang out in #ubuntu-bugs here on freenode.
(01:09:30 PM) BjornT: But don't go off reading all that information just yet, though, since it would take most of this session. Instead I will talk a bit about triaging bugs here.
(01:09:54 PM) BjornT: So, now that we know who we should talk to about triaging bugs, we can talk about picking which bugs to triage.
(01:10:00 PM) BjornT: If you look at https://bugs.launchpad.net/ubuntu you can see that there's a great deal of Unconfirmed bugs. It's those bugs that you want to turn to either Confirmed or Rejected.
(01:10:19 PM) BjornT: Confirmed basically means that the bug report contains enough information for someone to fix the bug, and Rejected means that it's not really a bug, for example, it could be a support request disguised as a bug report.
(01:10:52 PM) BjornT: When you triage bugs, you start to have a conversation with the bug reporter. This is important work, since it gives the bug reporter someone to talk to, and it shows him that someone does care about his bug report.
(01:11:21 PM) BjornT: Be sure to be polite to the reporter, though :), we don't want him to get a bad impression of the community.
(01:11:27 PM) BjornT: In order to avoid more than one people triage the same bug, it's a good idea to assign the bug you want to triage to yourself. This gives you a list of bugs you need to pay extra attention to at https://launchpad.net/people/+me/+assignedbugs.
(01:12:06 PM) BjornT: It also makes it easier for triager to find bugs you want to triage, since you can exclude bugs that are assigned to someone.
(01:12:23 PM) BjornT: let's stop for some questions here

< spr0k3t> QUESTION: if a bug is rejected by the person triaging,. does it get less priority or just left for the next person. triaging?

• If you mark a bug as Rejected, no one will look at the bug again, so only do so if you're sure that it's not a bug. When a bug is rejected, an e-mail notification will be sent, though, so people will see that the bug gets rejected.

QUESTION many people don't know the literal meaning of. triaging. could you please explain that first ?

• This question is actually quite hard to answer As someone of you already noted, "triage" is an unusual word. It doesn't have a useful meaning in the real world; I'm not sure why we say that you "triage" bugs. But in a bug context, it means to make sure that the bug contains enought information, and that it gets directed to the right people that will fix the bug. The thing is that mostly "triage" means to prioritize, while here it also means to make sure that the bug is a good bug report.

< micahcowan> QUESTION: The "bug contact" could just be anyone who. happened to subscribe to bug changes for that particular. bug, right? That is, it's not guaranteed that the Bug. Contact is particularly knowledgeable on that package?

• There are different kind of bug contacts. For Ubuntu, there's one global bug contact for the whole distribution, and also any number of bug contacts for each source package. Not anyone can become a distribution bug contact, but anyone can become a source package bug contact, which is a great way of getting e-mail notifications for bugs. For other projects in Launchpad, not anyone can become a bug contact.

(01:19:57 PM) BjornT: Ok, let's continue with how to find bugs to triage.
(01:20:04 PM) BjornT: To find bugs to triage, you can go back to https://bugs.launchpad.net/ubuntu and click on the "Advanced search" link, which will allow you to filter the bug listing in a great number of ways.
(01:20:26 PM) BjornT: In Ubuntu, bugs are considered untriaged if they are Unconfirmed, have an Undecided importance, and doesn't have an assignee.
(01:20:29 PM) BjornT: So you should make sure that no other statuses or importances are checked, as well as making sure that "Nobody" is specified as the assignee.
(01:20:48 PM) BjornT: After you've done this and clicked on "Search", you probably want to bookmark that page.
(01:21:05 PM) BjornT: When you have the list of bugs, it's a good idea to open each bug you want to triage into a new browser tab. That makes it easier to get back to the bug listing after you're done with the bug.
(01:21:36 PM) BjornT: Now, let's talk about how you actually triage a bug report that you've found.
(01:21:45 PM) BjornT: First, you should read through the bug report and make sure that you understand what the bug report is about. If it's unclear, ask the reporter to clarify.
(01:22:05 PM) BjornT: When you ask the reporter something, you should set the status to "Needs Info", so that the reporter (and you) knows that action is required from him.
(01:22:24 PM) BjornT: Sometimes the bug reporter doesn't respond, so if a bug in "Needs Info" hasn't gotten a reply for a while, it's usally a good idea to Reject the bug, since it can't be fixed without knowing more about the problem.
(01:22:56 PM) BjornT: Now, it might not be completely obvious how to change a bug's status, so I'll better tell you how to do it :).
(01:23:09 PM) BjornT: You change the status of the bug by clicking on the package name (e.g.  "amule (Ubuntu)"), which will expand the edit form, where you can edit things like status, assignee, and package name, and you can also leave a comment while editing.
(01:23:13 PM) BjornT: Anyone is allowed to edit the status of a bug, you don't need any special privileges.
(01:23:50 PM) BjornT: Now, let's get back to actually triaging the bug.
(01:23:59 PM) BjornT: There are a number of different things you can to do. A good first step is to try to reproduce the bug. If you don't know what steps are necessary, you should ask the bug reporter for more information.
(01:24:32 PM) BjornT: Now, after he's given all the information, it will be there in the comments. But sometimes there are a great number of comments in a bug, so the needed information can be hard to find there.
(01:24:56 PM) BjornT: So, to make it easier to find, Launchpad allows you to edit the bug description, by clicking on the "Edit description/tags" link in the action menu to the left.
(01:25:20 PM) BjornT: Moving the important information to the description will make it much easier for the next person looking at the bug to understand the bug.
(01:26:08 PM) BjornT: Let's take a few more questions.

< harrisony> QUESTION: When you mark a bug as a dupe do you then leave it. or close it or...

• If you mark a bug as a dupe, you don't have to do anything more about it. It will be considered triaged, and removed from the bug listings.

< deniz_ogut> QUESTION: There are bug reports which are "assigned" to. someone but stil remains "uncorfirmed" for many months.. Doesn't it mean that a bug will be triaged soon if it is. assigned to someone? Or still is there a need for new. contributers' help?

• This is a tricky situation. It basically requires someone to look at assigned bugs to make sure that some progress is made. Sometimes a bug can remain Unconfirmed, since the bug is a bit controversial, and requires a great deal of discussion.

< Loic> QUESTION: If we assign ourselves a bug we are triaging but can't. fix, hasn't the bug less chances to attract a developer, since. they will see that someone is already taking care of the bug?

• Oh, sorry, maybe I shouldn't have made that clear. After you've done triaging the bug, and moved the bug to Confirmed, you should unassign yourself, so that a developer can fix it.

(01:31:03 PM) BjornT: Ok, let's leave the rest of the question for later, and continue with assigning the bug to the right package.
(01:31:11 PM) BjornT: The next thing you should do is to try to decide whether the bug is filed under the correct source package. In Launchpad bugs are associated with source packages, not binary packages, and it can be hard for people to know on which package to file the bug on.
(01:31:52 PM) BjornT: If a bug doesn't have a package at all, or an incorrect one, it could lead to the bug not getting looked at by the people that should.
(01:32:05 PM) BjornT: Also, each package generally have few different guidelines as to what information a bug should contain, and it narrows down the scope of possible duplicate bugs.
(01:32:30 PM) BjornT: You can change/set the source package on the same form as editing the status, which is expanded by clicking on the package name on the bug page. You can find more information about finding the right source package at https://wiki.ubuntu.com/Bugs/FindRightPackage.
(01:33:02 PM) BjornT: After you decided that the source package is correct, you can start to search for similar bug reports, to see if the bug has already been reported before.
(01:33:27 PM) BjornT: You should start by going to the package's bug listing, which you can reach by expanding the edit form by clicking on the package name, and then click on the package name next to "Affecting:" to the right in the edit form.
(01:33:49 PM) BjornT: It's good to open this page in a new browser tab, so that you can easily return to the bug report.
(01:34:04 PM) BjornT: On the package bugs page, e.g.  https://bugs.launchpad.net/ubuntu/+source/amule, you can search for bugs that are reported on the amule package. The search will include all the bug reports that include the search words that you specify.
(01:34:36 PM) BjornT: If you found a bug report that is about the same bug as the report you are triaging, you can go back to the latter and indicate that it's a duplicate bug by clicking on "Mark as duplicate" and enter the id of the bug you've found.
(01:35:21 PM) BjornT: Now, let's talk about what other information the bug report should contain.
(01:35:29 PM) BjornT: If the bug isn't a duplicate, you can continue making sure that the bug report contains enough information so that a developer can debug what's wrong, ideally without having to request more information for the bug reporter.
(01:35:58 PM) BjornT: The most common thing is to ask the user what version of the related packages he's using. The reporter might not know how to get at this information, so be prepared to tell him how to do it.
(01:36:32 PM) BjornT: Apart from the general version information, each package, or subsystem has their own set of information they want a bug report to contain. For example, bugs involving a USB printer should contain a list of loaded usb modules, as well as some specific log output. The BugSquad can tell you more about this.
(01:37:00 PM) BjornT: You can also find a great deal of information at https://wiki.ubuntu.com/DebuggingProcedures.
(01:37:23 PM) BjornT: Now, since each part of a project is different, it can makes sense to focus on a specific part. This is especially true for large projects like Ubuntu. For example, in Ubuntu you could choose to focus on printing bugs, desktop bugs, firefox bugs, etc.
(01:37:39 PM) BjornT: Focusing on a smaller set of bugs gives you an opportunity to learn more about it, so that you, after a while, can do more advanced triaging, and maybe even fix bugs yourself.
(01:38:22 PM) BjornT: There are usually sub-teams that you can join, for example desktop-bugs.
(01:38:53 PM) BjornT: Now, I have a few more things to talk about, but let's deal with some questions again.

< techKyLa> QUESTION : DO i have to send the bug report to the particular. project or can it be sent to the genera bug repo?

• This is included in the part that is left, but in short, yes, sometimes you should. Often a bug is really not in the package itself, and not Ubuntu specific, but it's in the software project that is package. In this case you can link the general bug report to the upstream one. That way the Ubuntu bug is usually pending a fix from upstream, so the developers don't have to care about it until it has been fixed by someone. This is something you should wait with doing until you are more comfortable doing triage, and knows more about the packaging, and the packaged software.

< spr0k3t> QUESTION: How do you know if a bug has been triaged by. another but unconfirmed? Is there a standing count of. unconfirmed for each bug?

• No, there's no such count. But if you click on "View Activity Log", you can see all the changes to the status of the bug, so you can count for yourself.

<Nergar> QUESTION: is it safe to allow anyone to edit the bug status?

• I'd say yes Of course, there are opportunity for someone to abuse the system, and make unauthorized changes to the bug status, but it that happens, we have ways of reverting it. Everything is logged, so we can undo it. It's better to make it easy for people to get started, rather than trying to control people too much. That said, there might be some restriction in the future, where anyone can change the status to some values, while you have to have certain permissions to change it to some other.

< rohan> QUESTION: what would be the reasonable time frame before. rejecting a "Needs info" bug that has got no response ?

• This is very project specific. I'd say a few weeks, but ask the BugSquad instead.

QUESTION: If you're a bug triager, is it regarded good practice. to set status in a bug you've reported yourself?

• It's usually good to have someone else look at what you do, it's so easy to make a mistake. If your bug report has all the required information, it'll be quick for another triager to set it to Confirmed.

< jussi01> question: if you are working on any given bug, is. there a way to say to others that your working on it? ie. so. that you dont have a situation where 2 or 3 people are doing. the same work?

• Yes, you do this by assigning the bug to yourself.

< deniz_ogut> QUESTION: Would you please talk some more on "Anyone is. allowed to edit the status of a bug, you don't need any. special privileges." It seems to be a serious. responsibility and.... I mean I sitill don't have courage. to edit them. What if I mark them with an improper status?

• I've already covered most of this question, but not the last part. If you're unsure about which status to change the bug to, you can always ask someone. If you do ask the first couple of times, you will soon be comfortable enough to make a decision by yourself. Don't be afraid to ask questions when triaging bugs.

< torkiano> QUESTION: if a bug affect a driver what package is afected? kernel(linux-source-2.6.20) or the source of driver (rt2x00)

• This is highly Ubuntu specific, so it's better to ask this question in #ubuntu-bugs, they will help you.

< ditsch> QUESTION: Is it worthy to tag the bugs and if so, is there a. standard set of tags somewhere to include in the bug reports?

• In general it is worth tagging bugs, although I think Launchpad needs to be improved before tags get really useful for Ubuntu. We're working on it, though. But there are examples where it is good to ask tags. For example, new crash reports from Apport should be tagged with needs-retrace, so that the automatic re-tracer can pick them up.

<micahcowan> QUESTION: Except in cases of backports/SRUs, won't the package version typically be obvious from what version of Ubuntu the reporter is running (and thus "what Ubuntu version" being an equivalent question)

• No, it won't always be obvious. Sometimes the user hasn't updated his system for a while, and he might run an LTS like dapper. Also, if you leave the bug report for a month, it's not nice having to look up which version was the current one a month ago.

(02:00:19 PM) BjornT: ok, that's all i had time for. thanks for listening.
(02:00:31 PM) BjornT: Also, to remind you, if you want to start triaging Ubuntu bugs (you really should give it a try), read https://wiki.ubuntu.com/BugSquad and https://wiki.ubuntu.com/Bugs/HowToTriage.