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
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
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.
Fedora -- Freedom² is a feature!