Hi, On Wed, 2004-03-03 at 00:55, Jef Spaleta wrote: > How: > Come to the #fedora-bugs channel on the freenode irc network tomorrow > and be a part of the discussion. Instead of writing a very long drawn > out explanation of what you should be doing as a package shepherd. I'll > just point you to an example. > http://www.ottolander.nl/gnome-panel/ > > I think leonardjo created a very useful shepherding tool with this > simple static table. I think people might be able to do a lot of good > taking this static table summary example and reusing it for other > packages in Fedora Core. Hmm, I'm not creating a separate list of bugs outside of bugzilla is such a great idea. It requires a lot of work to keep the two in sync, and it actually tends to be more awkward than just using bugzilla itself. I've tried doing similar things myself in the past, but I always find that the list becomes quickly out of date and I just go back to bugzilla again. Another example is that the GTK+ team currently has a list of "willfix" issues for the 2.4.x release, but they're still finding it more useful to work directly from bugzilla. I think we need to figure out what we're trying to achieve with these shepherding lists and then figure out a way to use bugzilla to effectively achieve those goals. We could start with the following + Give package shepherds bugzilla permissions so they can actually modify bugs. + Come up with a triage guide that explains to shepherds how they should: - Try and reproduce the bug - If its in an older version of the package, identify whether it has been fixed in later versions. - Look for duplicates - Mark bugs as NEEDINFO if there isn't enough information - Track NEEDINFO bugs and re-open if there has been more information reported or close if no more information has been given within a certain time. - Set the bug's priority/severity - Identify if the bug exists upstream and has already been reported there. - Set the right keywords etc. - Work closely with the package maintainer + I think Leonard was also trying to do was figure out which bugs should be fixed in an update to the current release and which bugs should be fixed in Raw Hide. I'm not sure if there's already a way to do it, but it would be good if bugs could be marked in some way as to indicate that. Just some random thoughts .. Good Luck, Mark.