Table of Contents
A couple years ago a friend in a summer job decided that his summer firm needed a bugmaster, the catch being that he didn't quite know what one was. So he asked me if I'd written anything on the subject. I hadn't, and that ball was dropped. A couple months ago someone at Novell asked 'well, how do you deal with all these incoming bugs? Doesn't it drive your engineers insane?' The answer, again, was 'bugmaster.' But again, it was a little hard to describe what a bugmaster is, or why exactly it makes sense for large projects to have them. Hopefully this paper will fill that gap, and help explain why a bugmaster makes sense for many projects, and what a good (and great) bugmaster looks like.
Bugmastering in a nutshell: The bugmaster voraciously reads as many bugs as possible, and attempts to help the organization deal with those bugs by constantly improving the quality of the bug information hackers/developers, leaders/managers, and QA/volunteers have.
Most frequently, improving bug information means triage- the process of assigning bugs severity and priority, to help developers allocate their bug-fixing time, and cleaning the system of bugs which are in some way not useful- duplicate bugs, incomplete bugs, and bugs which have been fixed but not marked as such in a bug tracker. But it also can take a number of other forms. Among these would be mediating between developers and bug reporters in disagreements; working with duplicates; disambiguating bugs filed by non-skilled volunteers; helping other volunteers work with bugs and the bug system; training hackers and managers in good and consistent bug tracking processes; and helping hackers (or managers) better understand the state of their own project. All of these roles are important for a large software project to be really effective, and they are all too easy for projects (both open and proprietary) to overlook or do poorly, despite best intents.