There was some discussion on the rhl-devel-list about how we can know how many people want something / don't want something, given that posters to a mailing list are likely to be unrepresentative of the general userbase, for a variety of reasons.
Well, one thing that seemed to work for java.sun.com - as a means of gauging demand - was allowing voting in their bug database. Although the extent to which they actually listen to it is debatable.
I think it "worked" in their case because (a) they had a lot of serious bugs(!) and missing features that people wanted, (b) they have a vast number of users who are also developers and clued-in enough to file a bug report / feature request.
Javasoft use a vote limit of 3 to prevent overvoting (one person having undue influence). That seems a little small, but it certainly forced voters to focus on their 3, or 2, or 1, most important bug(s).
I propose enabling voting for all users in the bug system (Bugzilla or any future replacement thereof). Votes would obviously not be binding, but they could be taken into account at Redhat's discretion.
The ability to vote against a bug/RFE[1] would also be useful to avoid one-sided voting. (This is currently a RFE in bugzilla's own bugzilla at http://bugzilla.mozilla.org/show_bug.cgi?id=48570 .) Voting against a feature would mean "I don't like this"; voting against a bug would mean either "This isn't a bug" or "Too much important stuff which assumes the existence of this bug would break, if this were fixed".
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.
On Sun, 2003-07-27 at 23:45, Robin Green wrote:
There was some discussion on the rhl-devel-list about how we can know how many people want something / don't want something, given that posters to a mailing list are likely to be unrepresentative of the general userbase, for a variety of reasons.
Well, one thing that seemed to work for java.sun.com - as a means of gauging demand - was allowing voting in their bug database. Although the extent to which they actually listen to it is debatable.
I think it "worked" in their case because (a) they had a lot of serious bugs(!) and missing features that people wanted, (b) they have a vast number of users who are also developers and clued-in enough to file a bug report / feature request.
Javasoft use a vote limit of 3 to prevent overvoting (one person having undue influence). That seems a little small, but it certainly forced voters to focus on their 3, or 2, or 1, most important bug(s).
I propose enabling voting for all users in the bug system (Bugzilla or any future replacement thereof). Votes would obviously not be binding, but they could be taken into account at Redhat's discretion.
The ability to vote against a bug/RFE[1] would also be useful to avoid one-sided voting. (This is currently a RFE in bugzilla's own bugzilla at http://bugzilla.mozilla.org/show_bug.cgi?id=48570 .) Voting against a feature would mean "I don't like this"; voting against a bug would mean either "This isn't a bug" or "Too much important stuff which assumes the existence of this bug would break, if this were fixed".
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.
On Mon, Jul 28, 2003 at 04:19:21PM +0100, Robin Green wrote:
- Do a usability study on bugzilla. What could be done to make it
more attractive to intermediate and non-technical users?
You don't have to do a study, bugzilla has such an awful UI even the programmers get confused and waste lots of time with it. ;-)
Of course, problem #1 is "too damn many fields" and everyone loves their field and will whine if you remove it. Voting is another field...
Anyway, I think a total redesign of bugzilla so it even _tried_ to have a reasonable UI would be needed before it'd be worth doing user testing... and we have a giant legacy problem with migrating to something easier.
On the topic of voting: two reasons it's bad:
- it often asks users for implementation advice. what you want from users is root problems and goals; "it's too slow/confusing/hard to do foo," "I want to do bar" - rather than implementation "use package XYZ"/"change behavior in such-and-such way"/"put a button over here"
Some bugs are root problems, but most aren't. Most are really implementation type of issues. So to me bugzilla should mostly be for technical types and developers to discuss the specific changes.
- most bugs that get a lot of votes are just things that someone posted to a discussion board or blog or mailing list and said "spam them!!!!" - as a result, nobody takes the votes seriously.
(happens even now, we get bugs with loads of "me too!<aol/>" comments.)
When it comes down to it, developers are going to use their own judgment on bug priority. They already get an indication of how many people care about a bug because they get duplicate reports, private mail, IRC pestering, and so on.
What I think would be far, far, far more useful than voting would be a bug triage team as Mozilla and GNOME have, so that the good bugs aren't lost in a sea of noise, and so severity and milestone fields are accurate. Right now developers have to do their own bug triage for the most part.
Havoc
Sorry for my poor English.
Mandrake has a strong community. Contrary to RedHat, Mandrake don't know to say "NO" to user requests. This create bugs, usability weak and inconsistency in the Mandrake distribution.
Some times I "hate" the RedHat policy. But the result, the whole distribution, is better (for me) even if they are some functionality missing.
In France RedHat has bad brand image in relation to Mandrake. I don't know exactly why.
In France RedHat distribution have a reputation for being less supporting French than Mandrake. Strange since the RedHat distribution work very well in French and have a better documentation.
The point is that RedHat should more support foreign language and not only in the distribution.
Check http://www.mandrakelinux.com/en/ (search International). Now go to http://www.redhat.com/index2.html and search for some French pages. You will find nothing.
Another example : https://listman.redhat.com/archives/rhl-devel-list/2003-July/msg00006.html
Another example : http://archives.mandrakelinux.com/
Another example : http://www.mandrakelinux.com/fr/9.1/features/ http://www.mandrakelinux.com/en/9.1/features/ http://www.mandrakelinux.com/es/9.1/features/ ...
I don't asking RedHat to do as mush as Mandrake do for foreign language. But it will be beneficial to RedHat to have some web pages in foreign language : - presentation of rhl (about, objective, ...) - *users* mailing-list in foreign language (rhl-fr-list, rhl-es-list, etc)
On July 28, 2003 00:18, 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.
Do we need the opinion of users who are not already able to voice it or do we already know what they'd request?
- Better graphics - More speed - Boot faster - Less text - Ability to download/buy more third-party applications more easily - Games - Better support for such and such piece of hardware
That's the kind of data you'll get when you give voice to non-technical users. While it may become a good idea at some point in the future, Red Hat's bugzilla grows more than it shrinks. Fix more bugs than filled, then give voice to more users to have a bigger bug flow.
OTOH, I think it would be useful to know what bugs are more important than others, and this can be known by enabling voting.