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.
On Wed, Oct 19, 2011 at 14:17, anatoly techtonik <techtonik@gmail.com> wrote:
The resolution will likely be 'fixed' which doesn't give any info about if the patch was actually committed or not.
If there's no commit update in the messages on the issue, you should assume it was not committed. At that point, either it wasn't actually committed (fixed), or the person forgot to tag the issue in the commit message, which they should remedy by just posting a message with the changeset ID.
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
participants (3)
-
anatoly techtonik
-
Brian Curtin
-
Ron Adam