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