priorities brain dump [was Re: bug_squad]

[Luis Villa <louie ximian com>]

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
>