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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
