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

anatoly techtonik techtonik at gmail.com
Wed Oct 19 21:17:52 CEST 2011

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.

More information about the Python-Dev mailing list