Every user should have to have the possibility to vote with a special joker for one bug that bothers him the most. This really could help finding the most critical bugs. This joker would be only one vote for the whole Mozilla bugzilla system - only to be used in cases where you can't live without having a bug fixed :) A realization would be: red color for that kind of bugs, and two numbers: total votes, of which ## top priority votes (or similar).

You can already vote for bugs - click on the 'vote for this bug' link, just above teh additional comments box. you can do queries based on number of votes, too.

That's not what this is about. I know the voting system What bothers me is that you have too many votes, which means the weight of your individual vote isn't that strong. So you should have one *special* vote in addition to the oter votes to show which bugs/RFEs you really are interested in. Let me give you an example: Say you vote for 10 bugs in Mailnews, 10 in XPCOM and 3 in Calendar. One of the Calendar bugs is really important for you (let's say it stops your development process) How could the other guy possibly know which bugs you want to have fixed first? Of course I wanna have all of them fixed! Like everybody. But there has to be a way to specify priorities - from the point of the user. As I said - only *one* vote. A precious one. And for the developer one that gives you a lot more information about the severity of a bug. If you don't like the bug the resolution should be 'resolved - wontfix'. Therefore I'm reopening. Sorry for the mess I made.

Couldn't you argue taht a 'special' vote should be worth, say, 10 ordinary votes? In which case, instead of 10 votes + 1 'special' one, you just give them 20 votes? You can vote up to an admin-specified number of votes per bug; its just that bugzilla.mozilla.org has set the maximum number of votes per bug to 1.

Yes, maybe you're right. I'd just like to have the possibility of adding a special flag to the bug that bothers me the most.

Maybe it does not apply to Calendar, but currently you have quite a lot of possibilities to express your special vote for a bug, though all of them are indirect: - Add the nsCatFood keyword (if it's a user-visible problem). Probably nobody will object if you have a convincing explanation. Problem is, there are already quite a lot of nsCatFood bugs. - Nominate them to be fixed for the next milestone if you think they are urgent. Again, people will probably accept it, but there are a lot of nominated bugs. - Provide some data that helps people fixing the bug. Debug it, try to find where the code lives that's causing it, use bonsai to find out who has written it, make sure that the bug is assigned to the right person, when you're stuck, ask a specific question that could help you further etc. etc. But I think you are right that the current voting system can be improved. Before the adding-to-cc mail could be turned off, many people were using the voting feature to say "I'm interested in this bug and want to receive notification, but I don't want to bother other people with spam" (i.e. voting as an implicit bcc list) instead of "this is the one and only bug that really must be fixed asap IMO" which is what you want to express. Maybe the solution is to give voters the ability to prioritize their votes. In full generality, you could introduce a set of voting levels, where for each level one vote is equivalent to a certain amount of "voting points". Currently, b.m.o uses only a single level where one vote is equivalent to one point. If b.m.o were allowing e.g. 3 votes per user, in the current bugzilla system this would mean three levels of votes: level 1 with 1 point, level 2 with 2 points, and level three with three points, so you could either spend one level-3 vote, or one level-2 and one level-3 vote, or three level-1 votes. (In this setting, it would be nice if you had better access to the information how the total number of votes has been built: whether it was built using level-1 votes only, or whether it was built using a few level-3 votes. But if people were paying attention to votes at all, this would not really be a problem, since you would be able to find out this information manually for a given bug, and in theory the many votes do mean something, no matter how the high number is built. So the real issue is that votes are being ignored. Many people have stated that they either "view the voting system on b.m.o as a failed experiment" or that "we are beyond the point where votes matter", so if you want voting to be taken seriously, you'd have to first find out where these opinions come from, and address the roots of the problem. Another setup for multiple levels of votes would be the following: For each level, specify the maximum number of votes, and have a boolean flag indicating whether it can be replaced by a certain number of votes of the next-lower level (and if this flag is on, you need to specify the number, of course). Example: level-3) max. 1 vote; a level-3 vote can *not* be replaced by level-2 votes. level-2) max. 2 votes; a level-2 vote can be replaced by 5 level-1 votes. level-1) max. 7 votes. This would allow you to spend 1 + 2 + 7 votes of the respective levels, or 1 + 1 + 12 votes, or 1 + 0 + 17 votes. While this does not have the full flexibility of the "arbitrary distribution" of votes, it may be clearer for users and developers as to what is really considered important. Your proposal of one "special" vote would fit in this general voting framework as a case with two levels. And now I'm just brainstorming, so please forgive me if this is completely stupid: If each user had a weight factor, with increasing values the more intense/important the involvement with the project is, could this make the voting be taken seriously again? Couldn't even the driver's management process be integrated here, simply by giving drivers a huge weight factor? Here are some completely random examples how the numbers could look like: - Bugzilla account holder: 1 - Testcase author: 1.5 (at least 5 good testcases) - Patch author: 2 (1-2 good patches in different bugs) 3 (3-10 good patches) 4 (more good patches) - Full-time developer: 10 - Driver: 50 Also, something like the "bug karma" idea could be used here; I think jruderman had a (working!) page about this, it's a kind of bugzilla score depending on how many good bugs you files that ended up as fixed, etc. But maybe this idea of introducing inequality among voters is bad? I think one of the reasons that votes are currently being ignored widely is that developers think that even when there are a lot of users' votes for a bug, the developers know better what really needs attention. So the weight factor might help leading these different perspectives together, as well as introducing a new motivation to contribute. But it may also cause grief if a driver draws attention away from some bugs with a single click. (But then that's current reality anyway.)

Another idea would be to allow each user to cast *2* votes for a single bug, with all the other bugs having the normal 1 vote a piece; seems simpler than making special types of votes. Or allow one bug in each category to recieve 2 votes, and one bug out of all categories to receive 3 votes.

Reassigning all of my "future" targetted bugs to indicate that I'm not presently working on them, and someone else could feel free to work on them. (sorry for the spam if you got this twice, it didn't take right the first time)

Whilst this brings in a pleasing degree of subjectivity, it is probably a bad idea overall. One vote = one vote has the advantage of simplicity and transparency. If this were implemented, then casting your magic vote should remove all your other votes. In the example in comment 2 the 10 votes in Mailnews and the 10 votes in XPCOM should be subsumed. See comment 5 which is the right way to go. This should probably be a WONTFIX.

WONTFIX as per above comments. Paul--if you mark a bug WONTFIX, make sure you mention why.

This bug would conflict/compete with the multiple votes concept. Who wins in a situation where a bug has 100,000,000 votes or one joker vote ? It's just simply too far away from reality.

*** Bug 316420 has been marked as a duplicate of this bug. ***