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.
