Status: Resolved Later

[Kevin Benton]

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

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. 



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20041209/add0f2f2/attachment.html>