GNOME Bugzilla – Bug 629161
Support voting in GNOME Bugzilla
Last modified: 2015-02-11 02:45:31 UTC
Other issue trackers on the next provide abilities for userbase rating of bug reports. This is useful for developers to judge directions of development efforts. Here's some motivation background: http://blogs.gnome.org/timj/2010/09/09/09-09-2010-request-to-support-voting-in-gnome-bugzilla/trackback/
Dup of bug 390454.
Yupp. *** This bug has been marked as a duplicate of bug 390454 ***
(In reply to comment #2) > Yupp. > > *** This bug has been marked as a duplicate of bug 390454 *** André, please leave this bug open, just because it has been closed in the past as WONTFIX doesn't mean the request is invalid forever. At the very least, we can have some discussions going here, before a decision is made.
I agree with Tim and would like to second this request. It should probably be noted that a high number of votes doesn't guarantee anything, however, as a maintainer the number of affected/interested users is a very interesting data point when ordering your todo list. If the majority of maintainers wants to keep voting disabled, would it be possible to enable it on only certain bugzilla products? A possible solution to the issue of users expecting (quick) results when the bug has many votes might be to show the number of votes only to the product maintainer. So users can vote but not see whether this is a popular bug.
Google's star approach is nice because the user does not see how many other folks starred the issue (or if they do, it's not nearly as visible as something like "votes"). Since users don't see "one million votes OMG", there are less issues with managing user expectations. Of course, it would be helpful for developers of a bugzilla product to see the total number of users that have "starred" the bug.
Whoops, didn't see Jürg's comment, sorry for the repetitive noise!
I would vote for this if I could. And I also agree with Jürg and Sandy's points. It's important that users understand that voting for a bug is a request, not a guarantee, and the point about only showing vote totals to maintainers seems like it should make this feature feasible.
(In reply to comment #4) > If the majority of maintainers wants to keep voting disabled, would it be > possible to enable it on only certain bugzilla products? "Votes Per User" and "Maximum Votes Per Bug" settings are on a per-product base. It might be confusing to users if they can vote only on a few products as there is no "Voting disabled for this product" placeholder for all the other products (might be worth an upstream Bugzilla ticket maybe). (In reply to comment #5) > Google's star approach is nice because the user does not see how many other > folks starred the issue Feel free to file an upstream request in bugzilla.mozilla.org. In general from my experience in bugs.maemo.org enabling voting adds to "This has been filed in October 1986 and is still not fixed?! You don't care!!" the variant "This has already 2.7 votes and is still not fixed?! You don't care!!". But I don't really maintain any projects so my point of view is biased.
I'd be ok if I can search by number of CC: , but currently is not possible. There is a bug upstream about this: https://bugzilla.mozilla.org/show_bug.cgi?id=62718
I have mixed feelings about that, as users seeing a high number of votes on one issue are a bit disapointed to see it's not fixed. So I think that not having votes or showing votes only to the maintainer are good options. But I'd suggest instead of votes, to use a "me too" approach. Instead of a vote, one just could tell that he's affected by a particular bug. This would prevent people from adding useless comments (better signal/noise ratio), and show approximately to the maintainer how many users are affected. Marking a bug as duplicate would also group the "me too" on the original bug. It may also be interesting to connect this system to other bugtrackers so that pepole that voted for this bug on their distro-specific bugtracker are counted.
(In reply to comment #10) > But I'd suggest instead of votes, to use a "me too" approach. That sounds similar to Launchpad's "This affects me too" option, but in general this should be done (and discussed) upstream in Mozilla Bugzilla. Feel free to file a ticket there.
The argument that users will be disappointed that bugs with high numbers of votes are not being fixed has been raised here, and also previously on Bug 390454. My counter-argument to this is: so what? Every other bug tracker I use (KDE, Novell, SeaMonkey, OpenOffice.org, MediaWiki) allows users to both make and view votes. Yes, occasionally some users complain that bugs haven't been fixed. No, this hasn't resulted in planes falling out of the sky, all development work ceasing, etc. Such unhelpful comments are thankfully rare, and either get ignored, or else someone politely reminds the poster of bug tracker and free software development etiquette. I find the ability to both make and view votes to be extremely useful. It allows me to: 1) Keep track of those bugs which I'm interested in, along with a numerical score indicating the importance I assign to them. I can do this without adding myself to the CC list of the bug. By looking at my votes page, I get a nicely sorted list of all these bugs and can see at a glance whether they've been resolved. 2) See at a glance what the most hated bugs and most requested features are for a given project. This is useful to users if they're considering using the software and want to first see what sort of issues other users are experiencing. It's also useful to developers when prioritizing their work. 3) Help find duplicates before submitting my own bug report. Sometimes a simple keyword search doesn't turn up duplicates, or returns far too many results. Being able to order search results by number of votes often turns up issues which have been experienced by a large number of users, and are thus likely to be duplicates of the bug I'm thinking of reporting. This saves both me and the developers time.
I support enabling Buzilla's voting feature. The "me too" method is not only annoying (if you get e-mailed for every one), but you can't search/sort on it. Any method of tracking the popularity of a bug (# CC'd, # comments, # votes) is nearly useless without being able to sort bug searches on it. The main advantage of using voting vs those others (or making some new one) is it's already implemented upstream as a sortable column.
To my knowledge, launchpad doesn't support sorting by affected users. I would prefer to be able to add myself to the CC:-list without leaving a comment. Additionaly one should be able to sort by the number of CC:'d users, as proposed in https://bugzilla.mozilla.org/show_bug.cgi?id=62718 (Javier mentioned it). Too bad, nothing happened to that bug since Javier commented on it...
(In reply to comment #19) > I would prefer to be able to add myself to the CC:-list without leaving a > comment. This is up to the recipient in Bugzilla via https://bugzilla.gnome.org/userprefs.cgi?tab=email under "The CC field changes".
Keeping this ticket open while nothing will happen means de facto WONTFIX so I'm going to close this ticket to reflect reality and afterwards somebody might reopen this as a sign of protest or disagreement but then again nothing will happen again in reality and there's just another ticket that clutters the list of open tickets so maintainers start avoiding using bug trackers for actual planning because they cannot get a correct and proper list of tickets anymore that they actually do plan to work on or would accept / support to get fixed. Alright then. If folks are after measuring popularity of certain requests, I see number of CC subscribers, comments added, votes, and duplicates as theoretical criteria. That requires a non-broken upstream implementation first though and not an obscure confusing hard-to-detect "voting" UI with uninterpretable metrics. *** This bug has been marked as a duplicate of bug 390454 ***