Well, I’m back. The puncture wounds have healed quite a bit (though I shall have more scars to add to my collection of accident related injuries). The Radial nerve got injured so I still have no feeling on my left thumb, and occasional shooting pain, but that should go away within the next few weeks. So, I’m back to blogging, and bug triage.
When I first started triage almost 3 years ago, I didn’t really have a process for triage. It was usually to +start with a list of all the Bugs in a certain component, and just start at the top and work my way down. This is unfortunately one of the only ways we can triage with so many UNCO bugs. trying to run queries either pulls up very small and limited results, or pages that are hundreds or thousands of bugs long. The situation is improving though.
When I triage, I have several methods that I use. The most usual is running through a query that returns all the bugs filed in the past 24 hours. It returns all bugs in Firefox, Toolkit and Core from the past 24 hours that are UNCO, NEW, ASSIGNED and RESOLVED. (link to come soon, BMO is taking forever to run queries ATM for some reason). I will then browse the whole list (usually around 100-150 bugs a day).
I first start with what you could call “low hanging fruit”. I go through and find all bugs that look like they will be support issues, extension issues (ones that have words like “Google Toolbar” in the summary are usually a good start). I will go through, and try to resolve those bugs first to cut down on bug noise. Extension issues usually end up getting reported to the developer of the problem extension, and support bugs get directed to SUMO.
Then I begin to go through the other bugs. It is not possible to look at or touch every bug. I am not an expert in every component of the products I triage (not an expert in any I have to admit), and some bugs are simply above my head. Other bugs have already been touched by some of our other excellent triagers. However I try to at least look at every UNCO bug submitted in any given day. I usually visit this query several times a day.
I then start to plunge into the depths of BMO. I will either go through and mark untouched bugs as CLOSEME (I usually focus on that more at the beginning of the month), or I will start to run specific queries I want to focus on. For example, some months I will run queries in Firefox looking for bugs in printing (which is often improperly filed in Firefox General instead of the Core Components). Other days I will look for specific extensions or common issues I have seen trending recently and will go and search for more dupes.
What is your triage process? Any ideas for ways I can change or improve? Most of triage is a personal style. There is no cut-and-dried “perfect” technique to Triage. Different people work better different ways. It is all about how you work that makes our Triage community unique and vibrant. Our differences make Mozilla what it is today.
I’m trying to toss around some ideas on improving specific Triage, I’ll be posting soon on some thoughts for improving communication between developers and Triagers, something that is sorely lacking at the moment.
