What is the average wait time for Feature Requests to process?

This is just a simple question, and there is probably a simple answer to it: it just depends. Specifically, it depends on: 1) the number of requests made, 2) the number of moderators present at one time, 3) the time it takes for each moderator to go through and review a request, and 4) the amount time it takes for iNaturalist to process the request, which itself depends on the number of requests being processed at the same time.

So what are the statistics for each component of this process? Are there any parts of the process that I have missed?

1 Like

I doubt there are statistics to measure any of these. The reality is the vast majority of feature requests submitted here or elsewhere will never be implemented.

This is a combination of many things, resources (human, time, financial), requests not in line with the direction the site wishes to go, specialized niche requests being a likely incomplete list of factors.


Another factor could be the quality of the related programming code. If it is an old mess that has become hard to maintain, adding new features is more likely to cause bugs. In that case the programmers may already have redoing that code on the todo list. That could delay a related request. But replacing working code may not be a high priority.

If you have a really good feature request that makes sense for the direction of the project and the developers think it will benefit most users, it could be implemented quickly (if they have the resources to do it). There is really no way to estimate the average wait time. If we could estimate, I think the average wait time for software worldwide would be just short of forever.


process can mean many things. the quickest way to process a request is just to reject it outright. otherwise, there are lots of other paths to processing a request.

sometimes, it seems like a request without an obviously high benefit-to-cost ratio will sit for a while. i assume that that time is sort of a courtesy. rather than rejecting it outright, it’s given a period for others in the community to vote / weigh in to try to tip the scales more to the benefit side of things.

other times, the request is put on the backburner. so it’s accepted for potential future development, but it’s just not the highest priority thing, or it makes more sense to work as part of some other larger effort. so it won’t get done right away.

sometimes, iNat staff do start working on something but may not release it to the public for one reason or another. sometimes, it just takes a long time to develop something that is sufficiently complex.

also keep in mind that there aren’t that many people on the iNat staff, and that they already have at least a general roadmap for development. so adjust your expectations accordingly.


I was just going to say that. Off the top of my head I cannot think of any requests which became reality in a reasonable time frame; usually they’re rejected or deferred. There probably are some that actually happened which I don’t recall. Personally I gave up on reading and voting for them because I don’t think voter opinion has a real influence on staff decisions.

1 Like

The 115 implemented or otherwise resolved feature requests can be viewed here: https://forum.inaturalist.org/search?q=%23feature-requests%20status%3Asolved%20order%3Alatest


The category has 832 requests. 478 are open. 355 are closed. Of the closed ones, 116 are closed because they are tagged as solved (Thanks @bouteloua that’s a cool search you did there.) So about 14% got implemented, 29% closed without being implemented, and the remaining 57% are sitting open. Now if only there were an easy way to find out if the number of votes correlated at all with the status of the request. I guess I would have to click through them all if I really wanted to know. Just choosing a few at random, it seems there are “solved” requests with several votes but also solved requests with 1 or even 0 votes. I am not sure if that’s an indication of people removing their votes from solved requests after the fact. I think in the old days when there was a lower cap on number of votes per person, people did used to remove their votes from one thing in order to put it on another thing. I’m really not clear on how it works now.

1 Like

I think that votes are supposed to be automatically returned. The vote-return system does seem buggy though.


That’s my understanding too. I got clarified that the executive powers of staff is greater than electoral powers of community.

I don’t know about funding situation of iNat, but a few other FOSS (free open source software) that I follow also have similar resource (time/money/human) constraints. Financially, it makes sense why the staff lean on best-bang-for-the-buck features, but personally, the indefinite wait for a feature that I like to see implemented is hard.

Is there a product roadmap that gets published? Maybe it can settle some questions on what and when to expect?

I also thought they were supposed to automatically returned, but then I see some closed requests with 20 votes still on.

The stats are a little misleading as the resolved appears to include things seemingly closed for no reason, or that were not really feature requests, but more discussion, duplicates, requests that were actually already in the functionality etc.

I’m not going to manually go though to get a complete accounting, but less than 14% were actually done.

1 Like

I think this should explain that:


At this point, the best way to determine what’s going on now and in the future is to watch the #news-and-updates category (for example Tony’s post here: https://forum.inaturalist.org/t/inaturalist-2019-team-retreat-follow-up/373/26), read updates by staff on feature requests, and follow along on Github: https://github.com/inaturalist If you have bugs to report or features to request, please post them on the forum rather than Github though.


@cmcheatle @jciv @pisum have pretty much given the answer I would have.

But for a few more details, iNaturalist has 8 staff members plus one contractor (for Android). Two of us are not technically developers, we deal with the interpersonal, outreach, and organizational parts of iNat. And we have one designer, so for major things like redoing notifications, the designer has to come up with designs, then work closely with the developers working on the new notifications system. That designer is also working on other parts of the site and apps, and the developers working on notifications are also working on other features/functionality as well as just maintaining the site’s infrastructure as it grows to make sure everything’s working behind the scenes. So these things do take time, there’s simply no two ways about it.

Many of the feature requests are good ideas and I think they’d be beneficial to at least some users, if not most users. I think we all would love to add as many as possible as quickly as possible, but reality and resources limit what’s possible. Thank you for your patience and understanding, and thanks for the contributions you’ve all made to iNaturalist.

We try to make clear here that votes are there to measure community interest, but they’re only one factor when it comes to deciding whether/when to implement something. 59 people (including me) have voted for some way to search identifications, but that’s a complicated thing to add and other changes take priority because they would give greater benefit both for users and for the site’s infrastructure.

Other requests might have a few votes but are a) obviously beneficial and b) simple to implement, so those do get implemented fairly quickly. I’ve been trying to go through older requests and close or respond to them lately, but I’ve also got a bunch of other things on my plate.

We’ve been lucky to have some outside developers help us with things like markdown and the in-line editing feature for comments and ID remarks, that’s been great. These are difficult times, but if anyone has coding skills and is interested in working on iNat, here’s our Developers page and a page about setting up a dev environment.

The request still shows how many votes it received and who voted for it, but your vote there shouldn’t be counted against the 100 active votes you’re apportioned.


I was hugely grateful when the suggestion (not mine, but from South Africa) to offer a satellite view on the map - was activated very promptly. I use that every time I upload an obs.