https://fedoraproject.org/wiki/BugZappers/Goals looks a bit crufty. Unless goals have already been set somewhere else, there are several worthy goals I can think of, depending on what the priorities are and how many people-hours are available each week. There doesn't need to be a specific deadline, but on Wikipedia when dealing with these housekeeping queues we often just say "we're focusing effort on X" and then cheer when we finish that part of the job. People having the worst problems: * Zero out the number of NEW bugs from Fedora version 1-8 (handful) * Triage all NEW bugs that are Severity=urgent (104) * Triage all NEW bugs that are Severity=high (605) Cleaning up the "easy" bugs (likely to have been looked at already by the developer) from the end of the queue (by date): * Triage all NEW bugs from 2004, 2005, and 2006 (<50) * Triage all NEW bugs from 2007 (about 400 + 300 merge review) * Etc. * Eventually all bugs should be looked at within no more than _ days, so the system feels responsive and easy problems can be solved in a reasonable period. Catching bugs as they come in: * Triage all the bugs filed within the past 30 days, so that the triage queue never grows. (~2000/month) * Rely on EOL process to deal with bugs at the end of the queue, so eventually we will completely catch up. By the way, There are about 300 bugs from 2007-01-31 with "Merge Review" in the summary, filed against the component "Package Review". I would expect: https://fedoraproject.org/wiki/BugZappers/Special_Procedures to tell triagers what to do about these bugs, but there's no mention. Another thing that could be done is that if there are specific developers that are feeling overwhelmed with bugs, they could request that triagers clean out their components in a focused effort. -B. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list