The first post of the topic cannot be voted on (yet). Adding this would raise some overlap with Discourse Feature Voting.
Subsequent posts can be up-voted. One vote per user per topic.
Posts are arranged, first by the number of votes they have received, then by the date they were posted.
Hereās where this plugin fits into the array of similar plugins and features available in Discourse:
āLikeā button. There is already a way of expressing support for a post in Discourse in the form of the like button. The main difference between that button and this plugin is that this plugin re-arranges the posts in the topic based on those that have been supported. This plugin may also add the ability to ādown voteā posts.
Solved Plugin. The Solved Plugin is an official Discourse plugin. It also allows you to create QA style topics, but of a different style. The Solved Plugin allows the original poster (or a staff member) to select a solution to the question in the first post. In contrast, this plugin allows each user of the forum a vote on what they think is the best answer.
Feature Voting Plugin. This plugin allows you to vote on topics themselves, as opposed to specific posts. There is a great discussion of the thinking behind this in the plugin topic and associated spec.
How to safely install or update when using our plugins:
Pavilionās update schedule and support policy
This plugin is one of the Pavilion family of open source plugins.
Pavilion will focuses on ensuring compatibility of a core set of its plugins with Discourse Core tests-passed branch during the first 5 days of every month only.
Any bugs which arise because of an incompatibility will be addressed asap during this āsupported periodā, preferably by the 7th day. Low severity or Beta feature bugs may not be addressed by this date, but obvious things which are ābreakingā a forum should be resolved.
If youāve not used the plugin before, it is safer to adopt it within the support window, so add it and rebuild your site within the first five days of any month, otherwise itās possible you may be introducing an incompatibility and we might not be around to help.
Good question! The Solved Plugin is indeed an official Discourse plugin. However it works differently from this plugin. The Solved Plugin allows the original poster (or an admin) to select a solution to the question in the first post. In contrast, this plugin allows each user of the forum a vote on what they think is the best answer. Different forums will want different kinds of Question / Answer style topics.
Iāve added a brief description of similar plugins and Discourse features to the original post:
Hereās where this plugin fits in to the array of similar plugins and features available in Discourse:
āLikeā button. There is already a way of expressing support for a post in Discourse in the form of the like button. The main difference between that button and this plugin is that this plugin re-arranges the posts in the topic based on those that have been supported. This plugin may also add the ability to ādown voteā posts.
Solved Plugin. The Solved Plugin is an official Discourse plugin. It also allows you to create QA style topics, but of a different style. The Solved Plugin allows the original poster (or an admin) to select a solution to the question in the first post. In contrast, this plugin allows each user of the forum a vote on what they think is the best answer.
Feature Voting Plugin. This plugin allows you to vote on topics themselves, as opposed to specific posts. There is a great discussion of the thinking behind this in the plugin topic and associated spec.
I currently have both running in my instance. In the end, I think the upvoting mainly plays literally a positional role, moving posts up or down. In conjunction, I think both provide a Stack Overflow-type style.
Technically the logic doesnāt conflict, so yes the plugins can literally be used side by side without any issues.
The voting mechanism this plugin uses actually already exists in Discourseās code, itās just not visible. There is a vote action, and even logic that re-arranges the sort_order property of posts based on number of votes, already in the core Discourse code that is not currently usable in normal Discourse clients. This plugin exposes that action and logic.
The Solved Plugin, by contrast, usespost_custom_fields to store a boolean value about each post on a topic that can have an accepted answer (if post is accepted = true), and also uses topic_custom_fields to store the post id of the accepted post (if it exists).
However, there is an open question about what kind of QA system this creates (i.e. a product question). If the OP or an admin can select the solution to a question, then this mitigates the weighting of the ācrowd-sourcedā method of selecting the answer.
Using them together would create a system a bit like the federal election primaries here in the US. The popular vote for the partyās candidate is mitigated by the votes of the āsuper delegatesā (the OP and the Admins).
is it possible to use the QA button for another purpose: to filter and show topics which are QA listed below the button, as well as to use it as a composer in QA?
the same rule for wiki, rating, and discuss button.
The composer on my dev site is a work in progress. It will change quite significantly soon.[quote=āPad_Pors, post:14, topic:56032ā]
how can one set up the funky compose like this sandbow?
[/quote]
Itās a combination of this plugin with this plugin, but I wouldnāt recommend using it yet.
The discovery composer is context dependent. It assumes youāre using category navigation in a sidebar. The context (i.e. category when youāre in a discovery route) is set in a plugin like the map navigation widget.
This is a category list widget that I built for the map navigation widget to allow the user to select the category. You can also navigate by clicking on items on the map.
does this mean like this: if I choose Brazil as the category in the sidebar (using the map), any topic that I post will be in the Brazil category.
just like what happens currently in simple discourse, when we are in a category, and we open create topic, then the default category of the new topic is the category weāre in. correct?
Correct. Posting in the discovery composer I have built is entirely context dependent. Why restrict it like this? Because the use case Iāve built it for ties categories to physical locations, giving them a somewhat different character to normal categories in a normal non-location-specific forum. If youāre specifically tying content to a location, you donāt really want your users to be so easily able to post new content in different locations. Someone can only be in one place at once.
*edit. If youād like to discuss this further, letās do so in the custom layouts plugin topic. Itās a little off topic here.
What would you suggest I call it? āPost Voting and Sorting Pluginā doesnāt exactly roll off the tongue
@angus, my name proposal : āDiscourse Answers Votingā. Sounds net.
The sorting function should be default but optional (can be disabled), as some Discourse.org users may cherish the chronological sorting. Limit your plugin to just that and its associated effects on the right-side elevator would fit well with other plugins, existing or likely to come.
we used QA in our forum, but then the topics with more votes came down in the discussion! thatās if a topic has more vote its position is more near the bottom of the topic list.
does it have anything to do with the Persian language?
e.g. you can see in this image that a topic with one upvote is after a topic with zero votes!
This plugin is now retired in favour of the official Discourse Post Voting plugin
Get the code
See an example
Request a feature
Report a bug
