Implement a new filter for observations that opt out of community ID

This has been discussed before, but I don’t think anyone has officially made a feature request for this. So here it is:

Please add a new filter for observations that opt out of community ID in both the Explore and Identify pages (and in the API wherever observations are the underlying item being returned). I don’t have any preference whether this operates as opt_out=true/false/any or exclude_opt_out=true/false. (The former would offer a way to search for opt-out observations only, but I’m not entirely sure how folks would use that except in ways that would potentially annoy folks who opted out.)

Also, in the Identify page, by default, filter out observations that opt out of community ID. (While there are legitimate use case for opting out, since opting out is in many cases effectively a “leave my observation alone” flag, I think a reasonable consequence is that opt-out observations should get filtered out by default in the Identify page, which is were many power identifiers go to make identifications. Identifiers could still search for opt-out observations by undoing the filter.)

I would note that changes to how the Explore page works aren’t currently being considered, as it’s already undergoing a revamp. This seems more like a request for a new parameter / API endpoint though, so I let it through.

Also, it may be best to split the discussion as to whether such a feature should be made default / sticky / etc to a linked thread.

I would prefer this to be a personal setting.
I’d rather not see any opted out obs. If the reasons are valid, I probably am unable to help move the ID forward. Would rather keep ploughing thru the thousands that need ID. And we are coming up to the Southern Bioblitz - when my Needs ID will explode

While acknowledging that some have good reasons, and do respond to discussion by opting in later.

4 Likes

I think a lot of the mis-use (I’m not sure if that’s the word that I want) of the opt-out option comes from a misunderstanding of what it means, kind of like the amount of times that people mis-use the can or cannot be improved buttons, or the captive/cultivated button, or setting the location to private, or leaving the ID as unknown but putting an ID in the description, I think many of these are just from not understanding what those things mean.

I have seen several opt-outs that very clearly were “leave me alone” observations, but it would be a pity to ignore all of the ones that just made a mistake, and correcting them can at least send them on the way to being listed casual. And when people opt-out for a real reason like someone put a clearly wrong ID on an observation, they want it to go back into needs id in the hopes that more ID’ers will properly ID it, this would potentially make opting-out useless. I have only had to opt-out once, but it was useful to have it in the needs ID at a lower taxon.

3 Likes

Observers with an opted-out observation that they think has been incorrectly IDed and want to fix could still solicit feedback from specific users with comment mentions (which is usually the best way to get observations like this addressed currently anyways) even if the observation isn’t appearing in the Identify results.

I’m definitely in favor of having this option exist and being “sticky” (so it remains in my Identify filters unless I manually change) though I’m ambivalent on having it being the default for all identifiers.

6 Likes

True, and I do recommend making use of tags, but with that you run into another problem of misunderstanding and that’s how to use the leader board, even people who show up in a leader board for a particular taxon/area may not be comfortable placing an ID.

I’m not against making this change, I’m just pointing out a potential problem of missing observations that weren’t “go away” observations.

1 Like

i wanted to start with a full description of where i thought this should ultimately go. if the iNat staff prefer to implement just the parameter in the API and allow URL filtering in Explore and Identify without any GUI / visual changes to those pages (perhaps following up with GUI changes later), then I’m okay with that.

i’m also okay if there ultimately are never any GUI changes in the Explore page, if that’s going to be the stumbling block. i think the main conflict that arises due to opt out between observers and identifiers can mostly be resolved by implementing GUI changes in the Identify screen only.

I think this would be fine as an option, but as has been pointed out, some opted-out observations should remain visible to identifiers. I would prefer that it not affect Identify by default.

2 Likes

Well, our ids don’t change community taxon on such observations, so you can’t correct them, there’re other ways to get out of “ignorant” ids situation, and not letting community to say something isn’t the best one.

5 Likes

I will never opt in after bad experiences early on. If people want to punitively attack those of us who have strong reasons to stay in the opt out group, then sorry to see you go. Opting out is not punishment but declaring opt out observations verboten is.

No one is doing that. The feature request is for a filter only. Whoever wants to opt-out can do so, and whoever wants to filter for opt-ins only can do so. No one is attacking anyone.

5 Likes

Dude, did you just revive a year and a half old request just to defensively insult someone for having a preference?

No one is attacking you for opting out

3 Likes

I do get a bit defensive when know-it-all experts are demeaning but give zero reason why they disagree, sometimes they are wrong

Not to worry, I doubt that I will land on your obs. Unless I am tidying a distribution map for outliers of our Cape Plants. Where I copypasta - You have chosen a South African plant.

For identifiers - it is the other side of your (all these kids supporting each other in the wrong ID) We have all these (skilled and competent) identifiers agreeing, but the ID is stuck with the opted out ID no matter how many we @mention to Help please? We each need to find a way to resolve our problem.

There would be no need for this filter, or any of the eye-rolling that universal opt out causes if only there was a natural end point to these observations in the situation where the community ID does not agree with the observer’s ID. Currently, if the observer’s ID is identical to the community ID it becomes research grade, otherwise it languishes in Needs-ID-limbo unless and until someone clicks ‘No the CID can’t be improved’. I think that opted-out ID’s should leave the Needs ID pool under exactly the same conditions as every other observation (CID has >2/3rds agreement etc…). The only difference with opted-out obs is that if the observer’s ID is not identical to the CID the observation should become casual instead of Research Grade. If that were to be implemented, the identifiers’ experience would not be different depending on whether the observation was opted out, and the irritating ‘limbo’ situations would evaporate. Observers would probably be rubbed up the wrong way less often too. Everyone’s happy. Is there a feature request for this sort of thing anywhere?

5 Likes

I think it was discussed, but don’t remember a separate request. imo the easiest will be “if it’s 6+ of ids disagreeing with observer, opt it back in”, it’ll be an extraordinary case of wrong community id to get so many ids, but for most observations with such numbers (all I’ve seen) community is correct, the only disagreeing people would be those that opt out because they prefer their taxonomic view (same people would be against your proposal), but their ids will stand and still will be searchable, pros would greatly outweight the cons.

1 Like

3 agree against one who opted out - would (by iNat rules) have gone to Research Grade.
That could automatically go to Opted Out and Casual. And would prevent identifiers wasting time on unwanted IDs. (6 against 1 could have cleared 2 more Unknowns instead)

The original observer would be the only one able to allow CID and Research Grade. They want to keep control and iNat gives them that.

Identifiers are iNatters too. Observers need identifiers - or why is their obs on iNat?

PS why does iNat give priority treatment to Opted Outs? Why are they exempt from the 3 against 1 CID algorithm which applies to all the rest of us? Why are they in Needs ID forever?

5 Likes

After discussing this request, we decided to not move forward with it for a few reasons:

  • yes, it can seem fruitless to add IDs to these at times, but it’s actually helpful to get eyes and IDs on these observations so that if the observer’s ID is incorrect and they choose to not update it, the observation can be made casual grade by vote. This would remove it from searches, computer vision training, etc and be overall beneficial. One possible addition would be a graphic that shows how many more disagreeing IDs are needed to move the observation to casual grade, to make it more clear that the IDs are helpful.

  • the scale of opting-out is relatively small: as of this week, there are about 1.5 million observations where the observer has opted out of community ID, and less than 2k users have opted out of community ID by default.

  • and even though it’s at a small scale, we would need to reindex observations because we don’t currently store this attribute in the search index, meaning more processing.

I think work on a general exclusion filter for Identify would probably be a better use of time and resources. With something like that you could exclude a user (or taxon, or place, etc) from your Identify search for any reason.

5 Likes