On Mar 16, 2012, at 12:52 AM, Mark A. Hershberger wrote: > Rob Lanphier <ro...@wikimedia.org> writes: > >> Mark and I just discussed this, and he's going to look into having a >> "CONFIRMED" state. > > https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/ > > describes this implementation: > > UNCONFIRMED -> CONFIRMED -> IN_PROGRESS -> RESOLVED -> VERIFIED > > Since "UNCONFIRMED" is used so many places, I'm worried about changing > that to "NEW".
So up until last month we had this workflow: 1. NEW 2. ASSIGNED[1] 3. RESOLVED (sometimes) 4. VERIFIED (or) REOPENED -> step 1 I understand that last week it changed to: 1. UNCONFIRMED 2. NEW 3. ASSIGNED 4. RESOLVED (sometimes) 5. VERIFIED (or) REOPENED -> step 2 I don't think it makes sense to use "NEW" as "CONFIRMED", because, agreeing with [2], "NEW" is not descriptive. How about using "CONFIRMED" and dropping "NEW" completely? -- Krinkle [1] The difference between a confirmed bug having an assignee and status ASSIGNED, is that ASSIGNED means someone has it on his agenda to actively work on. Whereas the assignee in general is just whoever is currently watching over it. ASSIGNED and IN_PROGRESS are basically there same. Except that "IN_PRORESS" is slightly later than ASSIGNED but using both doesn't make sense and we're already using ASSIGNED. [2] https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/ [3] http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
