UI for editing workflow
Benton, Kevin
kevin.benton at amd.com
Thu Apr 12 21:55:58 UTC 2007
Gerv - nice job on a significant process improvement with providing a
way to manage status transitions from the UI.
I think that taking it a bit further might be even better. Offering
users the ability to configure which statuses are possible versus those
that are not really helps. I think that we're missing the ability to
configure which statuses are open versus those that are closed. I
wonder if it wouldn't make sense to have a way to configure that list
from this page as well. Maybe by adding a column on the left that
allows users to select Open/Closed would be intuitive like...
| State Type | UNCONFIRMED | NEEDINFO | NEW ...
{Start} | | | |
UNCONFIRMED | [ Open |v] | | O | O
NEEDINFO | [ Open |v] | O | | x
NEW | [ Open |v] | O | x |
ASSIGNED | [ Open |v] | O | x | x
REOPENED | [ Open |v] | O | x | O
RESOLVED | [Closed|v] | O | O | O
VERIFIED | [Closed|v] | O | O | O
CLOSED | [Closed|v] | O | O | O
BURIED | [Closed|v] | O | O | O
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. 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. The same
can be said about DISCARDED - why was an issue discarded? Then, when a
sub-status is available, for a given status, one of the sub statuses can
be required.
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.
> -----Original Message-----
> From: developers-owner at bugzilla.org
[mailto:developers-owner at bugzilla.org]
> On Behalf Of Gervase Markham
> Sent: Thursday, April 12, 2007 10:34 AM
> To: developers at bugzilla.org
> Subject: UI for editing workflow
>
> LpSolit is working on custom statuses and editable workflow. I've
mocked
> up a UI for configuring what transitions are permitted.
>
> What we are basically doing here is configuring permitted and
forbidden
> transitions in a state machine. This particular application cries out
> for a matrix where you mark a transition as yes/no at each
intersection.
>
> http://landfill.bugzilla.org/qa30pg/page.cgi?id=editworkflow.html
>
> [When you define a new status, you say whether it's an open status or
a
> closed one, and that drives the colour (and other things like whether
a
> resolution is required).]
>
> Note click behaviour and tooltips. I think this UI is good because you
> can visually pick out patterns in the workflow, e.g.:
>
> * The big blue block in the top left shows you can move from any
opened
> state (apart from UNCO) to any other one - except you can't do
> REOPENED -> NEW.
>
> * The vertical line of three in the middle shows that you can REOPEN
> from any closed state apart from BURIED.
>
> * The diagonal line in the bottom right shows that RESOLVED ->
VERIFIED
> -> CLOSED -> BURIED is a progression.
>
> * The nearly-empty vertical line on the left shows there's no way back
> to UNCONFIRMED.
>
> Other features:
>
> * Impossible or meaningless transitions are clearly marked by the lack
> of a checkbox.
>
> * It easily answers the obvious questions in *both* directions - i.e.
> "Where can I go from UNCONFIRMED", and "How can I get to VERIFIED".
A
> list-based system would only answer one of those easily.
>
> What do you think?
>
> Gerv
More information about the developers
mailing list