UI for editing workflow

[Gervase Markham]

Benton, Kevin wrote:
> As I see it, the problem is - how do you deal with it when the reason
> something is deferred is beyond your control (i.e. pending customer
> feedback)?  

I don't think it's all that helpful to get into a discussion about which 
particular workflows and states are good process and which are bad; 
after all, we are implementing a general mechanism so that people can 
shoot themselves in the foot if they so choose :-) But some thoughts:

> What about when a deferment is due to verification
> (VDEFERRED) - that might make sense for milestones or deadlines, but
> it's helpful to be able to mark the bug as being in that deferred state
> because managers like to know what's really keeping us from reaching our
> goals today. 

In the current workflow, this state is RESOLVED - i.e. the state between 
a bug being fixed and it being VERIFIED. I don't consider this to be 
"deferred", unless any bug not being actively worked on at this very 
moment counts as "deferred".

> At the same time, those managers want to know why
> something is deferred.  The other thing that a deferred state does is it
> helps users sort through tasks more easily.  When a bug is deferred for
> customer feedback, 

a.k.a. NEEDINFO :-) You are using a very broad definition of the word 
"deferred".

> the engineer knows that he/she can either ignore the
> issue or wait for it to show up again on their stale bugs report
> (non-closed bugs that have gone 7 days without an update for example).
> That helps the engineer stay focused on what the engineer can work on
> versus what's out there that needs to be worked on.  Items pending a
> future milestone may need some work now even though it's more than one
> milestone away. 

Except that then they should be broken down into multiple related bugs, 
some targetted at the next milestone, others targetted at a later milestone.

The absolute _meaning_ of "Milestone: Future" is "no one has to work on 
this now". If someone has to work on it, it's not Future.

> Managers are asking "How long did it take to resolve that issue" without
> asking engineers to fill in the time tracking data.  We used to do it in
> Remedy and we could do it in Bugzilla too with a little adjustment.

Surely this is the time between being filed and being RESOLVED? No 
changes required.

Gerv