Define Tracker workflow

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Define Tracker workflow

anatoly techtonik
Does everybody feel comfortable with 'stage' and 'resultion' fields in tracker?

I understand that 'stage' defines workflow and 'resolution' is status
indicator, but the question is - do we really need to separate them?
For example, right now when a ticket's 'status' is closed (all right -
there is also a 'status' field), we mark 'stage' as
'committed/rejected'. I see the 'stage' as a workflow state and
'committed/rejected' value is confusing because further steps are
actually depend on if the state is actually 'committed' or 'rejected'.

    stage: patch review -> committed/rejected

When I see a patch was rejected, I need to analyse why and propose a
better one. To analyse I need to look at 'resolution' field:

  duplicate
  fixed
  invalid
  later
  out of date
  postponed
  rejected
  remind
  wont fix
  works for me

The resolution will likely be 'fixed' which doesn't give any info
about if the patch was actually committed or not. You need to know
that there is 'rejected' status, so if the status 'is not rejected'
then the patch was likely committed. Note that resolution is also a
state, but for a closed issue.

Let me remind the values for the state of opened issue (recorded in a
'stage' field):
  test needed
  needs patch
  patch review
  commit review
  committed/rejected

There is a clear duplication in stage:'committed/rejected',
resolution:'fixed,rejected' and status:'closed'. Now `status` can be
one of:
  open
  languishing
  pending
  closed

For me the only things in `status` that matter are - open and closed.
Everything else is more descriptive 'state' of the issue. So I'd merge
all our descriptive fields into single 'state' field that will accept
the following values depending on master 'status':
open:
  languishing
  pending
  needs test
  needs patch
  patch review
  commit review

closed:
  committed
  duplicate
  fixed
  invalid
  out of date
  rejected
  wont fix
  works for me

Renamed 'test needed' -> 'needs test'. For a workflow states like
'later', 'postponed' and 'remind' are too vague, so I removed them.
These are better suit to user tags (custom keywords) like 'easy' etc.


Implementing this change will
1. define clear workflow to pave the road for automation and future
enhancements (commit/review queue, etc.)
2. de-clutter tracker UI to free space for more useful components
3. reduce categorization overhead

--
anatoly t.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Define Tracker workflow

briancurtin
On Wed, Oct 19, 2011 at 14:17, anatoly techtonik <[hidden email]> wrote:
> The resolution will likely be 'fixed' which doesn't give any info
> about if the patch was actually committed or not.

If there's no commit update in the messages on the issue, you should
assume it was not committed. At that point, either it wasn't actually
committed (fixed), or the person forgot to tag the issue in the commit
message, which they should remedy by just posting a message with the
changeset ID.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Define Tracker workflow

Ron Adam-2
In reply to this post by anatoly techtonik
On Wed, 2011-10-19 at 22:17 +0300, anatoly techtonik wrote:

> Does everybody feel comfortable with 'stage' and 'resultion' fields in tracker?
>
> I understand that 'stage' defines workflow and 'resolution' is status
> indicator, but the question is - do we really need to separate them?
> For example, right now when a ticket's 'status' is closed (all right -
> there is also a 'status' field), we mark 'stage' as
> 'committed/rejected'. I see the 'stage' as a workflow state and
> 'committed/rejected' value is confusing because further steps are
> actually depend on if the state is actually 'committed' or 'rejected'.
>
>     stage: patch review -> committed/rejected
>
> When I see a patch was rejected, I need to analyse why and propose a
> better one. To analyse I need to look at 'resolution' field:
>
>   duplicate
>   fixed
>   invalid
>   later
>   out of date
>   postponed
>   rejected
>   remind
>   wont fix
>   works for me
>
> The resolution will likely be 'fixed' which doesn't give any info
> about if the patch was actually committed or not. You need to know
> that there is 'rejected' status, so if the status 'is not rejected'
> then the patch was likely committed. Note that resolution is also a
> state, but for a closed issue.

It's somewhat confusing to me also.


> For me the only things in `status` that matter are - open and closed.
> Everything else is more descriptive 'state' of the issue. So I'd merge
> all our descriptive fields into single 'state' field that will accept
> the following values depending on master 'status':
> open:
>   languishing
>   pending
>   needs test
>   needs patch
>   patch review
>   commit review
>
> closed:
>   committed
>   duplicate
>   fixed
>   invalid
>   out of date
>   rejected
>   wont fix
>   works for me

I like the idea. But its not clear what should be set at what times.

While trying not to change too much, how about the following?

Status:
    Open
    Closed

Stage:
    In progress:
        needs fix       (More specific than the term 'patch'.)
        needs test
        needs docs
        needs patch     (Needs a combined fix/test/docs .diff file.)
        needs patch review   (To Accepted if OK.)
        languishing     (To "Rejected:out_of_date" if no action soon.)
        pending

    Accepted:
        commit review
        committed          (And Close)

    Rejected:           (Pick one and Close.)
        duplicate
        invalid
        out of date
        won't fix
        cannot reproduce  (instead of 'works for me')

This combines the stage and resolution fields together.

Currently the stage is up in the upper left of a tracker page, while the
status and resolution is further down.  They should at least be moved
near each other.

  +------------------+------------------+-----------------------+
  | status:          | stage:           |resoltution:           |
  +------------------+------------------+-----------------------+

But it would be better if it was just...

  +----------------+--------------------------------------------+
  | status:        | stage:                                     |
  +----------------+--------------------------------------------+

And just list the stages like...

    status: Open     stage: In progress -> needs docs

    status: Open     stage: In progress -> needs patch review
       
    status: Open     stage: Accepted -> commit review

    status: Closed   stage: Accepted -> committed

    status: Closed   stage: Rejected -> invalid

It's not entirely consistent because while it's open, the stage refers
to what is needed, but once it's closed, it refers to the last item
done.  But I think it would be fine that way.

As for more detailed info, you pretty much have to read the discussion.

Cheers,
   Ron






_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com