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! ![]()
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.
@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.
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 |
Imo 24 turns this into practically unlimited
I like the current limits, makes you think
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
)
@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.
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
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.
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.
@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.
