I’m mostly after the use-case where users can make feature requests and vote on them. I would rather not split my community into two different systems and discourse seems to be a great fit for this.
The way think it could work is to enable voting on a whole discourse category (or sub-category) turning every post in that category into a votable feature. The category view would then sort these topics by votes.
Updated with mockup, 10. January 2016:
I’m looking for a plugin like this as well.
I’m pretty sure the topic list used to have a likes column which was sortable.
If there was an option to switch this back on and then set a default sort order for a category this could provide a quick solution.
The likes column displayed total likes for the topic, not just the OP. So it would only be an approximate.
Better solution imo is to extend the archetype system so this can be done in a plugin (iirc voting is possible by creating a custom archetype, but changing the sorting on these topics isn’t)
The sorting thing is trivial. There are a few less trivial changes needed for this plugin to work.
I would like us to support this level of extensiblity but we don’t have time slotted for it yet.
What you mean by either or both those “custom views”?
From my weak perspective, sorting is all we need. Token isn’t necessarily a good idea.
On a similar note, I’m thinking about using discourse as it is for ticket support (one of the other 2 aspects from uservoice):
I think a token-mechanic is crucial for this.
From my point of view, token differs in 2 things from the current “likening” mechanic:
None of which I see as crucial.
To me, this means simply adding a “like” button beside each topic which would like the first post there. Why would you need to add vote limits and weight there? I understand that’s how uservoice works, but I never saw any point to it. Maybe that’s just me being dumb, though! 
Also, why not “splitting” the community into two different systems, if you can have the same login for them?
Actually, now I think most crucial things would be:
But you could also go with zendesk instead.
just as a data-point for the discourse team: If I could vote for features here, I’d put all my votes on this feature 
But you can already do this. Post in a “feature voting” category, then people like the first post to indicate support, and sort the category by likes via query string. See the “bug” and “feature” home page links that @sam set up here as examples.
@codinghorror is a ‘feature voting’ category a setting or is that just a concept you apply yourself?
I agree with @sam’s initial assessment that this feature requires at least three things:
Without this, this is of limited use.
@pakl, that link does order the bugs by the number of likes. I just added the word “Voted” in front to make that more obvious. (Anyone got suggestions for a better word?)
I’m surprised that this isn’t much of a priority and that you guys seem to be happy with your ‘order by likes’ custom headers. I doubt that this system is very transparent to the average user.
We will get to some of this but for now our biggest priority is billing and onboarding customers which is key to our survival as a company.
We will get to some extensibility stuff for the next release.
makes sense. good to hear and good luck!
A lightweight solution for that would be:
/c/uservoiceclone category.[quote=“sam, post:5, topic:19812”]
Custom view for specific category topic listing
(…)
Custom view for topic[/quote]
Really looking forward to this kind of thing being possible.
Doing it as a plugin will usually be the way to go of course, but in a pinch one could always make a separate app as well. One could point a category to an URL like features.discourse.org which would take users to a stand-alone app built on the Discourse API.
People have done a lot of really cool things with the GitHub API. Among them are completely new interfaces for GitHub Issues, e.g. with a greater focus on project management.
It’d require considerably more work than a plugin, but on the plus side developers can work with the toolbox of their choice, and there are no restrictions whatsoever on layout.
Bumping this topic - we are evaluating using Discourse, and would like to allow each user to have a limited number of votes in a given time period, e.g. 5 votes per day.
Given the price of alternative solutions out there, I’m surprised that there isn’t more interest in this. Surely having a well integrated uservoice/getsatisfaction-like service would be a major selling point for discourse?
Indeed, I’m quite surprised myself that no one has made a bet on this type of (premium) plugin for Discourse yet. Literally hundreds if not thousands of Discourse forums are product-centric, and most of these would benefit from a more formalised platform for feature requests.
I suppose one major detractor for prospective developers is that how to implement it is not abundantly clear. There are different roads you could go down:
Likes could be selectively stylised as “Votes” for a given category.
Problem: “Post likes” and “Feature likes” don’t always overlap well. If a company makes a popular Android app, the first person to type up a 70-character long “Make an iOS port” feature request could quickly garner 1000 Likes. In this case the number of likes does not accurately reflect the quality of the post nor the user’s community participation, which bothers me.
Would allow a more tailored solution, e.g. something that closely mimics UserVoice’s more flexible rating system.
Problem: Yet another points system is added, which can get confusing. There’s also the matter of whether Likes should remain, alongside the custom points system, as a way to acknowledge high quality posts.
Piggyback the same system, but treat them as separate entities, so that votes on features don’t count towards Trust Levels and such. So while the average post can have “Likes”, a special category could allow “Votes" instead. Maybe that’s what @strager had in mind in the first place but I thought it important to point out these subtle but important differences.
Problem: There’s still the issue of “how do I acknowledge a post of high quality?”, but…
In conclusion, I favour the last option, the “Likes archetype”. It is conceptually close to what Discourse users are already familiar with, it shouldn’t be as complicated to do as a completely custom rating system and when it comes to post quality I’ve realised that, as far as boosting your community rep goes, it’s actually kind of cool if the way to play the “feature game” is to make valuable additions to other people’s feature requests, as replies would receive Likes instead of Votes.
Also, it would still allow for some important customisations:
Super Votes
I’ll keep this separate from the rest of the list since this one might not be as straight forward to implement, but I’d love it if users could also have 3 “Super Votes” as a way to differentiate between popular wishlist items and MUST-HAVEs. Both types of votes would count towards the same grand total of “Votes” (so technically the Super Vote is just an ordinary Vote with a special flag attached) but say;
If one feature has 50 Votes and 3 Super Votes, while another feature has 10 votes and 6 Super Votes, that’s interesting data.
Furthermore, only fully registered users (perhaps even limited to a TL, but this could be tweakable per community) get Super Votes, so it could work as an added incentive to participate as a real member of the community.
