Slightly unrelated. @tiwane Can this be addressed? I’ve practically been unable to vote for about 7 months now. How is this fair? There are multiple years worth of feature requests maybe even over a 1000? Setting it at a limit just stiffles voting and essentially means anytime i want to vote, i have to remove support (a vote) from something else.
How is it unfair? Everyone gets the same number of votes.
Having a limit ensures that users prioritize what they think are the most important feature requests. The overall point of community voting is for the requests with the most support to “rise to the top” so that it is clear which have more support. If everyone had unlimited votes, for instance, then requests the community values less but still have support would have more similar numbers of votes to those requests which the community thinks are truly the most important. It would be harder to see differences in relative support.
If having a vote limit makes people vote for the feature they want the most than wouldn’t it make sense for users to have as little votes as possible. If INat’s voting system wants to be limiting but only to a degree than I think it’s a worthy discussion to have how many votes each user has. I’d think that the staff would agree that five or ten votes for each user would be insufficient considering the current number is a hundred. It follows than that as INat grows even larger there might come a time that a hundred votes could also become too little. Whether we’re at that moment is for the staff to ascertain I suppose but I think it’s something worth considering.
I remove my votes from older requests, especially if one more or less makes no difference. The request is in the system. I keep my votes where there are few, and mine matters (more). The discussion, with your comments and input remains active and visible.
Perhaps fair wasn’t the right word to use. Regardless I’ve essentially just stopped engaging with voting even when there are new feature requests I support because I’m not interested in going back and forth removing support from things I agree with.
Why should people have to remove votes from things they support just because of an arbitrary limit set years ago when the forums were set up?
Why should every time I want to vote now, i have to go back and debate with myself on if the new feature request is more or less important than anything I’ve already voted for?
How does having to remove support from things I support in order to vote fit that goal? If many people are doing this, how many true votes of support have been removed because of this limit?
There are 1533 feature requests
Only 100 votes
Even if I supported only 10% of feature requests, i wouldn’t have enough votes.
Being an online moderator is kind of like being a politician: it’s not easy, because every decision you make, will leave some people feeling like they were treated unfairly. It can feel like a thankless balancing act. At the end of the day, we have to hope that everyone is doing the best they can.
What? While true for a number of situations. I don’t think this applies to this situation as this isn’t a moderation issue. This is a system infrastructure setting that means you are only able to give support to 6.52% of feature requests on iNaturalist. Every month that percentage lowers as new feature requests are made.
This seems even more of an issue than I thought. 1533 feature requests, only 100 votes. So that means you can support a maximum of 6.52% of feature requests.
I don’t agree with the “it’s not fair” framing, thanks for acknowledging that. But I’ll definitely acknowledge that the feature requests category and system is not working as originally intended and needs an overhaul. Since 2019, when we first made the forum, things were a lot more fluid and more loose, and iNat was much much smaller. It was easier to have a back-and-forth between engineers and myself about forum requests. But it also meant there were less overarching structures when it came to prioritization.
Now we have a lot more structure and long-term planning (eg Product Goals for half a year), which I think is better, but it does allow for less of the kind of quick responses and constant updating of the Feature Requests category that I originally had in mind, so it’s stagnated. I haven’t communicated this well, and that’s on me. If I have time in the near future I’ll try to and prune down some of the requests that I think should be closed. And will continue to keep thinking on how to best evolve the category.
Because it makes them think about what they believe would be most beneficial and should receive attention. Votes are not the same as likes in this situation, they’re not measures of basic support. They are meant to convey what you think should be prioritized. There are a bunch of nice ideas here that I think would be good or cool, and I would be happy if added, but that I wouldn’t necessarily say should be prioritized.
I guess one thing I would like a little more clarity on is, how much or little do the numbers of votes even impact the setting of development priorities by the staff and developers at this point? A lot? Are they more for breaking ties? Or do they have relatively little impact any more?
If the last is closest to the answer, maybe it would make more sense to remove the voting system altogether and just let people heart the OP like any other topic?
in theory our votes should be returned when a request is closed. But I had to go back and retrieve my no longer relevant votes. While I was at it, I cleared lots more. Whether closed or declined, my vote no longer serves my purpose.
Much prefer the open discussion on the forum - my earliest feature requests were emails between the 2 of us, with no input for other iNatters use / see that issue differently.
I think currently they have little impact. I can look into potential changes next week.