Bug voting? (in Bugzilla or whatever)

[Robin Green]

Good point; also, even a lot of technical users will not join mailing
lists or do something else which takes a perceived lot of time (which
might include using buzilla over dialup).

So, some more ideas for broadening input:

1) Do a usability study on bugzilla. What could be done to make it
more attractive to intermediate and non-technical users? Whatever
software is used as the primary means for tracking and reporting
issues from an end-user point of view - and currently that's Bugzilla
- acts as a choke point. Potentially, if you get more and better
feedback here, that yields benefits accross the whole distro.

2) Some way of voting which includes not just indecipherable specific
issues like "Crash in nsPointerMunge at 0x4385869" but non-technical
general issues like "Make gaim less prone to crashing" or "Make
GNOME/KDE mingling less confusing". (These could then act as "bug
groups" for specific bugs.) The bug database is geared towards
reproducing and fixing specific bugs. For voting we need a way of
including those who don't have the time and/or proficiency to find or
report bugs accurately enough.

3) On the website and in newsletters, promote more user participation
(More user participation IS, after all, meant to be what the new RHL
Project is about, no?) Run a web forum, maybe.

4) Encourage people who install for other people or organisations,
such as: 
 - LUGers installing for friends
 - IT contractors installing for other organisations
 - IT departments
to talk more with users a few weeks down the line and get more
feedback on package installation, bugs, features. (Bearing in mind
that (a) RHL developers work not only on the "RH-specific" code like
rpm and anaconda but also on upstream packages, and (b) it doesn't
matter very much whether it's an issue that should be handled by
upstream developers or by the RHL maintainers - either way, if you
have a defect which is causing people a lot of pain, that's still
worth knowing and following up on.)

5) For those who will rarely be reached by internet means (e.g.
those who try Red Hat and quickly choose not to use it), traditional
market research.

I understand that Red Hat may be more interested in some types of
users than others; however, the young newbie student of today just
trying out Red Hat may be in an IT decision-making position tommorow.
Making newbies feel welcome and feel that their input is listened to
- and not over-hastily dismissed - is an important PR win. The
opposite extreme - explicitly telling newbies they are not welcome
- would certainly be bad news for a distro like RH, if RH wants to
retain its position as #1 (is it?) Linux distro in North America. In
this dominant position, third parties - especially commercial
software producers - will tend to focus more effort on targeting RHL
than on other, less popular distros. And RH is more likely to be
chosen by enterprise customers if it retains its popularity and good
reputation. (I'm sure that RH is well aware of the arguments in this
paragraph, I'm just saying it for the benefit of others on the list.)

Lastly, it must be said that many non-technical users don't contribute
generally to GNU/Linux issue reporting simply because they are quite
satisfied with GNU/Linux for their needs and don't have very much to
complain about. For those who do have something to complain about,
they may well be intimidated from doing so, and that's something that
needs to be addressed.

It's also a cultural issue. I have had problems setting up printing
on Redhat 7.3 (+ unofficial KDE+cups packages) and vanilla Redhat 9.
(UI note: When there is a problem preparing the data for printing,
there should be some kind of error dialog popping up, damnit! However,
there often isn't.) I, as a proficient developer, am intimidated
from consulting community resources, because I fear that instead of
people going out of their way to help, I will encounter:

- pages filled with jargon that are partially indecipherable to me
- flaming for not providing useful information to diagnose the problem
(but I found it hard to find any useful information!)
- flaming for not being a total guru expert and making a silly mistake
  - special case: flaming for "blaming the developer" when it is actually
  (unbenownst to me) "the hardware manufacturor's fault"
- comments like "Could be a redhat specific issue. Build from source
and then we'll talk."
- flaming for having the cheek to complain about a bug, instead of
"fixing it myself". (Note: On bugzilla.mozilla.org you are supposed
to vote for a bug instead of complaining about it; however, on
bugzilla.redhat.com you can't even do that because you can't vote!)
- no response

and other turn-offs. As I said, I'm an experienced developer and I
know my way around large parts of the distro. For newbies it will be
worse. These are real turn-offs in the real world; I am not making
a mountain out of a molehill here.

Most people only have a limited amount of time to spare on wrangling
with bugs, and if those who offer "help" are going to require the user
to spend large chunks of time reading/downloading/compiling - which
may actually be unnecessary in some cases - the user may well simply
give up.

-- 
Robin

On Mon, Jul 28, 2003 at 12:18:16AM -0400, Sean Middleditch wrote:
> This does nothing to avoid the problem: only technical users bother with
> the bug database, or mailing lists, or irc, or whatever.  Adding voting
> to the bug database is just giving more voice to the people who already
> have it, and not do anything for the people who don't.