I had interesting discussions with Andy Lindeberg and jlaska today about the semantics of our current Bugzilla - and particularly triage - workflow.

We were thinking about the NEW / ASSIGNED dichotomy, and Andy and I came to the conclusion that it doesn't really make a lot of sense.

Right now, Bugzappers uses it one way, Andy uses it another for anaconda. In the Bugzappers process, ASSIGNED just means, really, Triaged: you set a bug to ASSIGNED once the triage process is complete.

For Anaconda, Andy sets bugs to ASSIGNED once they're assigned to the correct anaconda maintainer (whether or not the rest of triage is yet fully completed).

Neither case is really terribly problematic, but they also don't make a whole lot of sense, really. Having 'triage completed' as a status is a bit arguable; it's not quite in the flow of the statuses, as a bug could be at a point 'beyond' ASSIGNED but not yet have been triaged, for instance. And it's also just semantically wrong - the word 'assigned' does not mean 'triaged'.

In the anaconda case, we just thought about it and decided the use of ASSIGNED isn't really _achieving_ anything: you can tell whether the bug's been assigned or not just by looking at who it's assigned to.

We sort of came to the conclusion that it'd probably make the most sense to have a 'Triaged' keyword that's used to affirm that a bug's been triaged (in fact there already is one, but it's not officially used in our current process), and abandon the distinction between NEW and ASSIGNED. Ideally, the ASSIGNED state would just be removed, but we could keep it and just note in our workflow / policy that it's not really used to mean anything in particular.

This could, I think, be implemented quite quickly if desired; I think we could rig something up to set all bugs in ASSIGNED state (except anaconda ones) to have the 'Triaged' keyword, that shouldn't be impossible.

We'd be interested in thoughts - negative, positive, whatever - on the idea. Thanks!