yo, party people- new keyword?

[Luis Villa <louie ximian com>]

Hey, guys, gals...
	So, I've been thinking a bit on us, and what Andrew said in specific,
and I think he's clearly right- we need a keyword to track what we're
doing, and avoid stomping on each other's toes. So, here is my tentative
plan: I hope it sounds good to people and I hope people start executing
it, like, right away. Or if not executing, calling me an idiot;
hopefully that way we can get together a plan that makes sense and
/then/ start acting on it. :)

*for starters, let's use 'bug_squad' as our keyword. It's clear, simple,
doesn't imply too much, and most likely won't be used accidentally by
anyone else. And we can always nuke it and merge it or replace it with
another keyword later if we decide something else will work better.
[Like, say, we do well enough to merge with triage without substantially
changing the quality level currently implied by triaged.]

The Who/What/Why of the bug_squad keyword:

*who: I'd like, for now, that this be restricted to people who've closed
or NEEDNFOd roughly 100 bugs. This doesn't necessarily show that you
know how to do triage, just that you've got patience and too much time
on your hands. ;) I was going to post a list, but I figure that it'll be
much better to just trust the judgement of the people on this list, and
keep an eye on who is using the keyword myself.

*What bugs should you put bug_squad on? Basically, bugs that you've
assessed. That means setting priority, severity, and at least the
GNOME2/GNOME1.4 keyword. Obviously, priority is a fine art and not a
science- so discuss priority with maintainers, on this list, and on
#bugs anything you feel uncertain about. I expect and hope that people
will talk about bugs- bugzilla got consistent because I worked hard at
it, and when we split up the task among many people it's going to
require communication to make sure we're all on the same page.
Especially when in doubt, /explain/ why you think it is high priority.
Assessment of a bug is /not/ your chance to lobby for your pet cause-
I'll be extremely unhappy with anyone who does that. It's your chance to
think big picture and think about where GNOME is going in terms of
quality.

*What do you need to do first before changing priority on a single bug?
Talk to the maintainers, tell them what you're doing, and how it is
going to help them, and ask them if there is anything they should know.
I'm going to email desktop-devel about this FIXME, but that only goes so
far. For this to work, you all need to build a rapport with maintainers.
They have to trust your judgement. If they don't, they'll ignore your
triage, redo it all themselves, and you'll have wasted your hard work.
I'm going to tell the maintainers that I trust all of you. Please don't
make me look stupid when I do that :)

*What else?[1] Don't be sloppy, don't spam maintainers, possibly worst
of all-don't lobby for your pet projects. All of those are sure ways to
have maintainers come back to me saying 'who are these people- please
tell them to stay away from my code.' It's happened before, and I don't
want it to happen again. GNOME can't function that way- but at least
some maintainers will be stubborn enough to try if they don't trust us.
Trust me on that one ;)

*So, um, why? We've already discussed this a bit- I won't be here
forever. More immediately, I also won't be on the continent for two
weeks starting Wednesday, and I think that'll be a good chance for
everyone involved to work without my interference and see how that goes.

Other notes, some related to bug_squad, others not:

*I'll work up (hopefully tonight, if not, Saturday) a very, very
rudimentary product chart showing the percentage of open bugs that have
been bug_squad'd. Ideally, this will also show what products have
'assigned' triage folks. 
*Hopefully, I'll also post some more details about my rules of thumb for
priority and severity so that we're all close to being on the same page
about that.
*http://bugzilla.gnome.org/simple-dup-finder.cgi is back up and much
improved- it should robustly find all traces now, and mostly filter most
crap. It still isn't very intelligent about what it does after that,
though :)
*I'm sort of curious what everyone thinks about doing things
mozilla-style and forcing nearly all bugs to start unconfirmed, and then
using NEW instead of a keyword.
*I think this might be a great help to bug-days- I can easily see having
a query of 'bugs in product X without the bug_squad keyword' for a
product X bug day, and quickly tearing through all of them, setting the
keyword and verifying that the bugs are still there. Thanks for that
suggestion, whoever that was :).

Anyway... sorry this took so long, I hope it answers more questions than
it creates :)

Luis

[1]Yeah, ok, what was a pretty weak 'what'. So sue me. :)