Feature Requests - how to best handle the voting system?

Hi Everyone,

One thing that attracted us to Discourse was the ability for users to vote on a topic, meaning they could endorse to a feature request without having to

  1. Engage in a discussion (which some people might not want to do but still want their voice heard).

  2. It would allow iNat devs to easily see what has captured the most endorsements by the community.

  3. It would make iNat team to be more responsive tofeature requests (eg “won’t happen,” “working on it,” “planned for x date” etc) and close them so that votes can be returned to users and they can vote on other topics.

However, as @kueda pointed out, it’s likely that the team cannot create new features at the rate at which users request them (sorry!) so perhaps it would be better to not close feature requests unless they’re either completely implemented (eg https://forum.inaturalist.org/t/add-forum-to-the-community-dropdown-in-the-inat-website-header/1403) or simply won’t happen (eg https://forum.inaturalist.org/t/standalone-uploader/1742).

Then users can move their votes between open topics and we can keep more complex, long-term requests (eg https://forum.inaturalist.org/t/remove-all-curators-and-start-from-scratch/140/27) open longer.



If there are going to be more requests, can/should the number of votes everyone gets be increased?

(Edit: I meant to have a question mark not an ! there sorry. )


It’s certainly possible.


That seems sensible to me, along with @charlie’s suggestion to bump the vote limit occasionally, maybe so that any given user could vote on, say, roughly 10% of open feature suggestions?

And I’ll add that my heart and my thanks really go out to @kueda and the whole team! Discourse has been a wonderful improvement for the forums, and I expect also somewhat of a Pandora’s Box of idea-overload. Compared to most (heck, all!) other tech products and services I’ve every dealt with, you all are amazingly responsive to and engaged with the user community. Rock on!


I think keeping feature requests open until they’re complete or denied would be better than the current situation, because it would allow us to vote for and discuss large but important long-term projects while they are still in progress.

I want to distribute my votes to my most desired features, which have mostly turned out to be ones which the staff and developers are already planning to implement. There are so many feature requests in progress that I would like to vote to help the developers prioritize.

I’ve seen some valuable new ideas which were only posted after weeks of back-and-forth discussion. That kind of community input is most valuable for the big features which take a long time to implement, but right now those are the feature requests which are getting closed right away.


And another thing, a couple of times a feature request has been closed before I could say thank you. For example, the addition of sort by random and sort by last updated have combined to make it 100% easier for experts to identify old observations. E.g. someone who reviewing random observations in an area finds an observation from 7 years ago, before there were any taxon experts in that region, and adds an ID. Then another expert, sorting by last update, immediately has the old observation brought to their attention and confirms the ID. Thank you, @kueda!

So that’s another reason to keep a feature request open for a while. Say, two weeks after it was implemented?


Given this fact, I’m not sure it makes sense to increase the number of votes per user. We’d just end up with more feature requests with more votes on them. Yes it’s frustrating not to be able to vote for all the feature requests one wants, but given limitations on the number of feature requests that can be implemented, having few votes might be a good way of recognising that it will take time for this to happen.


As far as prioritization, I think I would rather be asked, periodically, “which of these 5 features would you most like to see implemented next” than “here’s 10 votes (or 25, 50, whatever), read these 500 open feature requests and choose accordingly.”


I agree. However, I still plan on going through the “easy” requests (again, eg https://forum.inaturalist.org/t/add-forum-to-the-community-dropdown-in-the-inat-website-header/1403) and adding them to my weekly report so that they don’t get totally lost, and votes can be used for the thornier requests.

1 Like

yes, an easier way to move votes and to asses ones priorities would be ideal. Otherwise I agree to keeping them open until implemented or rejected, and maybe a post to say “we are moving forward with this, you can pull your votes if you like”. Actually, keeping open even after implemented so we can discuss the impact etc?

1 Like

OK, it shall be so.