On Fri, 2009-09-18 at 14:28 -0400, Owen Taylor wrote: > 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, while it is indeed an extra click or two to confirm a bug as NEW, is it really that much extra time? Surely most of your time was spent in reading the bug, thinking about it, establishing that it was not a duplicate, and then commenting on it that confirming it is only one extra mouse click. It seems that an UNCONFIRMED bug is likely to move into one of three states: NEW, DUPLICATE or NEEDINFO. Sometimes if the fix is easy, you might fix it immediately and move it to RESOLVED, but in this case the 1yr rule clearly does not apply. Marking bugs also seems to me to be a polite way of telling the reporter that you're aware of her issue and that it does seem to be a legitimate bug (especially in the case of GTK+ or another library, this means that maybe the reporter will stop trying to work out if it's a bug in her code). I know that sometimes you can't be sure about a bug immediately, so you leave it alone. Maybe we need a system that finds all UNCONFIRMED bugs that are 6 months old, or 11 months old and emails a reminder summary to the maintainer. That gives the maintainer an opportunity to confirm the bugs she now knows/suspects to be real. --danni -- Danielle Madeley Collabora Ltd., Melbourne, Australia http://www.collabora.co.uk/ _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list