Add voting to tickets
Here is my rough idea:
- Voting can be enabled/disabled per project/tracer
- so some projects will have no voting, some projects will have voting, but in some trackers (probably we don't vote in "bugs" tracker)
- Every user can give only one vote per ticket
- so voting will be for registered users only (probably)
- Proposal of voting model:
- Simple: you can vote (+1) or not vote (0)
- 1-5 model: you can select "how much" you vote: 5 = very much, 1 = maybe...
- -1,0,+1 model: you can vote in positive or negative way...
- Each ticket will display voting score (numbers of points) and number of votes (this apply based on exact voting model)
- When Nr. of votes and/of voting score will be added to ticket list's filters, we can list tickets by voting score or number of votes
- Top 10 (5 etc) of most wanted issues can be displayed on homepage of project
What others think?
Updated by David Davis over 15 years ago
Here's something that is 'sort of working for me': change the 'Issue priorities' Enumerations to [..., -1, 0, +1, +2, +3, ...] (as many as you need). This had the side-effect of making the 'priority' more relevant as well.
Then, the task would be to allow a non-manager 'user' to change the priority (explicitly?). Maybe 'voting' is a simple rule: a (non-manager/developer) 'user' can only change the priority, once, by one increment or decrement.
I was just toying with this solution as a workaround tonight, but thought it was interesting to implicitly tie the 'votes' to the 'priority' of an issue. Then the issues that are the 'squeakiest wheels' will automatically get the highest priorities.
Updated by Thomas Lecavelier over 15 years ago
Like the idea and its description.
But that's another layer of cmoplexity: including it would move redmine closer to the bloated status :(
I preach for a plugin/module approach: let redmine admin add features they want to their very redmine, don't put all of them in it.
Updated by Igor Tkachenko over 14 years ago
I think this is a must have thing for every successful product aimed for end user!
On the first stages of product development when user community is small you may just write all users' suggestions to a paper sheet and easily see how many users want certain feature (this feature is wanted by 3 users and other features are wanted by only a one user, ok I'll do the first feature). But when the product community grows it's getting to hardly define what users want more. Without this feature you may think that users want EVERYTHING and RIGHT NOW! Having this feature allows us to plan what improvements we should implement first and what may wait for some time.
Updated by Kamil . about 14 years ago
What is the reason of not integrating this feature into trunk?
The best example is redmine.org itself, where users are voting constatnly still using comments.
If there would be necessity not to have voting - it should be possible to disable it in options.
What do you think?
Updated by Terence Mill about 12 years ago
I am working on a fork with missing features
- per project module which can be switched on/off
- added 3 rights
separated view from hook code, no more inlining
- fix #2 bug for public projects
- establish view_rights for issues vote patch
- provide filters for issue search
Updated by Aidin Abedi about 11 years ago
- Status changed from Closed to Reopened
- % Done changed from 100 to 0
Since the "vote plugin" referenced as reason for closing this issue hasn't been maintained in over 3 years. I strongly urge this feature be reopened and reconsidered as part of redmine core. This is a essential feature, trac even has it as part of there official tracker. This is a must have for any large organisation or public project.
EDIT: also I think all everyone would appreciate this over spamming "+1" for everything.
Updated by Antoine Beaupré over 10 years ago
one way i'd like to see this implemented is by simply displaying the number of watchers on an issue... we already have a voting system builtin, right there. plus it means that people that vote actually are involved in the issue because they receive updates. if they don't want to receive updates, maybe they don't care so much. :)
Updated by Simon Cruise almost 7 years ago
We have always performed prioritisation of issues politically within the business and weight each channel with importance.
For example the sales team will never vote to have a db query optimised.
Priorities are extremely useful to a point but when you have queues with hundreds of items it is nice to have a group voting system to allow this to be taken into account.
The way I would love to see it implemented is that it would be a custom field, essentially an Integer type with vote controls assigned to it. i.e. Format type would be vote.
The default value could always be 0 and the following could be left out :
Min - Max length
Link values to URL
Other than that it could hopefully piggy back off the Integer type logic already in place.
Updated by Konstantin Ladutenko almost 7 years ago
The possible design solution I had created for a duplicated issue Feature #24946 (it has a more detailed description of the feature request, is is actually not a full duplicate of the present issue, as it is about adding voting to the issue list, not to the issue view itself)
Updated by Antoine Beaupré about 5 years ago
Max Johansson wrote:
See, this is beyond irony at this point. This issue is close to receiving about a hundred +1 comments, most of which are unnecessary noise for probably even more watchers that have been waiting for this issue to be fixed for over a decade now.
It's simply a matter of showing the number of watchers on an issue. How hard can that possibly be? :)
That said, I'm not using Redmine anymore, and so I will bid my fellow watchers farewellm, unwatch this issue and apologize for this final, ultimate mike drop: