Description of need:
When a user has been inactive for a certain amount of time, and can’t come back to check on observations, and they have opted out of community ID, then can’t return to add an identification, then that becomes a problem, especially if the observation is important (e.g. iNat first, or range extension, etc). Sure, it isn’t a problem with users who actively engage with their obs, but it is once they aren’t.
Feature request details:
When a user has been inactive for a certain period of time… (lets say 6 months, as likely they aren’t coming back) then simply revert their observations to showing the community taxon (as if they haven’t opted out of that). And even if they have returned, don’t revert them back to opted-out unless they specifically change their settings to opt-out.
While this would be the most beneficial option for iNat, it also goes deeply against the principle of “the user owns and decides what happens with their observations”.
An alternative option would be to pick an amount of time of user inactivity (let’s say a year) and after that time any observation opted out of the community taxon that is not RG becomes a casual observation.
This could be listed under the Data Quality Assesment, for example as “User is active or community taxon is enabled”.
Additionally, If the user comes back online, there could be a prompt informing the decision and suggesting them to opt-in on the community taxon to return the observations back to eligible
Could someone explain why this is a problem? Does not the community ultimately decide on the ID? I must be missing something. If not, I’m wondering if the new “disagreements” filter won’t help with this.
Not always. This is about users who have opted out of community ID. It isn’t a problem if the ID they have given their observation is correct. It can be a problem if their ID is incorrect and they have opted out.
Is this an actual iNat principle? No herbarium or other scientific archive works that way. You can’t go up to an herbarium and say “I don’t want anyone to change the ID’s because they’re mine”.
Other online collaboration projects such as Wikipedia do not work this way as well.
I don’t know that it’s written out anywhere but the general idea has guided many features, e.g. do not update your IDs based on taxon changes, allow people to edit or delete observations/IDs/comments at any time, edit photo and observation licenses to disallow sharing with GBIF and others, disallow others to add your observations to traditional projects or to add observations fields to them.
Or, just as bad, if they’ve given a very high level ID and the observation is permanently stuck there however many identifiers waste their time in trying to update it. (I saw one yesterday that has an observer ID of Plants, for example.)
A part of me thinks your idea is of interest, provided that the user’s ID is at family or above. However, this would make it much more unlikely that a valuable observation could be found and favourited or (depending on user settings) added to a relevant project, which depending on the situation might be worth the awkwardness.
Edit: or linked in a journal post, for the ones you can’t add to projects or apply observation fields
There is an option both in your profile and in each individual observation to “opt out” of the community ID. “Opted-out” observations remain identified as whatever the observer identified them with, regardless of how many users ID it as something different. Opted-out observations currently stay at “Needs ID” unless people agree with the observer.
This is useful in a couple of mostly edge cases: For example, I opt out observations for which I’ve identified a subspecies or variant after the obs was already RG, because otherwise it will stay a stuck at species level. I remove the opt-out as soon as enough people id the ssp/var, or if somebody corrects my wrong id. Some actual experts opt out observations for which they are a primary source, or in case of newly described species, etc.
But, some users entirely opt out for their whole accounts or are unresponsive to the community, and those cases generate uncleareable backlog of “needs ID” observations, as any observation for which the observer was not correct (or above species level) will never move to RG no matter how many people ID it.
When you see an obs where a string of identifiers have added their ID, but the Community Taxon is ‘stuck’ - check whether the observer has Opted Out. WHY is this obs ID NOT moving?!
For single obs with good reason it is a useful option. A global opt out - nobody but me can ID my obs - is a nuisance and wastes identifier’s time. When I come across them I leave a comment for the next identifier - a politer version of - don’t waste your time and effort on this obs, next!
You can’t go up to an herbarium with a bunch of friends and say “This isotype of daisy looks more like a fig tree to us therefore by majority vote let’s write ‘fig tree’ here”, either…
I’ve come across this several times, where I try to refine an ID only to find that oh- several people have already tried and the observer doesn’t allow for the ID to be refined. I wonder in such cases if it’s not best to mark the DQA vote for ‘community ID cannot be improved’?
I usually shy far away from that particular DQA option, but I think it might actually be valid in this case. After all, we’ve tried and the community ID quite definitely cannot be improved unless the observer comes back and changes their ID. And in such cases, marking that DQA option subscribes you to the observation, so if you check your notifications you can remove your DQA vote if needed.
To be clear, I haven’t done this. I prefer to steer clear of that DQA vote except for particular species that I know require dissection for an ID. But if others agree, I may begin using it to avoid wasting other identifiers’ time.
I don’t see an issue with using this DQA in this situation - the DQA doesn’t ask whether the observer has opted out - just to evaluate the CID. I am also conservative in my use of this DQA, but if a user is certain that the CID cannot be improved, it is fair to tick.
No, but a series of researchers could annotate an isotype noting that it is a different species than the holotype and thus not actually an isotype. It’s a rare case but it can happen.
I think this request may be generally reasonable, especially for when the observer has not logged on for a long period like 3 or 5 years. 6 months is too short as people take long breaks sometimes. The really problematic ones are from major contributors that have either passed away or just moved on years ago for some other reason.
iNat is not like an herbarium or any other physical research collection/museum because when you deposit a specimen in one of those collections it is no longer yours. Not the case with iNat records, given that you can delete any of your records or your account at any time.
I agree. As a serious “hobby hopper” where I’m pretty much either all in or all out. Something like 3 or 5 years feels much more reasonable to me. I’d lean towards 5 years as a reasonable time frame.
There are a couple of comments above stating things to the effect of ‘if a user has opted out, the ID cannot be changed’. This is not quite correct. It ignores the distinction between the ‘Observation taxon’ (which cannot be changed from the opted-out observer’s ID), and the ‘Community taxon’ which continues to operate as normal. If the observer is in disagreement with the community the observation cannot become Research Grade, but if someone clicks the DQA ‘community taxon cannot be improved’, the observation will leave NeedsID - it will just be ‘casual’ rather than ‘Research grade’.
Still, how an observation responds to filters tends to be based on the observation taxon rather than the community taxon, so that’s why one does not necessarily see it move. This is indeed frustrating sometimes.
I don’t think someone’s opt-out should be removed after a period of inactivity - it was their choice - but I will send it to casual if the community taxon has gotten as far as it can.
Any chance there is already an auto DQA already for when the community ID doesn’t match the displayed ID? I feel like I’ve seen this when monitoring casuals.