Status: Resolved Later

[Stuart Donaldson]

Pending another bug would be blocked by another bug.
Pending customer feedback means something else is blocking the bug. You 
still have an idea of when you want this bug fixed.

Keywords or Flags could work to "categorize" the bugs to indicate that 
the bug is waiting on customer feedback. Another option would be 
reassigning the bug to someone whos job it was to collect the customer 
feedback.


Kevin Benton wrote:

> What if a bug is pending something other than a future release? What 
> if the bug is pending another bug or if the bug is pending customer 
> feedback… Should that time count against the engineer’s time to 
> resolution? I agree that Target Milestone will help. I agree that bugs 
> that are postponed for another target/milestone should be in a pending 
> status. I’m adding FUTURE_RELEASE to my pending reason list.
>
> ------------------------------------------------------------------------
>
> *From:* developers-owner at bugzilla.org 
> [mailto:developers-owner at bugzilla.org] *On Behalf Of *Lee Ivy
> *Sent:* Thursday, December 09, 2004 11:02 AM
> *To:* developers at bugzilla.org
> *Subject:* Re: Status: Resolved Later
>
> 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.
>
> /Lee Ivy
> QA Architect
> netZentry, Inc.
> lee at netzentry.com <mailto:lee at netzentry.com>
> /
> 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.
>