MozillaZine

Mozilla 1.2.1 Coming Soon

Friday November 29th, 2002

Asa Dotzler writes: "We've discovered a bug in Mozilla 1.2 that can cause DHTML on some sites to fail. We've got a fix and will be releasing a 1.2.1 shortly.

"Also, the 1.2 release tag was not complete so builds created from that tag may have additional problems. If you're building Mozilla you can pull the tip of the branch or wait for the 1.2.1 tag to get the correct files.

"Sorry for the inconvenience."


#19 Re: top-voted bugs

by asa <asa@mozilla.org>

Sunday December 1st, 2002 10:32 AM

You are replying to this message

First, you're wrong about 2 of the most wanted bugs. Your query is too simplistic to actually give the data you want to support your claim. You're looking at current vote totals. That ignores the fact that many now fixed votes don't have all (or even any) of the votes that they once had. Most people don't leave their votes on resolved issues but rather move them to still open ones. If you look at the list of bugs that ever had a lot of votes (but currently might not) then you'll see scores of fixed bugs which (relatively) large numbers of voting people voted for.

Votes aren't ignored but at the same time they're not the deciding factor in what gets fixed. Votes are disproportionately used in feature requests. Should we attempt to move resources to the top voted for feature (because a few hundred people voted for it) and so not fix the top crash in our product (which is impacting tens of thousands of people or more) because it doesn't have a single vote? Should we ignore dataloss in existing features and focus our attention on implementing new features because dataloss bugs don't get a lot of votes and "implement PGP" does?

Not only that but votes don't say as much as you're suggesting about the wants of the end-users. You said "I'm personally not so interested in solving any of these bugs but the community certainly is." That may be correct if by "community" you really mean the few people that vote in Bugzilla. Mozilla had over a million downloads of Mozilla 1.0. That a couple hundred people put a vote on a particular bug or feature request doesn't really say much about the wants of Mozilla end-users. That's what, about 1/50th of 1% of Mozilla 1.0 users that have voiced an opinion. Bugzilla has over 50,000 accounts. Even if you just look at Bugzilla account holders as a representative sample of end-users (I dispute this heavily but for the sake of argument we can discuss it) then you've still got less than 1/2 of 1% of Bugzilla users voting for a particular feature or bugfix (mostly features). These are people that actually registered a Bugzilla account, many of whom commented in or created new bugs and didn't vote for that particular bug. To suggest that "the community" wants something with no more evidence than a couple hundred vocal bugzilla account holders checking a checkbox is a bit simplistic and probably wrong more often than right.

Additionally, there's no mechanism to vote against a pariticular feature and so who is to say that a bug with 200 votes for might not have 300 votes against. Because 200 people said they wanted it is an indication but doesn't necessarily mean that it's wanted by the rest of the Bugzilla or larger Mozilla community. I'd wager that I could file a bug "don't implement PGP" and, given a couple of years and enough highly moderated posts at /. and mozillaZine, get sufficient votes on my bug to get it on your top 20 list. Should we then implement code which makes PGP impossible to implement in Mozilla? I know that's a silly example but for a less silly example imagine I filed a bug "remove Mozilla's HTML Composer program". I'll bet I could get a few hundred votes for that idea pretty easily given all the /. sentiment about bloat. Would that be doing a service to all of the people that use Composer every day?

Even though your query doesn't come close to accurately representing the real state of bugs voted for, and voting is only used by a very vocal minority, is disproportionately asking for new features over bug fixes, doesn't take into account that dissenting votes, and is used so little that it's easy to manipulate with a simple /. or mozillazine campaign, I said above that it's not ignored. And it's not. <drivers@mozilla.org>, who work to build the Mozilla Roadmap and manage checkins during release cycles, are watching votes to see what that extremely vocal and very small group of people want and are taking that into consideration when making some decisions.

Voting is useful. If it was used by more people it might be slightly more useful but no matter how you square it, voting is never going to be clearly representative of what the community wants fixed or implemented in Mozilla. It's just a tiny sliver of opinion coming from an extremly tiny minority. <drivers@mozilla.org> use voting but they also use bug nominations, talkback topcrash data, technical dependencies, developer recommendations, newsgroup and other feedback forums, the needs of contributing organizations like Sun, IBM, Netscape, etc., published reviews and many other sources of input in determining where to move emphasis on the project.

That voting isn't the only mechanism may be a disappointment to you and others but that's gonna continue to be a disappointment because voting is unlikely to be come the sole factor in any decision making in this project for a long, long time. If "Some of [your] enthusiasm for this project is destroyed" because of this, that's a shame but that loss of enthusiasm by a few bug voters is not going to stop the developers from continuing to fix problems and make Mozilla better with every passing day.

--Asa