Status: Resolved Later
Stuart Donaldson
stu at asyn.com
Thu Dec 9 16:33:22 UTC 2004
We wrestled with this, and I am sure I saw somewhere the suggestion of
using Target Milestones. That is the strategy we have adopted. You can
target this to any of the builds on the current project, or target it to
the next release, or set the target to deferred which means some
undetermined future release.
I like the benefit of the required comments when using Resolve/Later,
however Later was not granular enough, and the paradigm seemed to fit
the milestone paradigm closer.
Kevin Benton wrote:
>>>I'm wondering - does it make more sense to create a pending status with
>>>a reason code than to change status to resolved later because the issue
>>>(if set to resolved later) in my interpretation, really isn't resolved,
>>>but instead, put on the "back burner."
>>>
>>>
>>Why not make a priority level for back burner and not change the status?
>>
>>
>
>That's a very good point. As a person who is also responsible for tracking
>process flow, I don't want to impact the priority / severity levels just
>because something is pending. A number of different pending statuses come
>to mind, but all of them revolve around the developer waiting for action
>outside their control as it relates directly to the bug in question.
>
>
>
We are currently trying to use the Flags for this. Someone requests a
review from someone else, such as a UI review, or a Documentation review
by setting the flag. We have added global reports as I suggested in
another thread a while back to allow you to select all bugs in the
Documentation review queue for example. This doesn't change the owner
of the bug, just indicates that input is requested from the
Documentation team.
-Stuart-
More information about the developers
mailing list