[Python-Dev] Define Tracker workflow (original) (raw)

Ron Adam ron3200 at gmail.com
Thu Oct 20 04:42:30 CEST 2011

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

More information about the Python-Dev mailing list