[Python-Dev] 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.