Re: bugsquad guidelines
- From: Aschwin van der Woude <aschwin van der woude creanor com>
- To: "Bugsquad list (gnome)" <gnome-bugsquad gnome org>
- Subject: Re: bugsquad guidelines
- Date: 11 Nov 2002 00:00:43 +0200
Based on Andrew's first draft and your comments, I have created this
next draft:
http://www.linux-aktivaattori.org/twiki/bin/view/Organization/GnomeBugsquadGuideLines
Please comment on it. As soon as we have it in a more complete state we
can drop it into the gnome website somewhere.
-A.
On Sat, 2002-11-02 at 17: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.
>
> The real problem is trying to describe general rules for categories of
> bugs when they all differ :-)
>
> 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. ?
>
> --
> Andrew
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GS/M d--(-) s: a17 C++(+++) UL+ P++ L+++ E--- W+>++ N(-) o? K? w--(---)
> !O M V-
> PS+ PE Y+ PGP+>++++ t@ 5-- X- R tv-@ b++++ DI+++ D>---- G- e- h! r--- y?
> ------END GEEK CODE BLOCK------
> ----
>
> 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?
> ---- Does this make GNOME totally unusable?
> -- 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.
> -- 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.
> -- #FIXME: I18N, L11N: What's the difference?
>
> Crashers
> -- Immediately Critical+High
> -- 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.
>
> 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.
>
> 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.
>
> Bugzilla crack
> -- screenshot keyword is not really used by anyone and can probably be removed...
--
Aschwin van der Woude, Open Source Specialist, Creanor Oy
(www.creanor.com)
Tietokuja 2, fin-00330 Helsinki, IBM-Building
Mobile +358 50 5676665, Tel. +358 9 8567 6400, Fax +358 9 8567 6401
If I have been able to see further, it was only
because I stood on the shoulders of giants.
Sir Isaac Newton
PGP Fingerprint: 55AB 3F70 6C6F C345 A3AC D7A1 F2FF C586 EB04 ABDE
Public key ID: 1024D/EB04ABDE
Keyserver download:
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEB04ABDE
This e-mail is confidential and may contain legally privileged
information. It is intended solely for the addressee(s)and access by
anyone else is unauthorised. Disclosure, copying or distribution, in
whole or part, is strictly prohibited. If you are not the intended
recipient, please notify us immediately by telephone or e-mail and
delete this message and any attachments from your system without
retaining a copy.
E-mail may be subject to data corruption, interception, unauthorised
amendment, tampering and viruses. We only send and receive e-mails on
the basis that we are not liable for any such corruption, interception,
amendment, tampering or viruses or any consequences thereof.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]