Status: Resolved Later

[Stuart Donaldson]

Lee Ivy wrote:

> In my pre-Bugzilla days, we used the Target Milestone approach and it 
> worked well. A bug's Version showed what version the problem was found 
> in; if you didn't want to fix it right away you left it in the 
> Assigned state but set the Target Milestone for the future release 
> where you hoped (planned?) to fix it. The bug was still assigned to a 
> developer, but it was clear that bugs only needed to be fixed right 
> away if their Target Milestone matched the current release.
>
> I prefer this to Resolved/Remind -- as a QA guy, I think 
> Resolved/Remind sounds like a developer cop-out, "I am marking this 
> resolved but I didn't actually fix it, I just want to be reminded to 
> fix it someday in the future -- trust me!". To me, moving a bug to 
> Resolved implies a hand-off of responsibility from development to QA, 
> and that is not true for Resolved/Remind.

That was one of our major objections to Resolved/Later.  The bug was not 
actually resolved, but you were "targeting" it to some unknown point in 
the future.

By using the Target Milestone, the fields continue to hold valid 
values.  The Status and Resolution are all clear, and the Milestone is 
clear on when you want it.  If you Resolved/Later then the Milestone is 
meaningless, and Resolved is confusing.

>
> Stuart Donaldson wrote:
>
>> 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.
>>
>>
>