I’ve been in the process of putting together data for a comprehensive database of plant galls in North America, and had been planning to have my partner develop a website from scratch to make that accessible to users. Recently I discovered that iNaturalist’s Guide tool already has 90% of the features I had planned to have him make for me, so it seems like a waste of time to rebuild all of that.
The only problem is that the Guide tool as it currently exists is slightly clunky relative to the scale of what I want to create. Alex tells me it would be easy for him to add a couple of accessibility features to the tool without disrupting anything that’s already there (he does similar things for work). Is this something we’d be allowed to do? Who do we talk to?
Want to help out? Fork the project and check out the Development Setup Guide (might be a bit out of date, contact kueda if you hit problems getting set up).
I think the guides part of iNat is an old part that they eventually want to revamp or replace. Before getting too invested in that path it would be worth looking into.
To clarify kiwifergus’ comment, guides are considered a failed experiment by the site. The existing infrastructure will be left in place, existing guides, and even new guides will still be available, but the site will allocate no resources to changing the code, adding new features etc.
I am unaware of any plans the site has to replace the functionality, but someone from the site best officially confirm that.
That’s why I asked, yeah. Does “no resources allocated” mean if we make improvements they won’t be implemented, or just that we have to do it ourselves, is the question.
I dont work for the site, but any code written by non staff members still has to be reviewed, tested, integrated etc by them. Its not a case of it meaning they have no work required. But again, an official word should come from the site itself.
@megachile, if you’re talking about doing some work on the iNat guides feature for eventual integration into iNat, we’d consider a proposal, but I wouldn’t get your hopes up. Anything we integrate is something we ultimately have to maintain, so if it looks like a maintenance headache, we probably won’t integrate it. As mentioned above, guides are a failed experiment that have become an annoying distraction. I know there are a few that people have put some genuine effort into, but on the whole, people just want a tool to print grids of photos or maintain lists of hundreds of taxa with zero additional context, neither of which was the point of the feature. Anyway, if you want to write something up here specifying exactly what you’d like to do, I’d be happy to comment on it.
Regarding doing things yourself, I would not balk at reinventing the wheel. The iNat Guides feature is not even a wheel. It’s more like a crude sledge made out of styrofoam that constantly disintegrating every time you drag it somewhere. Making something yourself comes with costs, but hopefully you get the benefit of something that exactly suits your needs. If you’re really committed to offsetting the cost of development (not maintenance), the code behind the excellent https://gobotany.nativeplanttrust.org is also open source and much better suited to a “comprehensive database of plant galls in North America”: https://github.com/newfs/gobotany-app
