Triage FAQ

Introduction

1. What is the bugsquad?
   The Bugsquad is the Quality Assurance (QA) team for GNOME. We keep track of current bugs in GNOME software and try to make sure that major bugs do not go unnoticed by developers. It is not our job to fix the bugs, although there is nothing to stop you from submitting patches if you have hacking experience. It is a great way to return something to the GNOME community whether you can program or not.

2. What skills are needed in order to help triage bugs?
   Common sense and a bit of pragmatism is all that is needed to join the bugsquad. Coding skills might help you evaluate or fix particular bugs, but triaging most bugs will not require knowledge of programming. Bug triaging is a great way for people who do not know anything about programming to return something to the GNOME community.

3. What software is needed in order to assist in triaging bugs?
   All you need is a web browser and an internet connection. Some people have triaged bugs using Internet Explorer on a Windows desktop at work. It is usually best, though, to be running a reasonably recent version of GNOME.

4. How long does it take to learn how to triage bugs?
   Triaging bugs is a great way to help out with GNOME if you do not have much time. It does not take very long to get started, and on average, the simpler bugs can be triaged in anywhere from 2-10 minutes.

5. Why should I join/help the bugsquad?
   There are several reasons:

   1. Maintainers will not have to spend as much time reading bug reports and will thus be able to concentrate on fixing bugs, making GNOME better for you.
   2. You will learn more about the capabilities of GNOME (e.g. when you look at a bug that someone files about Nautilus' "View as Music" listing which you did not know about...)
   3. Possibly getting your name (well, email address) on the weekly bug summary
   4. You will get a better feel for the different areas of GNOME and will potentially be able to find other areas that you can also help (e.g. documentation, graphics, translation, web design, user/human interface work, assisting with developing certain applications, etc.) Lots of people have gone on from the bugsquad to be useful contributors of all sorts within GNOME, after the bugsquad gave them an overview of the available opportunities.

Bug Days

1. What/When/Where is Bug Day?
   Bug Day is an organized day for bug triage. In other words, we clean up bugzilla. We do this by confirming or closing bugs, by making sure they have enough information, and so on. The goal is to make bugzilla a more useful tool for developers by removing bugs that would clutter up their lives, and organizing the remaining ones.
   Bug Days take place on Thursdays; the time can change from week to week so watch out for announcements. They are hosted on irc.gnome.org in channel #bugs. Lots more information about bug days can be found at BugDays

2. Thursdays are bad for me. Will there be bug days at other times or dates?
   While at the moment there are no plans to have bug days on other days of the week, someone is in #bugs and ready to help out new volunteers nearly every hour of any day. So just come by and say you want to help out--it is very likely someone will have a few minutes to help you out, though you may have to be patient for a response on some days. If for some reason no one seems to be responding, feel free to mail the bugsquad list (gnome-bugsquad@gnome.org).

3. What if there was no announcement for Bug Day on www.gnomedesktop.org?
   We try to announce Bug Days on www.gnomedesktop.org. Whenever we do, we tend to get a good turnout. The problem is that there are only a few of us available to run Bug Days and we all have many other tasks keeping us busy as well. So, if we are afraid we may not be able to keep up with all the extra questions that come on an announced Bug Day, we tend to just skip the announcement. You are still welcome to come by and ask questions, though. You are also encouraged to assist us in answering other peoples' questions once you are comfortable triaging bugs.

Getting Started

1. How do I get started?
   The triage guide is the best starting place. It contains details on all the steps necessary to lend a hand.

2. How do I get permission to change bugs?
   At first, we prefer that new volunteers ask other bug squad members before making changes, so by default you cannot change many bug fields. If you want to change a bug, ask in IRC. If the changes you suggest making are correct, someone will make the changes for you. After you have shown your good judgment a few times, you can ask in #bugs if you can have permissions to change bugs. Note that some bugmasters are hesitant to give people permissions to change bugs (usually the hesitant ones are the ones that have only had the ability to do so for a little while), while others are much more lenient. Remember that and realize that it's nothing personal if someone else gets permissions more quickly than you.

3. Where can I get answers to my questions?
   If neither the triage guide nor this FAQ contain the answer to your question, ask in channel #bugs on irc.gnome.org or email gnome-bugsquad@gnome.org. Feel free to jump right in and ask your question.

4. Are people going to be annoyed with all my questions?
   No. We get asked this a lot, but the answer is no. Being able to answer questions is the entire purpose for #bugs and the mailing list. Trust us.

General Triage Questions

1. What if I can not find any changes to make to a bug? What if all the fields look like they are set correctly?
   Then simply move on to a different bug.

2. What if I can not find a bug to triage?
   There is a finding bugs to triage page that lists many places you can look for bugs to triage. One of the links should almost certainly give you enough bugs to look at. In fact, the first link is enough to keep most people busy. However, if you still can not find any bugs, ask someone in #bugs on IRC.

3. What if a certain bugs look like a duplicate of many different bugs?
   Try to find the "original" one and mark your bug as a duplicate of that one. (i.e. if bug A has been reported and bugs B & C have been marked as a duplicate of A, then try to mark future bugs as a duplicate of A and not as duplicates of B or C.)

4. What does unknown@bugzilla.gnome.org mean, and does bugmail still get sent?
   If a reporter is unknown@bugzilla.gnome.org, it means that the reporter did not have a bugzilla account at the time he submitted the bug. It's really a misnomer, though: bugzilla does know the e-mail address supplied by the reporter and, if the address is valid, he will get e-mail just like anybody else.

5. I can not reproduce a certain bug. Can I close it?
   You have to take into account why you can't reproduce it. Many bugs happen only under certain rare circumstances, and you might not be able to reproduce it due to a different system configuration, or you might be running linux instead of solaris.
   If the bug is sufficiently general, is filed against an old version and looks as though it is now fixed, you can close it. If you're not sure, ask in #bugs or on the bugsquad mailing list. You can also add a comment saying that you can not reproduce the bug (along with any relevant information about your system) if you think it will help.

6. What if product development has been stalled ?
   Try to find project maintainers or developers and try to get information about future development plan. In case you get reply that product is unmaintained and there is no future plan, close all the bugs under the project as WONTFIX, tag whiteboard with gnome[unmaintained] and send mail to gnome-bugsquad@gnome.org so further actions can be taken in case requires.

Advanced

1. I am a programmer. Are there more advanced things I can do related to triaging?
   Yes, there are several things you could do that someone without programming skills might not be as adept at or would not be able to do at all. Bug triaging is a great way to find a small part of GNOME to start on while making your first GNOME baby steps. Here are a few of the things you can do:

   1. Obtain easy directions to duplicate bugs (sometimes it is easier for those with a programming background to find these)
   2. For bugs that are reported but do not contain debugging symbols, try to obtain debugging symbols for them. Some stack traces can help a developer find a problem even without debugging symbols, but often times they are not very helpful.
   3. Find and mark duplicates of crasher bugs (those without a programming background may take longer to get used to dealing with stack traces).

   4. Look for bugs with the gnome-love keyword. Fix them.

   5. Look for bugs which look interesting. Contact the maintainer to let him/her know you would like to work on it and verify that no one else is working on it. Then fix it.