Re: bugsquad guidelines
- From: Aschwin van der Woude <aschwin van der woude creanor com>
- To: Andrew Sobala <andrew sobala net>
- Cc: Malcolm Tredinnick <malcolm commsecure com au>, "Bugsquad list (gnome)" <gnome-bugsquad gnome org>
- Subject: Re: bugsquad guidelines
- Date: 02 Nov 2002 17:34:40 +0200
> 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]