BugzillaWorkflowImprovements: Difference between revisions
| Line 14: | Line 14: | ||
See also wiki [[BugzillaWorkflowImprovements:FlowChart B|FlowChart B]] illustrating how these might fit together. ([[User:Gekacheka|Gekacheka]] 07:34, 1 Oct 2005 (PDT)) | See also wiki [[BugzillaWorkflowImprovements:FlowChart B|FlowChart B]] illustrating how these might fit together. ([[User:Gekacheka|Gekacheka]] 07:34, 1 Oct 2005 (PDT)) | ||
Here's the latest version of [http://steelgryphon.com/testcases/bugzilla-workflow-9.png Mike Connor's flowchart]. | |||
=Other ideas= | =Other ideas= | ||
Revision as of 16:58, 11 October 2005
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 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.
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