[Python-Dev] Define Tracker workflow

[Ron Adam]

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