(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 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 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 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 remaining votes are shown when you vote and have less than X votes left
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.