Status: Resolved Later

[Kevin Benton]

> What we need is a clear way to mark an entry for a later release.  We are
> in
> a very regulated environment (medical devices) and need to carefully
> document which issues we decide to not address in a release (and why).  By
> using the resolved/later, we are "forced" to enter a comment (cause we set
> that parameter) and hopefully will enter the evaluation that indicates why
> the issue doesn't impact efficacy or safety.

In my mind, putting a bug into a pending status would require a comment to
explain why it's being put into that pending status.  It would also require
specifying a pending reason in a list like "VENDOR_WORK", "BUG_RESOLUTION",
"CUSTOMER_FEEDBACK", ...

Again, the status of Pending would be used more for time tracking of a bug
as a way to "stop the clock" so that a bug sitting in a group's queue
wouldn't impact their Time To Resolution (TTR) counters, but still prevent
the bug from being marked resolved (which it truly isn't).

> Now resolved/later isn't  perfect (after all, the issue isn't really
> resolved, just delayed).  But it gets close (at least for our needs).

And that's exactly my point - it's truly not resolved, so why set a status
that requires us to "lie to ourselves" and more importantly lie to reporting
software?

If we're also measuring bugs reopened in an effort to locate process faults,
all the bugs that went from Resolved/Later back to Assigned would show up in
that list.  I don't know that I would want to handle them in the same way I
handle bugs that are reopened.

What I'm trying to get across is the view of people like myself who are not
just using/developing Bugzilla to track bugs, but also to track performance
of those who are doing the bug maintenance.  In my view, Resolved/Later and
the lack of a pending status makes that tracking more difficult.

In my view, status would go new -> assigned -> resolved/decision -> verified
-> closed, or new -> assigned -> pending/reason -> assigned ->
resolved/decision -> verified -> closed or some form of this.  The clock for
developers would start as soon as the bug is "new" and would stop at both
pending and resolved, only to be re-started by going back to assigned.  The
time it takes to go from new to assigned would be seen as "ack time" or the
time it takes to acknowledge a bug.  A bug could go from new ->
pending/reason, however, that would be rare.  When a bug is resolved, the
performance of the developers would be measured by the total amount of time
the bug spent in the assigned, new and reopened statuses.  # of times
reopened would also be used as an indicator to help locate problems in the
development process.  BTW - this is the same kind of reporting I wrote
against Remedy/Helpdesk to help my team see a 90% improvement in performance
over a one year period while simultaneously decreasing the team size through
promotions.