For me it is most important how many bugs are resolved and not market as duplicate, invalid ...

I think that it is actually just as important to weed out all of the dupes and wfms.. this makes it easier for the real bugs to be noticed, and better to have developers seeing the bugs and working on them, than having to trawl through the dupes/invalid/wfm's

4me. You don't seem to understand. This effort isn't about fixing bugs. That's what the developers do. This effort is about wading through the thousands of bugs in the system, most of which are garbage (we have 100,000+ people with Bugzilla accounts so there are tens of thousands of clueless bug reporters) and clearing out the noise and highlighting the real bugs so the developers can focus on what's most important.

Asa, you guys have probably thought of this, but just in case, here's something that crossed my mind today:

As an aid to organizing and directing the effort of increasing numbers of bugday participants (I should show up again one of these days myself), would it be possible to do a systematic recheck of all the old bugs in the system?

You could try breaking up the new bugs into some large fairly arbitrary blocks, for instance by component. There is a long list of components, but only Mail News Front End has more than roughly 600 open bugs, so this makes it easier to see concrete progress. To really make this work, it would be nice to have some way to track this in bugzilla itself, something like how UNCO works for new bugs (but that might not be worth the effort).

There may be quite a few older bugs that aren't easy to invalidate, but this could perhaps be used to generate a new list. Bugs that bugday participants can't verify nor invalidate could form a list that more experienced bug triagers could target. Ideally bugs that are confirmed or reconfirmed by the bugday hunt could also be separately identified.

Well, maybe this is a little complex, and not worth the effort when so many older bugs are probably low risk/reward bugs anyway, but I thought I'd put the idea out there...

Indeed, it'd be nice to have "bug teams" of sorts, whose members work on a specific component. Furthermore, it'd be nice to have a policy for ambiguous bug. E.g., if you've requested feedback from the reporter, and s/he doesn't respond within 3 weeks, it's legitimate to mark the bug as WFM.

There are a number of UNCO mac bugs that have sat forever awaiting reporter feedback. I'm sure that there are even more bugs like this for other platforms. Of course, if the reporter than responded that the bug still occurred with the latest nightly build, we could re-open the bug and go from there.

You should really have all this information "offline" too. By offline, I don't mean "not-online", I mean not given to you by someone in IRC on bugday. I'd really like to help out on bugdays, but I can't do it with your schedule. If there was written down manual of the things you tell people on bugdays, that would help me. (Maybe there already is. If so, just point it out to me.) Thanks.

Pretty much everything we do at BugDay is documented at the getting started with Mozilla QA page. The thing that isn't available outside of BugDay is the personal hand-holding and friendly help for newbies :-)

If you're interested in the specific lists that we've been working from the last few weeks, here's the bug that are probably 'worksforme' and unconfirmed browser-general bug broken down by operating system.

I would love to help sit in on a buy day but I tend not to have the time on Tuedsays :( I would love to see two bug days every week... but I know it cuts into everyones time.

Want to make it 251?
Go and dump bug 72761, this is just not closed since one year.

Udo, reporters have full rights over the bugs they file, IIRC, so you should be able to resolve that yourself. I'll take care of it, though.