Well someone called my bluff and dared me to write a useful post to a fedora mailinglist. I'd like to start a discussion on implementing a community based bugzilla triage team for the Fedora bugzilla. Okay well actually I'd be interested in a broader discussion of establishing a full guide for beta testers/bug hunters for the fedora.redhat.com..but I'd like to focus on triage first, since bugzilla triage has the potential to greatly improve the productivity of package maintainers/developers and its something interested community members with little coding skill can spend a few minutes here and there during the day making a useful contribution if there is a good set of guidelines and some mentoring. So in preparation for this little essay. I've read over the Gnome Bugsquad's project's detailed outline of how to do useful gnome bugzilla triage. http://developer.gnome.org/projects/bugsquad/ http://developer.gnome.org/projects/bugsquad/triage/ I don't want to rehash the full documentation Gnome has done, but I would like to hi-lite some of the things Gnome's Bugsquad webpages that would probably be useful for a Fedora triage team. Okay well actually taking pretty much the entire process Gnome has developed sort of makes sense to me. The only issue i see that Fedora will have to deal with is how to escalate a bug ticket for a package to an upstream project maintenance system, But here are some specific things I like about gnomes bugsquad: *) Strong documentation on the website on the steps to triage bugs. Clear example cases, http://developer.gnome.org/projects/bugsquad/triage/examples.html and even more importantly examples on how to form bugzilla queries that make sense when trying to pick bugs to triage. http://developer.gnome.org/projects/bugsquad/triage/finding-bugs.html *)A focus on having people learn from established bugsquad members. New contributors to the triage effort are encouraged to suggest how bugreports should be changed to active bugsquad members either through irc or in a mailinglist...and over time they earn more access to make bugzilla bugreport changes themselves..once they've shown they've got the hang of how to triage. It's a mentor approach to get around bugzilla's inherent steep learning curve for the average new bug reporter. *) examples of polite stock responses when bugs need more information to be useful for the developer to understand the technical specifics of what is going wrong. The 'get to the point' culture of how development is done can be a culture shock to people who are new to this sort of environment. The current Fedora test release seems to be appealing to many non-techinically savvy users...people who are excited by the project, and want to make a best effort at contributing via bugreporting...some of these people are stumbling over how bugzilla interacts with them. Not in a technical sense...but strictly on perception oh how valuable their contribution. A triage team can be used to grease the wheels a little. The polite stock responses gnome has could go a long way to overcome the perception issues bugzilla's rather terse responses are causing. http://developer.gnome.org/projects/bugsquad/triage/stock-responses.html *) Last but not least....organized Bug Day efforts...to clean the cruft out of Fedora. If a triage team is of significant interest as a tool to increase the productivity of the fedora developers...i think the first step is laying down some useful guidelines and a 12 easy steps outline of what triage in fedora involves so it can be documented on the website. I can't imagine its going to look horribly different than how gnome handles this issue. The other think i really think is different is how to handle bugs that should also be reported to an upstream project maintainer. I welcome further discussion on this issue. Other contrasting models of how this sort of bug triage is done by other projects than Gnome would be useful too. I firmly believe that the pacing item in development processes will continue to be the number of hours in a day a developer has. I'm not going to pretend that everybody in this community has the ability to contribute technical skill on the level needed to actually constructively work on major portions of he Fedora codebase. But i think there are a significant number of technically proficient people who can help the experts keep their todo lists organized...and act as an interface between end-user and developer, saving valuable developer time for code writing, instead of "please add more info" message writing in bugzilla. -jef"Ask not what the fedora developers can do for you...but what you can do to for the fedora developers"spaleta
Attachment:
signature.asc
Description: This is a digitally signed message part