(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!
Voting
Likes/Reactions
I’m off to do some 
I don’t think so.
btw