Automatically send message to observer when adding to traditional project (by curator) fails

For a traditional project which I am a curator, we have a fairly strict set of observation rules (ex: observer must allow project curators to view coordinates). Recently, I have been reviewing, one-by-one, many potential records following Find Suitable Observations. A number of these fail, primarily due to the above rule. Right now, I leave a comment and hope for the best, but a little extra functionality by iNat could really help, such as:

  • Set inclusion into a project as “pending” (rather than just a flat pass/fail) and offer the observer a clear option or instructions on how to meet the criteria. Something like “@kaptainkory attempted to add your observation to the Herps of Arkansas project, but failed due to observer must allow project curators to view coordinates. Would you like to allow project curators to view coordinates and add this observation to the project? Yes/No.”

  • Not sure if this should be a different post, but does the iNat API offer batch functionality that might be configured to automatically add all records to a traditional project that meet certain criteria?

Thanks.

When the project feature was originally created you had to ‘invite’ people to join the project so their observations could be added. You even had a specific “Invitations” page where you could review pending invitations. But people got sick of having to respond to all these requests. I think your proposal is re-inventing that process.

(remnants of old system https://inaturalist.org/project_invitations )

May be so, but right now I’m literally commenting on hundreds of records “Please consider adding your observation to the Herps of Arkansas project” since I can’t add them myself… Maybe it is what it is, but some kind of batch processing for curators would be a Godsend otherwise.

I agree that the process needs help. I spent the better part of the day yesterday sending messages to users with observations that I thought might be in my project area, adding their observations, and then removing them if they were not actually in my area. I was able to add a few useful observations, but it was a huge amount of work for just a few locations.

If something like this is implemented, there should be a way to limit it to one message per user per project, otherwise it has the potential to get spammy.

Users should also have the ability to decline, and if they have done so, not be sent further requests.

2 Likes

Yeah, the old project invites ended up badly spammy as the site grew. I wouldn’t really favor anything that was anything like that being re-instated

2 Likes

So basically what I’m doing right now is getting pretty spammy as it is. I was afraid of that and a couple of observer’s messages have essentially confirmed it, although they were nice about it. I don’t think my interests here are all that radical:

  • Add as many suitable observations as I can to the existing traditional project.
  • Keep the existing project rules as they are, including must be on list and allow curators to view coordinates.
  • Communicate with observers when observations fail for easily resolvable reasons (ex: allow curators to view coordinates).

This doesn’t sound too difficult or daunting, until you actually start cycling through 1600+ records using the existing interface and tools. Here is basically my plan going forward, which is awkward as hell, but I don’t currently know a better way to get it done (and not even 100% sure this will even work):

Stage 1

  1. Use the iNat API (https://api.inaturalist.org/v1/docs/) website to return suitable records that meet ALL project criteria and will not fail to add.
  2. Parse out the observation URLs from the Response Body.
  3. Repeat for however many “pages” I get.
  4. Visit each URL in turn and add to project.

Stage 2

  1. Use the iNat API (https://api.inaturalist.org/v1/docs/) website to return suitable records that could meet project criteria but fail for easily resolvable reasons (ex: allow curators to view coordinates).
  2. Convert the Response Body to CSV/Excel format and paste into spreadsheet.
  3. Repeat for however many “pages” I get.
  4. Sort by user and compile a list of observation URLs per user.
  5. Send ONE message to each user in turn requesting they add those records to the project.

Now, please someone tell me there is a better/easier way?

1 Like

One thing I would investigate about stage 2 (it has been too long since I created my account to remember) is what is the default setting in the ‘Which traditional projects can add your observations?’ config option in your account settings.

I think it is Any, so if a user has explictly clicked None, to me, if that can be determined, then even sending them a request is questionable. Some would say it is fine because all you are doing is ‘advertising’ your project, but to me it is a little questionable.

1 Like

We used to allow some traditional projects (mainly bioblitzes, which had time and place parameters) to automatically aggregate observations and add them to a traditional project. But that is very hard on our servers, so it’s no longer available (although it has been grandfathered in for past projects) so I don’t see this happening.

I would suggest you consider removing the “observer must allow project curators to view coordinates” rule for your project and at least get the observations in the project, then reach out to the users. Not sure if that would help convince them, but it might. I don’t really participate in many projects.

1 Like

Unfotunately this isn’t something we’ll be moving forward with so I’m going to close the request.