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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
