I know we can “vote” on feature requests, but I have personally found the limitations on the voting to be quite annoying. Firstly, the limited number of votes means we have to constantly be re-assessing how we prioritise our votes. Secondly, they don’t really give a good way to oppose feature requests on the few occasions where we can see a negative overall impact. Nor to indicate ambivalence, although one could assume that not voting might be construed as such, but does that mean anyone who has not yet seen that feature request is (by default) ambivalent to it?
I had wondered if we could incorporate standardised polls into feature requests, either added to the original post (if moderators are allowed to do that) or otherwise added as a reply immediately by the moderator who accepts the feature request.
Advantages are that it can allow for everyone to vote for everything they would support, be able to show opposition or ambivalence to an idea, and for staff/dev to get a real perspective of the level of support for a feature request.
This feature request is therefore more of a test of whether that concept could work, and to gauge whether there is interest in doing this. The actual wording can be tailored to the type of feature request, or just left generic as in this example. It is NOT a request for a feature in iNaturalist itself, but a change to how we would “vote” for feature requests.
I’m not sure how accessible stats on these polls will be for staff and devs to review, so maybe after a couple weeks of this test we might find out if it’s useful?
I did consider making it a general category topic, but it would not group with feature requests. Definitely scope to hold general discussion on a feature request in general before switching it over to feature request once the details are ironed out.
Any moderator can edit the original post, and it does appear that building a poll is one of the editing actions available. So if I can see that functionality, I’m sure Tony can too.
That said, for this test do you still want a moderator to edit your post to remove the poll you inserted, then add a “replacement” poll?
It might be confusing to have “n votes” at the top of the page being the ones from the existing vote system, and then different vote tallies further down that don’t match up. Especially for new forum members that might not understand the two systems.
OK, successful test, although it required two steps because of an error, “Cannot change a poll after first 5 minutes.” But I could just delete it. So deleted it in first edit, then added new one in second edit.
True. It would have to be considerably better in the view of the majority before I think it would be switched off though. And certainly, it would have to meet the needs of staff and devs… worst case scenario is we establish it as not workable as a replacement!
I do think this is a worthy idea, but as @kiwifergus mentioned, it may generate confusion. Also, adding a poll creates more work (although that work creates richer data).
I also think it IS good to force people to choose which features are most important to them, by limiting their votes. Maybe we can keep the votes as a system of showing what is most important to people, while also encouraging the inclusion of polls in feature requests.
One other potential issue is that polls would mean that users who are on the forum more (who would be more likely to read and vote in polls or have more time) would have more influence. For example, one person who had time to read all the polls and vote in them would have the maximum level of influence, while someone less engaged would have less influence.
The current system means that everyone has a more similar level of influence, since the max number of votes is capped, essentially making an influence cut off.
Of course, it might be reasonable to have a system where more frequent users have more influence (I’m not really arguing for one way or the other here). But it seems to me like this would be a big difference between the current system and a poll-based one.
I did consider making it a general category topic, but it would not group with feature requests. Definitely scope to hold general discussion on a feature request in general before switching it over to feature request once the details are ironed out.