Re: bugsquad guidelines



> 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.

It looks pretty good already. I learned something from it. :-)
I am missing something I learned the last few days at irc. (I started
helping out on Thursday). 
I have understood 'fixme' bugs are considered 'minor'. Perhaps we could
have the general solution for this type as I suggested in another email:

 - Check if the fixme is still in the code
 - mark it minor
 - mark it GNOME2 or GNOME2.1.x
 - mark it bug_squad
 - check if it is in the right category 

I also have some remarks about your draft:

> 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

Visibility for the user

> ---- How often this feature is used

How often this features might be used

> ---- Is this very specific to an uncommon OS feature or setting?
Is this needing a specific or uncommon OS feature or setting?

> ---- Does this make GNOME totally unusable?

<joking> Does it make people run away screaming to the KDE
camp?</joking>

> -- 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.

Lets make this a list like above, one on a line.

> -- If you've actually _read_ the HIG, add this keyword to bugs about HIG-violation. If you haven't, don't bother.
> -- All the stuff in b.g.o/triage.cgi

Should we list some of it here too.

> -- 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.

Great advice! :-)

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

Probably not too much from a bug-squad point of view

> Crashers
> -- Immediately Critical+High
> -- simple-dup-finder.cgi
> -- Put crashing function in square brackets in the description if it is a new one

Perhaps we should explain how to find this function in the stack-trace.

> ---- 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.

Makes sense!

> 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?"
> 
> 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.

Again we should use the 'running and screaming'-test. ;-)

> 
> String moans
> -- Trivial, string keyword.
> 
> Accessibility issues
> -- Are not trivial! Put as Severity=Normal, at least in the general case.
> 
> 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.

Great start!

Where do we dump this document on the gnome-website?

-A.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]