As many of you know, I have been working on relaunching a triage team within Fedora (more on that later as we come closer to a formal launch - there's lots of things that we need to do before we announce that to the world at large). Part of the effort is streamlining the current Bugzilla workflow (or lack thereof). These workflow guidelines were approved at the FESCo meeting on January 24, 2008. Note the use of the word guidelines, these aren't hard and fast rules that we are imposing on people. If you have a good reason to break them, feel free - but this is the mantra that the triage team will be going by.
When a reporter enters a bug, the report automatically starts out in a NEW state. The triage team will be primarily looking at bugs in this state. From this state, the triage team can either change the status to ASSIGNED (which indicates that the bug is well defined and triaged), or use the NEEDINFO state to request additional information from the reporter, or close the bug (either as a duplicate of an existing one, or using other closure reasons - CANTFIX for problems with proprietary drivers or kernels that have such drivers loaded, for example).
The ASSIGNED state is a state that has a new meaning - it used to mean that the bug was actually assigned to a person. Instead, it now means that the bug is capable of being worked on by a maintainer - i.e. the triage team believes that this is a complete, actionable bug - i.e. with a stack trace for a crasher, various log files for other components, complete AVC message for SELinux stuff, etc.
When a maintainer has a fix for a bug checked into CVS, they should move the state of the bug to MODIFIED. This is an indication that the fix is indeed in CVS, and has likely had a build submitted against it. You may want to (though it's certainly not required) post a link to the koji build so that the adventuresome tester can go grab a copy and verify the fix.
Once a maintainer submits an update via bodhi against a particular bug, and the update hits updates-testing, the state of the bug will transition via bodhi to ON_QA. This is a indication to the reporter of the bug that there is a fix for the bug available, and that they should test the package that's in updates-testing, and report on it via bodhi and/or as a comment in the Bugzilla. The comment used by bodhi will be more verbose as to how to give feedback via bodhi.
Another change in the current process is that once the update from bodhi hits stable, the bug will be automatically closed. There used to be a checkbox in bodhi not to auto-close the bug - this either has been or will soon be removed. It is therefore important that one bug describe one issue in one release. If the same bug applies to multiple releases, then multiple bugs should be opened (possibly using the clone feature of bugzilla).
The final change is that NEEDINFO bugs are eligible to be closed by the triage team (after review that the information has not been provided, that it's not the maintainer that the NEEDINFO is requested of, etc) after 30 days of inactivity. A stock message will be provided to triagers (yet to be written) with which to close these bugs.
Sorry for such a long e-mail, I just wanted to make certain that everyone was informed of these changes and an impending launch of the BugZappers! Subject line shamelessly stolen from Max and adapted :)