my experience with bug triage

I have been always wanting to contribute to Ubuntu since the day I joined Ubuntu India Team. But, other things happening around me always kept me from converting this wish into action. It was this new year that I finally took a resolution to start some solid contribution to the Ubuntu project. The most viable options was to Ubuntu Bugs at Launchpad, which in better terms is the bug tracking system for Ubuntu.

The formal way to help with bugs (not formal as it literally means) is to join the bug squad, the team of ubunteros whose sole motive is to check bugs filed by the users, help the users provide as much information about their problem as possible, assign bugs to related packages, find earlier reports which is very similar or sometimes the same (duplicate bugs), assign status and importance for bugs and finally make it all ready for developers to work on them. This process also filters out reported bugs which are not bugs but user end mistakes, which are rather feature requests (wishlist) or merely misunderstood normal behaviors. In addition, we can also file patches for the bugs if we know how to fix them, which actually reduces a lot of developer time (which is precious).

So, where did I get started? Actually two places, one is Launchpad Bugs for Ubuntu and second is the bug squad team channel #ubuntu-bugs at irc.freenode.net. When I joined the team, the irc channel was both a place to discuss about bugs as well as where the bug announce bot was running, announcing the channel whenever a new bug was filed. Later, the bug announce was moved to #ubuuntu-bugs-announce channel, while #ubuntu-bugs became a complete discussion channel for the bug squad. Then I started reading the docs in the wiki, especially the following,

  1. How to Triage
  2. Debugging Procedures
  3. Standard Responses
  4. Bug Importance
  5. Bug Status

Apart from reading docs, I started observing how triagers respond to bugs. When I got an idea of the basics, I started triage with some newly filed bugs, easy ones which I could make sense of from the description. All I did was find bugs where I can ask for more information from the reporter. This is the easiest way to start as most filed bugs lack in one information or another, and it’s the primary task of the triager to get as much information from the reporters as possible.

Most people miss out the Ubuntu version they are reporting the bug against, the related package for which the bug is filed and it’s version. These are minimal information required in the bug report. The next important thing is how complete and meaningful is the bug description itself. It is not uncommon for people to be in a tensed mood when they file bugs and their description is quite unclear about their problem. Minimal requirements of a good description are what is their problem and how to reproduce this problem. Some reporters also specify things they tried to fix the problem, and surprisingly sometimes this ends to be round about solution for the problem. Some people take more responsibility of getting into the problem, finding a fix and submitting a patch to the bug as well (which is amazing btw). Now bug triage doesn’t seem to be simple all together, but it offers various levels of participation fitting with one’s level of interest and skills. I know of a few in bug squad who are specialist in dealing with duplicates, which is nothing but a reporter filing a bug which already someone (or even many others) have filed already.

Filing a same bug doesn’t help much, rather what would be welcome is looking at existing bug and adding additional information to it if possible. Similarly, one can also check existing bugs and if the problem can be reproduced at our end we can indeed confirm the bug reported by someone else.A bug also gets confirmed when the triager feels that the bug report enough information for the developer to deal with it. There is no hard and fast rule, but some guidelines on what makes a report complete (which you can find in link 1 above) and is often acquired as a trait by experience.

There is not much for the basic level of bug triage. As I got involved doing these basic things, I started learning more. Sometimes I have done little mistakes, but as I always refer to people in #ubuntu-bugs for doubt, my mistakes got immediately corrected. Am still in the lower levels of bug triage, but learning a lot. One wonderful endeavour regarding bug triage is 5-a-day project started by Daniel Holbach. It is nothing but a team of bug triagers who make sure they at least triage 5 bugs a day. This has really been working and if you would like to see some stats check this one out.  One handy link for every new triager is the Checklist.

So, when can you join us? Anytime anyday and if you are looking for special time to join then Hug Day and Global Bug Jam could be a nice opportunity 🙂

Advertisements

One thought on “my experience with bug triage

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s