The community has enabled Topic Voting for the #feature category, allowing users to cast weighted votes based on Trust Level (TL1: 4, TL2: 6, TL3/4: 8) to prioritize feature requests. While Likes are retained for historical continuity, the limited vote allocation sparked a debate regarding its effectiveness and potential improvements.
Users like tobiaseigen and ToddZ argued that current limits are too restrictive, causing valuable signals to be lost as users run out of votes on stale requests. They proposed increasing limits or implementing a ārefillā system where votes are released after a set time or upon staff review of closed topics. Conversely, sam and Heliosurge defended the scarcity as a necessary mechanism to force prioritization, suggesting that unlimited voting dilutes the signal of genuine interest.
Discussions also touched on the distinction between Likes and Votes, with some suggesting that Likes should remain the primary indicator for general interest while Votes denote top priorities. mcwumbly proposed a more advanced solution involving personalized, stack-ranked views of features to better aggregate community preferences.
Notably, the conversation revealed that vote limits were officially lifted on March 15, with ToddZ confirming the change and zogstrip noting that technical support for disabling these limits has been added to the codebase.
(the screenshot isnāt the most compelling, but Iāll come back and replace it when we have some topics that have been voted on )
Voting
Votes are limited, so you will need to choose wisely. You can see the allocations for each trust level in this table:
Trust Level
Votes
TL0
0
TL1
4
TL2
6
TL3 and TL4
8
This is the total amount, though votes can be removed and recast if you change your mind - and if a topic is closed your votes will be returned and be available to be used on other open Contribute > Feature requests.
Likes/Reactions
Normally Likes and Reactions would not be displayed or be able to be given on voting topics, but as we have such a long history it seems a shame to blank that out and start over - so weāre keeping them.
If anyone has any questions or suggestions please let me know
No that is quite understandable. But this will make it a lot easier for the team to identify which requests have greater community support as a want/potential need
Of course there are still other factors that will impact if/when a feature request might be worked on/implemented.
I was contemplating this earlier about how to handle some Contribute > Feature topics that donāt necessarily fit the ārequestā mould. As yet, not sure. Maybe some display: none; based on tag.
I think the issue for me is not that allowing voting is bad for experimental features, but itās a little tricky because the functionality is evolving, so thereās no snapshot to reference against voting numbers.
That will potentially put a less favourable light on features that will emerge great but start out compromised in some way but somehow resolve their issues.
I think voting for something thatās being actively developed is likely a waste of a vote, as specific feedback/replies are going to be more desirable/move the needle more than a vote count at that stage of the proceedings.
Itās early days yet though, so Iām not sure Iāve got a fully-formed opinion.
Yeah see what your saying. With these experimental features it might be better as well say maybe using standard voting vs topic voting to explore parts of the features for feedback once a part feature has enough feedback points.
I think perhaps if this works out, we may want a separate category for cases like the experimental sidebar, where weāre sharing updates and/or seeking feedback on things weāre actively developing, and then make Contribute > Feature more explicitly about feature requests (I kind of like the idea of renaming it to #ideas or something in that case).
That said, weāre just getting started trying this out now, so happy to take this one step at a time.
We have a separate category for work our PMs are actively building where the PM describes the problem theyāre solving, etc. and usually ends the topic with, āSound familiar? We want to hear from you, hereās our Calendly if youād like to discuss.ā
We call them In Discovery sessions, and the category is In Discovery. Weāre also designing an ideas portal solution soon so that we can eventually move off of AHA Ideas.
Iād love to compare notes/ideas on using Discourse as an ideas portal for a Product orgāI bet weāll have near-identical needs!
I have been voting for features but was unaware that I had a limited number of votes. I see the reasoning why this is necessary, but it isnāt very clear. Would it be possible to have a (# of votes remaining) under the Vote button?
The problem is when the last time you voted was weeks ago, itās difficult to remember the number of votes you have left.
Though I donāt think I need that information for every topic. Maybe the remaining votes could be shown above the āmy votesā topic list. Then you can find out without voting for something, but it is not shown everywhere.
Voting
Likes/Reactions
Iām off to do some 
I donāt think so.
btw