<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

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.<br>

<br>

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.<br>

<br>

<i>Lee Ivy<br>

QA Architect<br>

netZentry, Inc.<br>

<a class="moz-txt-link-abbreviated" href="mailto:lee@netzentry.com">lee@netzentry.com</a><br>

</i><br>

Stuart Donaldson wrote:

<blockquote cite="mid41B87E52.6000702@asyn.com" type="cite">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.

  <br>

  <br>

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.

  <br>

  <br>

  <br>

</blockquote>

<br>

</body>

</html>