Hi Asa, thanks for the reply....
Asa Dotzler wrote:
> It is very underused making the wishes of a couple of people look much
> more important than they probably should be. We have 15,000 active
> Bugzilla accounts and the most voted for bug has like 150 votes!!!
Low "voter turnout" is a problem. However, this doesn't mean that you
should ignore the votes. As I said, it needs front-page visibility. Heck
it's not even listed under "get involved"! My prediction is that if you
advertised voting a bit more, you'd get input from people other than the
"most vocal" ones--a lot of people who might otherwise lurk on the
newsgroups or not read them at all.
Plus it will help get non-developer users using bugzilla and will help
prevent duplicate submissions and posts to the newsgroups.
How else are you going to get feedback from users? Sure, talkback will
tell you which bugs cause crashes, but how are you going to know which
bugs cause the most annoyance for users? Or which enhancements they want
to see the most?
> If
> 1% of the active Bugzilla users (there are actually 32,000 total
> accounts which makes it less than 1% if you count lurkers) think that an
> annoying bug or a request for a new feature is important, we should stop
> fixing crashers and dataloss bugs and jump right on that popular bug
> because it has more votes?
No. I didn't say that. Obviously the developers have visibility and
understanding that users don't, and are aware of internal bugs that may
not make it to the user level. Votes should be a factor in the decision
process. How important a factor is up to you.
> What if it is a request for a feature that
> would take significant enginering resources away from existing buggy
> features. I never see anyone voting for the "mail crashes on startup"
> bugs but there are 150 votes for a request to implement the mail PGP
> plugin.
You can bet that if I had a problem with crashing on startup, I would
have voted for it to be fixed. If a crash bug affects 5% of users,
should it get more importance than a UI bug or enhancement that affects
95% of users? I doubt it. A great way to get that kind of data--the
pulse of the users--is through voting.
If we define "best" as "the one that makes the most people happy the
most amount of the time", then votes are the currency to express this.
Giving the users the ability to help steer the project (tempered by the
expert opinions of the developers) will guarantee that "best" will
eventually be achieved.
[Expert opinions are necessary because we don't want the "McDonald's" of
browsers. Neither do we want to marginalize minorities (e.g. Linux).]
> note: I upped the number of votes from 3 to 10 in Browser and MailNews a
> while ago to see if it encouraged participation. Not much changed.
Great idea. But advertise! Tell people it's an easy way for them to help
even if they can't code or document! (I'm bcc'ing this to
[EMAIL PROTECTED])
>> My followup questions was "Isn't the voting scheme the only way you
>> have of finding out what the customer wants to see implemented?" She
>> misunderstood my question and thought that I was asking what the
>> engineers were interested in seeing implemented.
[snip]
> Mozilla Milestones are downlaoded by a much larger audience than the
> 15000 bugzilla account holders (I think recent numbers are over 100,000
> downloads per milestone) and even if all of those people got bugzilla
> accounts and voted for bugs we'd still have a pretty small sample of
> "typical end users (Netscape's, IBM's or Beonex's customers) weighted
> heavily in the "open source power user" class (if there is such a thing).
How about adding a link to the talkback window sending people to
bugzilla so they can vote? Sure they'll probably vote for the crash that
just happened, but it may get them involved in other votes as well.
>> First of all, I'm sure that the developers already have good ideas of
>> where they think they're effort should be expended. However, it seems
>> to me that without direct input from the users, there's a good chance
>> that something may be missed.
>
> mozilla.org's customers (Beonex, OEone, RedHat, Netscape, those folks)
> have their own mechanisms for gathering feedback from their audiences.
> For example, Netscape does preview releases and actual releases and
> gathers feedback from those beta users and customers. We don't let them
> send those hudreds of thousands or millions (I don't know what those
> numbers are) of people to Bugzilla. They gather feedback directly
> from
> their users and that feedback is distilled into bug reports/feature
> requests which are filed and hopefully fixed in Bugzilla.
Interesting. I didn't know that scale was a problem.
>> So here's my proposal: hype the bug voting some! Stick it on the main
>> mozilla page along side the bugzilla link. And integrate number of
>> votes in along with the talkback crash data, or at least keep a link
>> to the search page with the highest voted bugs/features.
>
> What do you mean "integrate number of votes in along with the talkback
> crash data"? Integrate it into what?
Originally I meant integrate it into your consideration, but I see you
do that already. The impression I got at the conference was that it was
being ignored (maybe you're the exception to the rule?).
>> FWIW, here's my vote list so far:
>>
>> #13474: External filters/editors for textareas. This would allow you
>> to use your favorite editor when composing mail, e.g.
>> #18808: Spawned windows should inherit parent window's history
>> #28792: Need a "publish" command for the editor
>> #75371: Add a user interface for the popup windows preferences (and
>> other javascript stuff)
>> #88810: Remove code that unnecessarily focuses/raises windows
>> #11459: mailto: can launch external mail app or launch an url
>> #18266 Query IMAP folders other than INBOX for new msgs
>> #18729 [FEATURE] Windows integration for new mail notification
>> #22994 Mail reader allows spammers to set cookies to track web usage
>> #43278 Crossposts (same Message-ID) not marked as read in other groups
>> #72761 Send unsent messages fails if no folder of the account is open
>> #72791 if Inbox is Sent folder, show Senders not Recipients
>> #91052 [RFE] Notify me when someone follows up to my newsgroup message
>> (sound/alert/whatever)
>
> I see that the majority of your votes are not on bugs but rather new
> feature requests. Should developers stop fixing bugs in existing
> features and start implementing your new features? Should we hold off
> on declaring some Milestone until those features are implemented and bug
> free? What is it that you want us to do differently with that list now
> that it has your vote on it?
Again, I never said to stop working on bugs. I don't vote for bugs
simply because I haven't seen very many. Plus, I figured that when
features do get implemented, my input might help decide which get chosen.
Here's a thought: why not have all the developers vote also? Give their
votes more weight... Maybe make the total number of votes across all
developers equal to the total number of votes across all non-developers.
Then you can say that users get 1/2 influence on which bugs/features get
worked on, and developers get 1/2 influence as well. You could also do a
similar thing with the corporate customers.
In projects that I've worked on, we tackle high-importance items first,
and judge the importance based on direct feedback from users. Only
rarely do we preempt the users with our own priorities. That way we
always make sure that we're working toward the "best" system.
Regards,
David
