Re: bugsquad guidelines



My comments (there are other bits other people will probably coment on):

-- I wrote the "make sure you've _read_ the HIG" bit, but on re-reading,
it needs re-wording before being made an official document.
-- s/Cc+=/add yourself to the Cc field/
-- gentoo and LFS: are you _sure_ we can just recklessly close crashers
on these systems? I didn't know that...
-- s/a complete stack trace automatically means it is confirmed/a
complete stack trace means it should be confirmed/
-- crashers: in general, not a good idea to ever NEEDINFO them. NEEDINFO
means that the bug cannot be fixed without further information; the
stack trace is a very useful source of information in most cases.
-- s/String moans/Incorrect strings/
-- slashdot was a joke. Don't really do that, don't really put it in the
guide. Sorry :-) To be honest, bugzilla doesn't normally get moans so
this section is probably not relevant for the guide. (I know I wrote it,
but I was being silly.)
-- 4th comment in Sun/Wipro bit doesn't mean anything. All bug reporters
are held to a high standard. To be honest, I think the first comment
should be lost (I know I wrote it and take full responsibility) because
it could unintentionally cause offence.

If I've contradicted anything I said earlier, sorry, but that's life :-)

On Sun, 2002-11-10 at 22:00, Aschwin van der Woude wrote:
> 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.
> 
> _______________________________________________
> Gnome-bugsquad mailing list
> Gnome-bugsquad gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
> 
-- 
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------




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