Use this category to post new feature requests for iNaturalist, and to vote for existing feature requests.
Requests
To make a feature request, start a new topic with the request as the topic’s title. Please take a minute to search for existing requests before creating a new one. In order to eliminate duplicate requests and to not let in requests for features that have already been turned down in the past, new topics must be approved by a moderator or iNat staff member before they are made public. It may take 1-3 business days to get a response to your request.
-
The topic template that appears when you create a new request must be filled out or the request will not be approved.
-
Only one feature request is allowed per topic.
-
No more than one request per day and two or three requests per person per week, please.
-
Take some time to describe not only your request, but why you believe it will improve iNaturalist.
-
Cite specific locations or examples where the feature would apply. Screenshots are often helpful - see instructions at https://www.take-a-screenshot.org/
-
Please use an action verb in the topic title. So rather than just “Extraterrestrial Observations” you should write “Allow Extraterrestrial Observations on iNaturalist”.
-
We are not currently accepting new feature requests related to:
- Explore (observation search page) - add your thoughts here instead
- Specific annotation additions or changes - add your thoughts here instead
- Features that are in the Android app but missing from iOS - we’re already working on it
- Gamification features for iNaturalist, such as achievements, badges, and the like. The Seek by iNaturalist app does include those things, but we don’t plan to implement them on iNaturalist.
- Guides
- Onboarding
- ID weighting, e.g. based on expertise
- Observation fields
- Places pages (e.g. https://www.inaturalist.org/places/38691) - we will fix glaring bugs but won’t add features until/if the Places pages are revamped
- Languages into which iNaturalist should be translated - please see our translation page
- New apps that use iNat data, e.g. a quiz or ID training app
- Other items on the iNaturalist team’s broad agenda from back in 2019
Votes
If you like a feature that is being requested, you can vote for it to show your endorsement. The vote button can be found at the top the topic’s page:
Every user with a Trust Level of 1 or higher has 100 votes to use. You can only vote “for” a topic, there is no downvoting. Once an administrator has closed a topic for which you have voted, you will be able to use that vote for another topic. Topics will not be closed unless a) the request has been implemented as fully as it is going to be or b) staff have decided we will not be implementing that request.
You can manage your current votes via your profile page, or remove a vote from a topic by clicking on the “Voted” button at the top.
Votes are used to gauge community interest for feature requests. iNaturalist staff have the final say as to whether a feature will be implemented.
What happens after a request is approved?
Currently (as of March, 2023), here’s what happens:
If the request is specifically for mobile apps, it basically stays there or is closed, as development of the upcoming mobile app isn’t really open for changes at this point.
If the request is for the iNat website or something that isn’t mobile-specific, @tiwane usually brings a set of them to the iNat team on a weekly or biweekly basis. We discuss if the request is something we
- don’t want to do, in which case we close the request.
- want to do and is relatively uncomplicated, in which case we’ll usualy make an issue on iNaturalist’s GitHub page.
- might want to do in the future but is really complicated, in which it’ll be labeled as such.
@tiwane will also (again, as of March, 2023) be adding the following tags to as many requests as he can, but older closed requests probably won’t get tagged.
under-review = no decision made either way, but at least one iNat staff member has looked at it. Most requests will probably fall under this.
github-issue-made = this is a request we’ve accepted, and have made an issue for our developers to follow and discuss. This does not necessarily mean the feature will actually be implemented soon.
implemented = this feature has been released.
very-challenging = would take a lot of work and maybe even site downtime to implement.
declined = iNat staff declined to move forward with that request.
For requests that have a Github issue, those issues will be prioritized by staff and worked on based on that prioritization, although very easy requests might be also be worked on before more difficult ones.
@tiwane will also add a “Staff Notice” to the first posts of feature requests that will link to the relevant staf response in the thread. It will appear above the top post and look like this:
