[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Fedora Bugzilla Triage-Overview



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]