Status: Resolved Later

[Stuart Donaldson]

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