UI for editing workflow

[Benton, Kevin]

> > For 3.2, I think we ought to rename Resolution to Sub_Status or
Reason,
> > then add a substatus table that includes the list of statuses and
> > possible sub-statuses.
> 
> Basically, you are asking for status-dependent resolutions. I haven't
> seen any demand for this elsewhere...
> 
> > This is critical when processes allow a DEFERRED
> > or PENDING status of sorts.  For process management, it's important
to
> > know why something is deferred, not just that it's deferred.
> 
> Except that we killed REMIND and LATER because they sucked. IMO, the

RESOLVED/REMIND to me makes absolutely no sense.  RESOLVED/LATER is an
oxymoron - we've resolved that we're going to fix it later?  I agree
that they did more to confuse than help.

> ideas of DEFERRED or PENDING should be implemented in a workflow using
> milestones. Right tool for the right job.

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)?  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.  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, 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.  Using a pending state would indicate that the engineer
can look at it once a week in the stale bug report.  A non-pending open
state would mean that the engineer has work to do on it now.

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.

Someone can correct me if I'm missing something in Bugzilla on how to
accomplish this without documenting a sub status, but right now, I just
don't see how to do that.  Granted, Bugzilla was never intended to be a
time management system, though it contains some aspects of that.

Kevin Benton
Senior Software Developer
MSS Silicon Design Engineering
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.