| 1 |
On Thu, 10 Mar 2011 11:04:19 -0500 |
| 2 |
Mike Gilbert <floppymaster@×××××.com> wrote: |
| 3 |
|
| 4 |
> If we were to switch to the new workflow, it probably would make sense |
| 5 |
> to switch the default new bug status to UNCONFIRMED. I'm not sure how |
| 6 |
> we would handle the existing bugs in NEW status. |
| 7 |
|
| 8 |
I agree that new should now automatically be set to UNCONFIRMED when they are |
| 9 |
not assigned yet (i.e. have been automatically assigned to |
| 10 |
bug-wranglers) but to CONFIRMED when they are being assigned directly to their |
| 11 |
respective maintainers. |
| 12 |
|
| 13 |
For existing bugs, then, NEW bugs should be changed to UNCONFIRMED when they |
| 14 |
are assigned to bug-wranglers, and to CONFIRMED when they have already |
| 15 |
been assigned to their maintainers (irrespective of whether they are |
| 16 |
actually confirmed or not or whether they are deemed to be actual bugs). |
| 17 |
|
| 18 |
Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED |
| 19 |
Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED |
| 20 |
|
| 21 |
> Here are the workflow diagrams for our old Bugzilla and the new one. I |
| 22 |
> find pictures are a bit easier to follow. |
| 23 |
|
| 24 |
Thanks, those really helped. |
| 25 |
|
| 26 |
(The only problem I have with the new workflow is that bugs assigned to |
| 27 |
bug-wranglers can usually be dealt with more quickly when it is obvious |
| 28 |
that new information has been added, which is the case when a bug has |
| 29 |
been closed as RESOLVED, NEEDINFO, after which reopening it will set it |
| 30 |
to REOPENED. If we're going to lose that, then the b-w assigned list |
| 31 |
loses some definition. But maybe bugzilla 4's support of the Changed |
| 32 |
column can help there.) |
| 33 |
|
| 34 |
|
| 35 |
jer |
Archives