Reminder: Bug Triage Meeting Tomorrow (Tuesday) @ 15:00 UTC

Christopher Beland beland at alum.mit.edu
Tue Feb 24 03:49:14 UTC 2009


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.





More information about the fedora-test-list mailing list