Bugzilla semantics: marking bugs as triaged

[Jesse Keating]

On Fri, 2009-07-17 at 13:43 -0400, Christopher Beland wrote:
> If it is useful to indicate whether or not a bug has been reproduced,
> there could be three states: NEW, TRIAGED, and CONFIRMED.  It could work
> in a one-dimensional fashion (no keywords) if CONFIRMED implies TRIAGED.
> It seems like if someone is going to all the work of confirming a bug
> *and* they have permission to change the bug's state, they might as well
> triage it as well.
> 
> This additional state only becomes useful if there are people actively
> looking in Bugzilla trying to reproduce bugs that have already been
> triaged.  Is that actually the case?   Or are there so many untriaged
> bugs that no one really cares whether the "extra credit" work of
> reproduction has been done on all of the triaged bugs for a specific
> component?
> 
> -B.
> 

Two classes of people, although for some groups the same person plays
both roles.  Triaging can mean that the triager thinks enough
information has been provided, and it's on the right component.  However
the issue may still need to be reproduced.

It's of my opinion that we should try to avoid adding too many interim
steps here, or states, and try to keep things as simple as possible.
Bugzilla is already way way way too complicated for people to file bugs
and manage bugs.  A simple keyword to mark whether it has been triaged
or not is probably best, something that the triagers can use to avoid
looking at the same bugs twice.  Bonus points for avoiding bugzilla spam
when that keyword gets set, hard to do outside of the xmlrpc api though.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20090717/a5094722/attachment.sig>