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

Re: Draft email to maintainers regarding Priority / Severity in Bugzilla

On Mon, 2009-04-20 at 09:01 +0800, John Summerfield wrote:
> Adam Williamson wrote:
> > 
> > At present, the status is that these are more or less ignored by
> > Bugzappers and most maintainers; some maintainers use and set them for
> > their own packages according to their own system. The reason for their
> > neglect, as I see it, is that there's been no convention for their use,
> > and no overall responsibility in setting them - they're usually set
> > arbitrarily by reporters, and thus convey no useful information.
> This is offensive. I am one such user.
> I set fields as thoughtfully as I'm able, given the lack of guidelines. 
> I've mentioned my thoughts on reasonable values and meanings here before.

As I mentioned, I didn't want to go into this topic in too much depth in
the mail to developers because it's irrelevant, and it's never a good
idea to have meat in a mail that can fuel a debate you really don't want
to get started.

The fact that there are no agreed definitions of what these fields
actually means is enough to make them useless. No matter how
thoughtfully you set them, at present, they are not doing anything - you
wasted your time. This isn't your fault, it's just the way things are at
present :)

> I'm the only person able to assess the importance of a bug _to me._ If a 
> bug in any package, no matter how unimportant it might seem to some 
> triager, prevents my use of a computer, then that bug is critically 
> important to me.

Here's the news: how important it is to you doesn't matter. That's
oversimplifying, but that's the meat. What matters is how important it
is to the project.

Obviously, how important it is to you feeds into that, but that's the
correct status of "how important is this bug to the individual person
who reported it": it's *one* of the components that goes into evaluating
the importance of the bug as far as the project (and hence the
maintainer) is concerned, not the *only* one. A crasher bug which
affects only people in Poland running with Turkish locales while facing
the moon and howling on alternate Wednesdays is, of course, very
important to people in Poland running with Turkish locales while facing
the moon and howling on alternate Wednesdays, but is not as important to
the project as a crasher bug which affects everyone. The
severity/priority fields in Bugzilla evaluate the importance of the bug
as far as the project is concerned, not the importance of the bug as far
as the reporter is concerned. This is the right way to do things.

Bugzilla is a tool whose function is improving the efficiency of
development of software. It is not there to massage the ego of those who
submit reports to it. Take a step back, and you'll realize this. If
there was a bug tracker where a team of hundreds of helpful people
helped you file a superb report which encapsulated all your problems in
perfect, minute detail, and categorized them in every way according to
your own exact desires and evaluations - and then nothing else happened,
because no developer ever saw any of the bugs - its value would be
precisely zero. Should that make you happy? No, it shouldn't.

> Xen proved not to work satisfactorily, and I spent more time fighting 
> with it than enjoying it.
> Over time, xen dropped from supported Fedora, and KVM appeared. Sadly, 
> KVM does not work reliably either.
> For me, those are critical problems. Today, the best solution I have is 
> to run Windows XP on that computer, even though Windows doesn't use all 
> the RAM.
> A triager might assess problems with those packages as relatively 
> unimportant "because 90% of people don't use those."

This would not be the case. At least one of the two fields will
definitely be used, in the proposal, to evaluate the importance of the
issue solely in terms of the component in which the issue actually
occurs. A bug that stopped KVM from working entirely would of course be
a critical bug in the context of KVM.

> Another example.
> I am one who does not like KDE 4.0. At least, 4.0. I haven't had a 
> decent chance to play with newer KDE. I've used KDE for years, since 1.x 
> and GNOME was a contender in my affections, ruled out because of its 
> lack of reliability. Recent GNOME's reliability is fine, though it has 
> some annoyances (where's klipper? Heck, I had something of the kind on 
> OS/2), but basically it gets the job done. So does XFCE, and both are 
> workable alternatives. From the package perspective, KDE's new design 
> (IMV) is a serious problem, and I don't normally use it, but it doesn't 
> prevent my use of the computer, and I don't care _that_ much about it.

This is far beyond the scope of any kind of triage, and hence irrelevant
to this proposal.

> In return, triagers (and maintainers for that matter) should accept that
> . Some users know more than they do
> . Some bugs are in design. "That's how it's documented to work" isn't 
> always the right answer.

This is a call for developers to make, not triagers. Unless the triager
already knows from previous developer feedback, a triager should not
make the decision to close a bug because 'that's how it's supposed to
be' - it will be passed on to the developer. If a developer closes a bug
in this fashion, future discussion should be directed to the appropriate
mailing list (or other discussion forum for the project in question),
because it's beyond the scope of Bugzilla.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org

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