Re: bugsquad guidelines

[Luis Villa <louie ximian com>]

On Sat, 2002-11-02 at 10:00, Andrew Sobala wrote:
> On Sat, 2002-11-02 at 12:21, Malcolm Tredinnick wrote:
> > I was thinking earlier today that there is enough collected wisdom in
> > the archives of this list that we just about need to write up a document
> > collating it all. So not just common bug-reports stuff, but the various
> > keyword meanings (including bug_squad), etc. We are starting to have a
> > learning curve for the bug busting business.
> > 
> > [And, no, Telsa and Luis and any other funny guys... the correct
> > response is not "well, off you go then". :-) ]
> > 
> 
> In a very real sense it is :-)
> 
> I've attached some quick guidelines I just wrote. They really need
> input, someone to flesh them out so they're readable, corrections, and
> bits that I missed, but as a starting point they're probably OK.

They're a great starting point. I'd love to have someone 'new' to this
flesh them out instead of myself, since I probably make way too many
assumptions about things. But I'll attach my 'commented' version.

> The real problem is trying to describe general rules for categories of
> bugs when they all differ :-)

:) Experience and patience are the only solutions for this problem, I'm
afraid.

> BTW: I've been thinking about "Urgent" priority. Maybe bugs that block
> use of GNOME (eg. login hangs for everyone), or "Panel/Nautilus crashes
> at startup every time" etc. should be urgent. ?

Definitely sounds like what I'd use it for- does this not sound like
something covered under the current definitions?

Anyway, my comments attached. Andrew, Anschwin, David- if one of you
'newcomers' wants to flesh this out a bit, provide some intro/context or
whatever, please, please do- I'll get it up on the site quickly.

Luis

| Luis's comments preceded by |

New bugs
--------

General
-- Always set a GNOVER keyword. If you don't know what version, ask the reporter.
-- If it's GNOVER2.0 and reproducable in 2.1, set both keywords.
-- When triaging, take into account:
---- Visibility
---- How often this feature is used
---- Is this very specific to an uncommon OS feature or setting?

| If it is, make sure to set the OS field.

---- Does this make GNOME totally unusable?

| Additionally, /always/ explain _why_ you've triaged something the way you have. That way if
| people disagree with your triage they can try to point out specific things you may have
| missed or misunderstood. BTW, saying 'I'm not sure- this feels borderline between X and Y
| to me, please feel free to persuade me otherwise' is a very, very acceptable triage comment.

-- Other important keywords: accessibility, usability, keynav (also add accessibility to keynav issues), doc, string (string changes), PATCH (QAs should watch for patches coming into their bugmail and viciously add this keyword), multihead.
-- If you've actually _read_ the HIG, add this keyword to bugs about HIG-violation. If you haven't, don't bother.

| Please don't let usability and HIG get misused- 'I think this feature would be cool' is not
| usability. 

-- All the stuff in b.g.o/triage.cgi
-- If you think it's triaged correctly, add bugsquad. If you are doubtful, Cc+=you, say you've attempted to triage it, and watch for someone else to add bugsquad and what other changes they make. If you add a comment they may even explain why they think what they think.

| If you're doubtful, email bugsquad or ask in IRC- there aren't enough of us going around at
| this time to make 'add a comment and wait for someone else to triage it' a very effective
| strategy.

-- #FIXME: I18N, L11N: What's the difference?

| Kjartan has provided better definitions of these now- are they clear enough to you, Andrew?
| Note that in many cases bugs are both.

Crashers
-- Immediately Critical+High

| There are one or two exceptions to this; the big one is that people using gentoo and LFS
| often create useless stack traces because of the brokenness of their own systems. If you
| see them, close them INVALID.

-- simple-dup-finder.cgi
-- Put crashing function in square brackets in the description if it is a new one
---- This normally involves skipping through g_* and gtk_* and grabbing first application-specific frame
-- I always confirm a bug with a stack trace. Because, for some reason, it really crashed.

| This is absolutely the correct thing to do. Note that most things should be confirmable
| immediately- either as 'new' or as 'needinfo'. 

Feature requests
-- Almost always Enhancement+Normal
-- If it's a fringe usability issue, Cc+=usability-maint gnome org and add a wordy comment like "Thoughts, usability?"

| You might want to be /slightly/ more verbose than that ;) 

Something not working as expected
-- Generally Normal+Normal
-- If it's totally broken, Major+Normal.
-- Would GNOME suck badly if we shipped another version without this? If so, Priority=High.

String moans
-- Trivial, string keyword.

Accessibility issues
-- Are not trivial! Put as Severity=Normal, at least in the general case.

| Or even major, depending. The important thing with accessibility is the keyword, more so
| than the severity/priority, since it often takes more skilled assessment and fixing than we
| can provide.

People moaning about the button order
-- Tell them our designated decision making forum for this is http://slashdot.org. (Some mailing lists may appreciate their input, but most are sick to death of the topic. Usability may be interested if there is a good usability reason other than "I want it to be like Windows/KDE", but otherwise NOTABUG.)

Memory leaks (don't get many of these reported)
-- Should theoretically be Critical+Normal
-- Can be bumped down to Major+Normal in applications that don't get run all the time. So in gnome-search-tool, memory leaks aren't so important, but in gnome-settings-daemon or nautilus they are.

Sun/Wipro
-- Are just like any other bugs - and they often don't search for dups or correctly set priority just like all the other bug reporters
-- Can be Sun-specific. If they are talking about something that sounds totally alien, ask them.
-- Can often be multihead. Remember to set the multihead keyword if they are.

| Note that sun and wipro QA is 'professional'- that means you can hold them to a higher
| standard. :)

Bugzilla crack
-- screenshot keyword is not really used by anyone and can probably be removed...

| It's sort of used by gtk. That said, I've cleaned out some other unused ones.