BugzillaWorkflowImprovements
This is a page for suggested improvements to Bugzilla workflow
Having two states that canconfirm can put a bug in? mconnor had details here I think.
Allowing canconfirm to mark dup.
Perhaps allowing canconfirm to change the product/component?
Renaming canconfirm to "cantriage" (most of the above falls under this).
See mconnor's A Modest Proposal post
See also wiki (older) FlowChart B illustrating how these might fit together. (Gekacheka 07:34, 1 Oct 2005 (PDT))
Here's the latest version of Mike Connor's flowchart.
Latest FlowChart B added NEEDSINFO and Resolved DEFICIENT (and removed shortcut paths for simplicity). (Gekacheka 18:25, 7 April 2007 (PDT))
Other ideas
It might also be good to make a list of bug states that QA people can search for which might indicate the bug needs some particular loving:
e.g.
- Status Whiteboard says "dupeme"
- Bug is UNCONFIRMED yet it has a non-obsolete patch attached
It might also be good to search for active Bugzilla people (by various criteria) and email them suggesting they apply for canconfirm or editbugs.
How about an OPEN state that shows people that a bug is actively being worked upon (no patch would be necessary) Jhermans 05:02, 30 Sep 2005 (PDT)
- That's what READY is for, I think, no? Mconnor
- I think IN-PROGRESS might be a better name for what you describe. Some developers accept a bug but have so many other tasks that they don't work on it for months, and it might progress faster if some other interested developer picked it up. Maybe for assigned/in-progress bugs bugzilla could issue a warning after 30days requesting a progress report (or expected date when work will start). And/or IN-PROGRESS could expire after some period of no activity. (Gekacheka 18:25, 7 April 2007 (PDT))
