What do folks think is a reasonable number of votes to allow per trust level? I see on meta we have changed TL0 from 2 to zero votes and TL4 from 10 to 8. I noticed that I am out of votes myself, even though I am admin here! 
2 Likes
I have always thought that the number is deliberately limited so that it works as a kind of āthis is really important to meā indicator. I can still like all requests and add my use case to feature requests even if I run out of votes. And I can still vote on these topics once another feature request I voted for is completed and the topic is closed.
1 Like
@tobiaseigen, I wouldnāt limit themā¦ I find myself never using votes because, to me, I either merely support or oppose something; trying to ascertain whether something is seriously important to me just isnāt a particularly pragmatic use of my time, when likes exist instead.
For comparison, on Bugzilla, although some instances limit votes, many donāt.
2 Likes
I moved this recent discussion into Jammydodgerās original because it feels right to continue talking here about Feature voting.
I like the idea of limits, but I also think that there are so many open feature requests that it feels unfair to have a very low limit. I feel constrained by this myself! Votes are also a signal, and by not letting people vote we are depriving the product team of that signal.
I am inclined to increase the limits along the lines below. What do folks think?
| Trust Level | Current Votes | Proposed Votes |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2 Likes
Imo 24 turns this into practically unlimited
I like the current limits, makes you think
2 Likes
I do wonder if the strict rationing of precious votes results in limited intel. Vote counts generally seem low for the number of users here. Many feature suggestions have more Likes than votes, but I imagine only votes are noticed.
Being perpetually out of votes and always having to triage & sacrifice to vote on anything new is a significant barrier. I review my existing votes to see how I can free up votesā¦ but none of the requests are unworthy. They just scrolled off the feed and got forgotten.
Am I to give up on them?
Should I bump my favorites with a comment? Having voted on a feature, commenting āYeah, good idea!ā feels like superflous clutter.
Good ideas sit with one or two votes. Are people not discovering them, not interested, orā¦ are they just out of votes? 
Increasing limits wouldnāt require a bunch of coding, and it feels like it would help ā but I also think of how widening a road to reduce traffic just invites more traffic and youāre back where you started.
Just spitballing hereā¦ some bunch-of-coding functional changes as alternatives to a hard limit:
- Allocate a number of votes per month based on TL. (On āvotes dayā thereās a flurry of activity as people visit Feature and evaluate open itemsā¦)
ā¦or, as heliosurge mentioned, eventually release votes:
- Release a used vote after a set time, or
- Staff review stale feature requests on a rolling basis and either a.) bump topic for another chance, or b.) comment with āno plans to addressā and release votes.
ā¦In either case, cast votes remain in place, and users canāt exceed their vote allocation by further un-voting these topics.
(Easy for me to say. Thatās probably a lot of coding 
)
2 Likes
@sam, it doesnāt for me, since I just use likes. Its current implementation feels a little redundant ā rather like the upvote and thumbs-up both existing for GitHub Discussions. Iāve already bookmarks to keep track of what matters to me.
2 Likes
Agree having duplicate signal is confusing
āI like how you wrote the feature request, sounds good to meā
Vs
āThis is certainly in my top 8 I think discourse should buildāā
It may be an interesting experiment to disable op likes when topic voting is enabled
1 Like
There is something about closing some requests with āsorry we are not doing thisā
There is certainly something extremely compelling about closing 2 year completed features as done, and feature requests that no longer makes any kind of sense as stale.
2 Likes
I donāt think it would change that much in the end. Most of my votes were added a year ago. Yes, I would have been able to vote on more topics, but once I have spent all my votes itās the same again: I would have to wait for one to be completed and closed, or I need to remove my vote from a different topic. I am quite sure there are also more than 20 good feature requests on Meta 
As I said before, to me votes are something stronger than a like. But I still think likes on the first post are also very helpful to capture interest. They have been the indicator for more than 10 years when voting wasnāt enabled. So ignoring them, especially on long-standing requests, means ignoring the only way users were able to show support back then.
Also, maybe no one thinks the feature request is something they need that much to spend a vote on it, but lots of users like it because they think it would be helpful. Does one vote (usually by the author of the request) say more about how helpful that feature would be for a range of different Discourse sites than multiple likes?
I wonder whether, instead of increasing the number of āIām really interested in thisā votes, it would be better to limit the number of topics they can be distributed across.
So instead of having 378[1] topics from this year to vote on, it might make sense to pre-select them.
For example, only requests with a certain amount of reactions indicating interest from multiple users are those that can be voted on, or you could limit it by time and say that voting is restricted to topics from a certain time period in order to find the favorites within that group of features.
You could also say, āWeāre revising the review queue. What requests come to mind?ā Then those would be moved to a subcategory and voted on.
Being able to spend 4 votes on ~100 topics would be proportionally more than being able to spend 10 votes on all open feature topics.
3 Likes
@sam, I was hoping for the opposite ā I donāt much see the value in votes. Do votes provide something, technically, that likes donāt? I doubt anyone likes an FR that they donāt support. Some Discourse instances donāt utilise votes, and, instead, provide ā
ā and ā
ā as the sole available reactions.
If likes were disabled when votes were enabled, that would āreduce intelā, I believe. For comparison, that Forgejo and GitLab donāt limit upvotes might indicate that value in having them as a simple support versus donāt support indicator exists.
Poking around Feature today out of curiosity, it was interesting to compare these filtered views:
- Filtered results for category:feature status:open order:likes-op
- Filtered results for category:feature status:open order:votes
I wonder what could be done with a Data Explorer query including both Votes and Likesā¦ 
Also:
Automation thought: maybe a āprimaryā pool based on Likes could escalate requests to votable status.
Manual curation thought: occasionally a request with obvious merit gets picked up by staff regardless of votes, so in a way, some curation happens already. But perhaps everything should face a quick staff review?
Supporting example: I found 8 feature requests around ālet users close their own topicsā ā from 2014 to 2025 ā a couple closed, but most of them open with 0 votes. Somethingās not working well if the same request is made repeatedly while older versions go unnoticed & unvoted.
If users arenāt searching ā or seeing āyour topic is similarā¦ā dialogs ā Iām not sure what else could be done but have initial requests reach a staff checkpoint: 
if new, move topic to a voting category; 
if similar request exists, reply with a link.
Just thinking out loud. I know everything takes resourcesā¦
The limit would be fine if the team released the votes after composing a list of voted upon topics. Maybe release the votes Quarterly. The update could even detail features the team have chosen to add to the roadmap with a potential timeline in terms of priority.
Otherwise 24 really isnāt unlimited as some votes have. Tied up for over a year and possibly more. It is a pain to also try to go and remove votes in seemingly dead features that might not even being considered.
Maybe an idea is to once in awhile create. List if features the team is strongly considering and create a poll for ppl to vote on and then update things from there. Topic voting is not bad ud there is a release cycle. What that cycle should be is something the team needs to dkscuss and decide on
not following, canāt you release votes on stuff that is no longer important to you?
That is presuming these things previously voted on have been implemented or no longer have importance.
Collating Feature Requests in a listing of ones the team is considering to add in future and releasing those votes to be utilized again imho makes sense.
Why even use topic voting? As you mentioned the Likes/reactions could be used instead of being limited to a set number of votes. Using say a particular reaction like 
might be sufficient to gusge interest in a particular Feature request as you could use a data explorer script in this category to return top topics maybe in the Op post with most of this particular reaction.
Vs limiting voting that really doesnāt feel like it is going anywhere as there is not in my experience any updates directly related to this category. There might be from. Time to time and i just havenāt noticed it maybe.
I am sure some of the new things rolled out may have been a feature request at one time though.
Imho topic voting might be better for Contests voting on the top X Topics with a set close date to announce day top 3 winners. But used in this category it feels more like a contest without a clear conclusion with needing to second guess ones votes.
1 Like
Iāve commented a bunch on the process here, but to be fair, there are lots of feature requests tagged as completed ā Filtered results for category:feature tag:completed
2 Likes
The completed tag does help. But I find if the team wants to gauge more interest in feature requests. Limiting the number of votes can be counter productive.
As Sam mentioned with the various signals like the Like/Reactions. (Choose a specific reaction) Or even no vote limits. As not all Ideas will ppl vote/react to as they may not be interested in a specific idea. For example there is I believe a request for Electing a forum team.
While on some forums that might be an idea/option many would not want to have a potential popularity contest decide on who controls the forum.
So you will still get Features with more votes/reaction signifying level of community interest overall vs limiting to set number which is more likely to split interest and have much more Tied so to speak.
1 Like
Reviewing the tag does indeed help.to see how much has been added. It just feels too restrictive to limit vote interest. Even some of the features completed had minimal to no votes. Granted easy simple wins are if course good.
My dream here would be for everyone to have their own, personalized , stack ranked view(s) of features, which we could then aggregate into different collective views through different ālensesā.
So, rather than have it be a binary vote/non-vote in everything, Iād be able to put together my ātop 10ā list, and show them in order of preference. Youād be able to do the same. And then I could do things like āshow me the top ten list for people who have joined meta in the last yearā or āshow me the top ten list for people who are hosted on our starter planā, etc.
In the meantime, Iāve got some other ideas for how we can make things a bit more manageable here, which tie into ideas of how we manage an open roadmap and backlog more generally. These involve some changes in how we manage the bug, feature, and ux categories, and how we separate more open ideation from more concrete proposals and/or specs for things we either are planning to work on or would be happy to see contributed.
Iām hoping to get something like an RFC put together for this for discussion before the end of the year.
4 Likes