Status: Resolved Later

[Kevin Benton]

I should have stated it this way - I'm tracking time where the developer is
responsible for acting on the bug.  For reporting purposes, this would be
*much* easier to track if there were an associated status change when the
developer is waiting on something outside their control.

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Stuart Donaldson
> Sent: Friday, December 10, 2004 10:03 AM
> To: developers at bugzilla.org
> Subject: Re: Status: Resolved Later
> 
> Are you tracking time spent "fixing" the bug, or time that the bug is in
> a state where the developer could be working on it?
> 
> My guess is the later from your description.
> 
> If you use the bug dependencies, you will always have a combination of
> fields that result in wether or not someone can actually be working on
> things.   I use a set of queries to determine the various conditions
> that our items typically end up in.  I also have these same queries used
> in the new chart system so I can get historical charts for the bugs in
> each of the various states (Documentation Review, UI Review, Management
> Review, etc...)
> 
> The reporting on this type of issue is precisely why I raised the
> question a while back about standard reports, because the standard
> reporting (and standard charts for the new chart system) are pretty
> limited and do not have an extension mechanism to define new standard
> queries and reports.
> 
> -Stuart-
> 
> 
> Kevin Benton wrote:
> 
> >Yes, I agree.  The challenge is that part of my job is to write software
> to
> >track status so I can determine how much time was spent on fixing a bug.
> It
> >seems to me that the place for that which makes the most sense is in the
> >status field rather than pulling a combination of fields together.
> >
> >
> >
> >>-----Original Message-----
> >>From: developers-owner at bugzilla.org [mailto:developers-
> owner at bugzilla.org]
> >>On Behalf Of Stuart Donaldson
> >>Sent: Thursday, December 09, 2004 5:20 PM
> >>To: developers at bugzilla.org
> >>Subject: Re: Status: Resolved Later
> >>
> >>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.
> >>>
> >>>
> >>>
> >>-
> >>To view or change your list settings, click here:
> >><http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton@amd.com>
> >>
> >>
> >
> >
> >
> >-
> >To view or change your list settings, click here:
> ><http://bugzilla.org/cgi-bin/mj_wwwusr?user=stu@asyn.com>
> >
> >
> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton@amd.com>