Re: Danger: older bugs are getting squashed with NEEDINFO



On Thu, 2009-09-17 at 10:32 -0500, C de-Avillez wrote:
> On Sun, 13 Sep 2009 12:24:23 -0400
> Tristan Van Berkom <tristan van berkom gmail com> wrote:
> 
> > Guys,
> >     Im sorry I missed the memo if there was one, I woke up this
> > morning to a full page of bugmail, deleting valid bugs from the
> > buglist and throwing them into a NEEDINFO state.
> > 
> > Javier pointed me to a blog post[0] which describes a new policy
> > to mark bugs as NEEDINFO after one year. I'm raising the flag here
> > on d-d-l because it concerns us all and I think every maintainer
> > needs to know this policy is currently in effect.
> > 
> > I know the guys mean well, and I cannot express my gratitude
> > enough for the efficiency that the bugsquad has for closing
> > some crash bugs that really do need info.
> > 
> > Suffice it to say; I really need to know this policy is going to stop,
> > or at least not effect Glade bugs.
> > 
> 
> All, 
> 
> We had a chat a few ago on #bugs, and we agree this was rather too
> inclusive: as Tristan points out, and others commented, a confirmed
> (i.e., status NEW) bug is no longer under the care of the bugsquad.
> 
> We have just revised the policy to refer exclusively to:
> 
>   * UNCONFIRMED bugs with *no* action in the last year
> 
> We appreciate the feedback, and we would like to keep on having
> more ;-). We invite any interested party to either email us at the
> gnome-bugsquad or to drop by #bugs, voicing their concerns and
> suggestions.

I think for most modules, confirming bugs has usually seemed like a
waste of of the maintainer's time. Confirming bugs assumes that the
maintainer isn't looking at bugs until they are confirmed. Once the
maintainer is already looking at a bug, what's the point of confirming
it? 

So, the confirmation step only makes sense in a module that is getting
lots of NOTABUG and DUPLICATE bugs and where bug triaging will help deal
with that stream.

There are huge numbers of bugs out there with extensively commentary,
patches, etc, that are in the UNCONFIRMED state because the module
maintainers don't care about that distinction.

Would you really propose closing:

https://bugzilla.gnome.org/show_bug.cgi?id=572312

even if there is no activity in the next year just because it's never
been confirmed?

Is it possible on a product-by-product basis to have all bugs go
automatically to the NEW state? And just have the UNCONFIRMED state for
modules where the bugsquad is actively triaging bugs?

Or have the first comment from a developer on a bug automatically mark
it as NEW if no other status change is made?

(Neither helps at all with past history and all the UNCONFIRMED bugs we
have now.)

- Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]