A couple of changes to note

[Gaetan Nadon]

Hi,

Can you explain how this policy fits/integrates with the
https://help.launchpad.net/BugExpiry automated process which "expires"
bug reports after 60 days when some conditions are met?

==========================================================
Launchpad will mark bugs as candidates for expiry if it appears that
they have been abandoned. To determine if a bug has been abandoned,
Launchpad uses the following conditions: 


      * it has the "Incomplete" status 
      * the last update was more than 60 days ago 
      * it is not marked as a duplicate of another bug (duplicate bugs
        have no status of their own and so aren't expirable). 
      * it has not been assigned to anyone 
      * it is not targeted to a milestone. 


Only projects and distributions that use Launchpad as their bug tracker
and that have not disabled bug expiry are part of the bug expiration
process. 
============================================================

For example,
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/85796 was marked
for expiry yesterday, however there is no observable change to the bug
report I can detect. How does one list "expired" bug reports?

Thanks

On Wed, 2009-03-04 at 06:53 -0500, Mackenzie Morgan wrote:

> On Wednesday 04 March 2009 5:26:35 am Wolfger wrote: 
> > Speaking as somebody who does a lot of invalidating of old bugs, I
> > have to say that responses from the submitter are the exception, not
> > the rule. Maybe (and I'm being generous) 10% of these bugs see life
> > again. So this (proposed?) change only adds to the work load without
> > providing any extra value. Under the 4-weeks-to-dead system, a triager
> > only touches the bug once, and if the bug is still alive, the
> > submitter touches the bug once. Under this new system, triagers will
> > have to touch the bug twice if they are dead (don't play with dead
> > bugs!), but the process for it's-not-dead-yet bugs hasn't actually
> > changed at all.
> 
> Leaving a bug which has not had a response alone, in incomplete-without-
> response mode does not hurt anything.  They don't *need* to be closed. 
> Prompting the user to supply more of the needed input can be good.  Going 
> through the list of bugs last touched 28 days ago and killing them makes 
> reporters feel ignored. The bugs aren't dead til you invalidate them.  Someone 
> that can reproduce it can supply the needed input.  Once you invalidate, it 
> goes off everyone's radar and stops showing up in bug searches, so people who 
> can reproduce have to go through submitting a whole new bug when they could've 
> just added the one missing piece of information to the original. 
> 
> Triaging's not about closing as many bugs as possible.  It's about improving 
> bug reports.  You could say "resolving" bugs, but "nevermind we don't want to 
> deal with you because you're not prompt enough" isn't really a resolution.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20090304/0ea5a0e7/attachment.htm