Re: priorities brain dump [was Re: bug_squad]

[Luis Villa <louie ximian com>]

BTW, sorry for the cruddy formatting... was experimenting with evo 1.1's
very cool html cut-and-paste and didn't think of what the possible
outcomes were in plain text emails. I'll reformat/resend if anyone wants
me to.

Luis

On Mon, 2002-09-16 at 15:14, Luis Villa wrote:
> So, a braindump, starting from:
> http://bugzilla.gnome.org/bug_status.html#severity
> 
> [Clarifications are in brackets, but the more I look at these the better
> they look to me. Maybe this is something where people need to ask
> questions on this list? Like, 'do you guys think this is high?' and as
> we work that out, we can add comments and thoughts to the formal
> guidelines? I'm not sure- are these specific enough? too vague? They
> work for me, but then again I wrote them :)]
> 
> Priority
>              Immediate
> This bug blocks development or
> testing work and should be fixed
> ASAP, or is a security issue in a
> released version of the software.
> [clarification: basically never
> used; outside of 'real' security
> issues, the biggest issue would be
> 'HEAD X doesn't build because of a
> patch.' 'HEAD doesn't build because
> my development setup is broken' or
> 'HEAD doesn't build because I'm
> trying to build on some completely
> unsupported platform' is /not/
> immediate.]
>                Urgent
> This bug blocks usability of a large
> portion of the product, and really
> should be fixed before the next
> planned release. [Not really used
> much during 2.0 cycle; maybe we want
> to use it to highlight
> 'showstoppers' for the next
> release?]
>                 High
> Seriously broken, but not as high
> impact. Should be fixed before next
> major release. Can include cosmetic
> bugs of particularly high
> visibility, regressions from
> functionality provided in previous
> releases, and more minor bugs that
> are frequently reported. [All
> crashers, at least at first, should
> go here. 'high visibility' in this
> context mainly means nautilus and
> panel- things that every gnome user
> is going to use every day. It also
> includes things that are extremely
> 'unprofessional'- spelling errors,
> for example. A challenge for us
> going forward is how to deal with
> a11y and usability issues in this
> framework; stability and polish are
> long-understood and entrenched
> issues while a11y and usability are
> not.]
>                Normal
> Either a fairly straightforward
> workaround exists or the
> functionality is not very important
> and/or not frequently used. [This
> really needs to be rewritten, since
> it implies that every major bug is
> also high, which just can't be true
> or it makes 'high' useless.
> Suggestions? I'd suggest it just
> means along the lines of 'not
> glaringly important.' That's still
> terribly vague, though.]
>                 Low
> Just not all that important; fix
> when time permits. [mostly
> crack-headed enhancements, but might
> also include, say, bugs against a
> soon-to-be obsoleted module.]
> 
> 
> Severity
> 
>               Blocker
> We should fix and push an update
> immediately. This will mostly be
> used for security fixes. [comment:
> this is misnamed, as
> urgent/immediate are the 'true'
> release blockers, typically. Perhaps
> this should be renamed to 'security'
> or something like that?]
>               Critical
> crashes, loss of data, severe memory
> leak. [comment: basically, only
> crashers. 'Something really big
> breaks' should be major severity and
> high priority. This maybe indicates
> a need to re-name critical to
> crasher, as I've discussed on this
> list before. Thoughts on that?]
>                Major
> A major part of the component is
> nonfunctional. [i.e., menu items or
> buttons don't bring up a window.
> This is very much a judgement call.
> Not as important as priority,
> though, which is what things mostly
> come down to.]
>                Normal
> A minor part of the component is
> nonfunctional.
>                Minor
> The component mostly works, but
> causes some irritation to users. A
> workaround should usually exist.
>               Trivial
> The component works with 100%
> functionality, but has visible typos
> or other cosmetic problems.
>             Enhancement
> Generally a feature request for
> functionality the program doesn't
> already have. These can be useful as
> guides for future product
> improvements.
> 
> 
> On Mon, 2002-09-16 at 12:14, Luis Villa wrote:
> > Ah, nm. Greg ponted out that I misread. Brain dump coming :) [Though,
> > note that Friday's email discusses the bug_squad 'appearance.']
> > Luis
> > 
> > On Mon, 2002-09-16 at 11:49, Luis Villa wrote:
> > > Read your mail from Friday :) Your thoughts on that would be very
> > > welcome, Andrew, since it was your nagging that made me write the email
> > > in the first place :)
> > > Luis
> > > 
> > > On Mon, 2002-09-16 at 11:51, Andrew Sobala wrote:
> > > > A bug_squad keyword seems to have appeared. Is there priority guidance
> > > > and so on yet? (nag, nag, nag.... sorry...)
> > > > 
> > > > -- 
> > > > Andrew
> > > > 
> > > > "Someone needs to make a 'woops' command that reverts the hard disk to
> > > > the state it was in 20 seconds ago."
> > > > 		-- me
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Gnome-bugsquad mailing list
> > > > Gnome-bugsquad gnome org
> > > > http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
> > > > 
> > > _______________________________________________
> > > Gnome-bugsquad mailing list
> > > Gnome-bugsquad gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
> > > 
> > _______________________________________________
> > Gnome-bugsquad mailing list
> > Gnome-bugsquad gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
> > 
> _______________________________________________
> Gnome-bugsquad mailing list
> Gnome-bugsquad gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-bugsquad
>