On 2009-11-27 at 12:23:26 [+0100], Niels Reedijk <niels.reedijk@xxxxxxxxx> wrote: > 2009/11/27 Ingo Weinhold <ingo_weinhold@xxxxxx>: > > On 2009-11-26 at 22:08:30 [+0100], Niels Reedijk <niels.reedijk@xxxxxxxxx> > > wrote: > >> 2009/11/26 Stephan Assmus <superstippi@xxxxxx>: > >> > On 2009-11-26 at 12:08:06 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx> > >> > wrote: > >> I know it is marginal, but what the 'new' workflow offers is an extra > >> layer of triaging. > >> > >> Tickets will come in as 'new' (that's a status). They can be assigned > >> to someone (status assigned) and then that person can accept it > >> (status accepted). This means that tickets that have a certain level > >> of triaging (and that are given the status of assigned) can be > >> distinguished from both those that are being worked on (accepted) and > >> those that still need extra data (new). > > > > OK, but then I don't see any difference to the current workflow. "owner != > > nobody" means "assigned to someone" and "assigned" means "accepted by the > > developer". > > Right, there's no semantic difference there. The layer of difference > it would add is: > > new = untriaged > assigned = triaged and waiting for response from assignee > accepted = accepted by developer and is thus being worked on. Which would be equivalent to: owner: nobody = untriaged owner: <developer>, new = triaged and waiting for response from assignee owner: <developer>, assigned = accepted by developer and is thus being worked on. > > I thought what you were proposing was to differentiate between tickets > > that > > have been given to a developer and those that are confirmed by the > > developer > > to actually be her responsibility. Clearly currently we're misusing the > > "assigned" state as "being worked on" > > > > Anyhow, I'm fine with the current workflow. The only thing I'd change, if > > that is possible, is to rename "assigned" to "being worked on" or > > something > > to that extend. > > Like I said, I would like to start getting some systematic triaging of > tickets before they go to developers, and I offer doing this (and > trying to get others to do it). With every new release there is a > chance that there will be more and more tickets (and thus more that > does not answer to the standard of ticket reporting) and right now I > think developers are using their valuable time to handle these > requests. > > Anyway, that would only work with the new workflow where there is a > difference between 'new' and 'assigned' (or CONFIRMED in bugzilla > language). Why? The "assigned "status apparently just means "owner != nobody", which is redundant. I believe Bugzilla's CONFIRMED means something else, namely that the bug has been confirmed to exist (or at least the ticket has been confirmed not to be invalid). Introducing a "confirmed" ticket state would indeed make sense, if you want to do consequent triaging. CU, Ingo