Feature Requests - how to best handle the voting system?

Forum Feedback
1

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.

Thoughts?

3 Likes
2

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. )

4 Likes
3

It’s certainly possible.

2 Likes
4

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!

7 Likes
5

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.

3 Likes
6

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?

5 Likes
7

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.

2 Likes
8

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.”

10 Likes
9

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
10

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
11

OK, it shall be so.

12

I don’t know about everyone else, but I find the “vote” system to be very frustrating. Yes, we can “see” what we currently have voted on, but it is difficult to decide which 8 of the 100 open feature requests I would determine as my preferred priorities. If I take the time, I can sit down and evaluate a priority, but the second another feature request goes up, I need to re-evaluate. If it is soon after I did that evaluation, then I can usually remember what the next lowest is, so I know which to drop if another good idea comes along, but if it’s been more than a couple days, or there has been significant discussion that has “changed the picture” on any of them, that all goes out the window and I need to re-evaluate from scratch.

I know it is not the “discourse way”, but I imagine a system where for EACH feature request, we can indicate whether we are for it or against it, and perhaps an indication of how strongly. So instead of a vote, a score of -2 to +2, and the system to tally the results of everyones scoring dynamically, so we can go back and alter our score if our position on that feature request changes. Displayed at the top of the Feature Request would be it’s score, or better yet a tally of each score value… so: “5 Strongly dislike, 1 dislikes, 0 are ambivalent, 3 like and 87 strongly like this feature request”

then perhaps that same tally approach could be shown in the list of ALL feature requests, and at a glance you can see what the support levels are like for a feature.

This would allow the ability to show dis-approval, which we currently do not have outside of comments. In fact, I would go so far as to suggest that the best way to gauge support, or lack of, for any feature request would be the post count!

I fully appreciate the purpose of discourse forum is to function as a think tank, and that actual consideration and acceptance, as well as design and implementation of features is not tied to the vote system, but I just find it so frustrating all the same!

7 Likes
13

I don’t agree with the limits on voting. Unlimited votes would make it much clearer which the most popular requests are. limited votes means the peaks get smoothed out. I don’t believe we’ll all vote for everything just because we have unlimited votes, there are plenty of requests that i don’t find of interest to me, or even understand. Look at the likes: we have unlimited likes yet we don’t all use them on every comment out of politeness or over-exuberance.

4 Likes
14

we don’t actually have unlimited likes… I often come up against the limit, but then I do tend to like a lot!

4 Likes
15

Oh dear. What’s the limit? And what do you do when you reach it, unlike something? I’m not sure I like this.

3 Likes
16

Initially I think it’s somehthing like 50 per day, but it gets increased once you go to the next “level” (received a certain number of badges) to something like 100. It’s actually quite high, and it’s a rainy day in front of the fire to be able to read that many likeable posts in a day. It’s “Per Day”, so I doubt you’ll need to unlike anything! I tend to like anything that is constructive. “Me too” posts not so much, and there are plenty great posts where I just didn’t think to click the like… I do hope no-one thinks a lack of a like is an unlike!

8 Likes
17

and receiving likes is involved in several of the badges, so I try to like as often as I can, to help others gain the badges and gain the extra likes and so forth…

5 Likes
18

I can increase the number of likes allowed per user, but please start another topic if it’s something you’re interested in.

@kiwifergus I don’t think the system you propose (which sounds cool) is doable on Discourse. I can increase the number of votes per user per trust level. It’s currently set to the default levels, which are:

image
image.png1276×752 30.2 KB

I should note, however, that increasing the number of votes won’t speed up how quickly our small team can implement a complex feature. Many more people can vote for something like adding heatmaps on user profiles, but it won’t happen for a while. Votes are just there to gauge interest from the community.

2 Likes
19

Sorry… briefly off-topic, or at least loosely related… thanks for the pull back!

The increase in votes would help make it less frustrating. Of course it wouldn’t fix the “problem”, but then it’s not really a problem either! I have pretty much given up on the votes system anyway, and will just drop comments “I would vote but don’t have any” because I can’t be bothered figuring out where to free one up. I figure dev team will see the support from such comments, and it is the discussions and ideas that really are what it’s about anyway.

Not trying to flog a dead horse, this just out of curiosity… is it possible to have a feature request with a survey attached? Completely impractical, of course, as it would have to be set up by every feature requestor, a nightmare scenario all of it’s own! If it could be “attached” as a first reply to a feature request when it is accepted by moderators might be one possibility… but still too intensive

and confused… I have 11 votes out currently! I must out rank the TL4s!

2 Likes
20

Some old Feature Request topics recently got re-opened, and their votes were reinstated in the process. I ended up with 9 instead of my allotted 8. Meaning I had to release 2 before I could vote again. Caused a long overdue review of my existing votes, anyway…

1 Like