[quote=“joebuhlig, post:20, topic:38772”]
is there a custom field option available on the Topic-User relationship?
[/quote]Hopefully someone from @team can chime in here to get the ball rolling.
Nope. This plugin isn’t an official thing, so if you do work on this you should have complete ownership over it. I do hope we’ll put it to use on Meta though.
I’m thinking I’ll start one then. I looked but couldn’t decide which category WIP plugins typically land here. I assume I should start a new topic for build itself. I’m still a bit new to the dynamics of the community here.
I agree it would make sense to use the already existing like system and simply highlight the likes on the first post.
On Facebook the main action is to like or comment on posts and the ability to like the original post is highlighted more than the ability to like the individual comments.
I don’t think you need a centralised topic for it until it’s an actual plugin people can install and test. In the meantime just do your troubleshooting on dev.
Best of luck to ya! Will be following this with much excitement 
Sounds good. I had a major cancellation today so I took it as a chance to get started. I have the category setting working and the boxes added to the UI. Just need to do the wiring behind the button. So the majority of the work is yet to be done. 
Awesome! Very excited about this. We would love to use the plugin to build a hackernews like site on Discourse as outlined here!
Let me know if you need any UX/UI help
I’m working on an active votes release mechanism when a topic has been closed. I’ve been able to add/subtract votes and store everything in custom_fields for both the Topic and the User. I’m debating the use of a sidekiq job that does the release of votes but the votes themselves are in a array within a custom_field. Can you search for users based on the value of a custom_field? I haven’t been able to find an example that does that. That would allow me to search for users that have voted for the topic and remove that vote from the user.
@joebuhlig we’re considering sponsoring some work on this plugin. I wonder what your thoughts are on this feature:
Any cursory ideas on how you might go about implementing that? @sam & @eviltrout would we accept PRs to core to accommodate such a feature? The feature being “alternative Likes systems built on top of likes”.
Not following @erlend_sh why is this necessary?
I would definitely take on a sponsored add to core. I could easily see moving the voting plugin over to use it. I would be curious about using the existing archetype class on likes but would need to think about it a bit more.
But outside of using it for plugins, I don’t see where it would be useful to the master codebase. That might be what Sam is getting at. Unless there’s a desire to implement something similar in multiple ways, I’m not sure it’s worth it.
Yes I don’t think any part of this belongs in core either. I was just wondering if the addition of a new points type in addition to Likes might necessitate changes to core.
And to reiterate, the reason I believe a completely separate points count is necessary is because the feature-voting model encourages votes in the thousands, which can mess with the otherwise safe averages of badges and trust levels.
This becomes even more important if we ever figure out “Votes by unregistered users”, which would further add to a feature’s average vote count.
The safest default would probably be to hide the Like option on the Original Post. Other replies should still be likeable though.
That makes perfect sense to me. I looked into adding a like archetype as part of the plugin and it would be way too complicated and add a bunch of monkey patching which I’m not a fan of.
This makes me think about a slightly different question; would this voting feature be something the team would be interested in having within core? I could take the plugin and port it over to a PR. It would require some changes to the way the data is stored but I would be willing to do it.
If the number or product and tech websites using Discourse is high, I could see it being a big deal for a number of instances. But you guys will know that much better than I will.
Hmmm, as much as I love this feature I don’t see that happening. I don’t think the majority of forums out there require feature voting. I can definitely see it as a bundled plugin though.
If we’re in a gridlock as far as “separating voting from likes” goes though, we could just bypass it for the time being and focus on other features for starters. I’ll PM you.
I think having two systems is confusing - when do you like something vs voting on something? Would the like be a reaction to a post/reply? Can easily get confusing! 
I think voting should replace the like system, when installed.
It could look like this (like Quora)
Alternatively, with number of votes in button
Or like this (Reddit style)
It depends on the community. The need to draw a line between (analytical) Voting and (personal) Liking is how this plugin proposal came into being in the first place.
We’re gonna be testing Feature Voting here on Meta, and in the context of this community we definitely want to keep the concept of Votes separate from Likes, because Votes behave differently, most importantly:
If we kept the concept of likes throughout the forum, except they’d behave differently in feature, I think this would confuse users way more than having two distinct points systems. I can definitely see how the uniform “Upvote” concept would make sense on your forum though, and that’s your prerogative.
* Actually @joebuhlig, I guess the way the plugin currently works, if I hit my Like limit for the day, that would effectively prevent me from casting any further votes as well, right? Shouldn’t be a big deal as users hardly ever hit their Like caps, but worth making note of in a “Known Issues/Limitations” .
Nope. It’s not using the current like functionality in any way. It uses custom fields to store the data. So any feature that uses likes isn’t touched by the plugin. The whole structure is standalone.
Oh! All this time I thought you’d gone with this first-pass approach:
I see you actually mentioned the use of custom fields several times; my bad!
With that out of the way, let’s tackle Super Votes. As you’ve considered yourself, I think a modal would be the simplest approach. On that note, I don’t think the “Unvote” state is necessary.
I think a clear “Voted” status works better. If Super Votes are not enabled, it’d work the same way as before: Clicking again removes the vote. But when Super Votes are enabled, you get modals:
The modal you get right after having clicked to vote:
The modal you get if you click on an already super-voted vote:
The modal you get if you click on an already voted vote:
That’s some weird use of the English language. I hope I’m making sense. Any other ideas @commonpawn?
I really like this. It solves a lot of the issues I was having with “super votes”. A few questions:
Would you revoke the regular vote when a super vote is added? Or would both remain? If a super vote is worth 10 votes, that would mean the user actually has 11 votes on it if they both remain.
My assumption is that we would add another section on the user profile that shows a list of your active super votes like we’re doing for regular votes right now. That way you can find your votes easier. Or would we consolidate them into one list and simply put an indicator on them? I would lean towards the latter.
The defaults I’m thinking would be 3 super votes with the value of each being 10 regular votes. Is that fair?
Sidenote: Those mockups are really nice! 
There should probably be a hover/focus state there, too, Either hinting that the menu exists, or showing the menu.
My thinking is that the normal vote would remain. The “super vote” isn’t an extra vote, it’s just a normal vote that got promoted to super. As far as showing this in the interface goes I haven’t tackled that bit yet, but I was thinking it could be something similar to what we do in the standard topic index with Like ratios, i.e. a topic with a high likes-to-replies ratio will show a red replies count.
I think the latter sounds best. If possible it’d be nice to have a simple “Only show super likes” toggle, but that’d just be a bonus.
So, as i alluded to when answering #1, I don’t think super votes should add more votes. This wouldn’t be quite like UserVoice.
The closest real-life version of this I can think of is actually Tinder. So, if you’re at all familiar with how it works (you know, like, you have a friend who uses it or, like, whatever), you can Like someone and you can Super Like someone. A Super Like is just a Like with some additional perks. And while you can dish out a whole bunch of Likes every day, Super Likes are very limited. I think it’s 1 per day.
So when you get Super Liked, it’s pretty exciting, because “ooh, this person used their oh-so-precious Super Like on me? I’m intrigued”. And you’re counting on that same effect if you’re sending someone else a Super Like.
I want to replicate a similar effect with Super Votes. And I also think it’s a cleaner separation of data. You get to easily count:
In default UserVoice, you can give an idea 1, 2, or 3 votes. I don’t think I’ve ever given an idea 2 votes. I give my 3s to my top priorities, and then I spread some 1s around mostly just to keep track of some other Nice-To-Haves. That’s one extra thing I didn’t want to have to figure out for myself. And if there are people out there using their 2s, how in the world am I supposed to interpret that? In my world, “medium priority” is the same as “low priority” because they both get trumped by “high priority” every single time. Lastly, if a UV idea has 900 votes, that means somewhere between 300-900 users voted on that idea. I’d much rather see up front how exactly many people could be bothered to +1 this idea. Then, layered on top of that, tell me how many of these users consider this a top priority.
