I think the sentiment is that the design is unnecessarily introducing work for identifiers, and that those simple comments build up quickly across the users that have all observations opted out.

The community volunteers their time on this platform, and iNat as an organization has lots of opportunity to tweak things to refine this tool that provides such valuable data.

Immense amounts of data is fabulous, but the true value probably come from the curation.

3 Likes

I created this project for those who dislike spending time on opted-out observations, but of course it can be used also by those who like to spend time (identifying or commenting) on these observations:
https://www.inaturalist.org/projects/user-has-opted-out-of-community-taxon

In the first case, append this filter to your search URL (not very useful by now, but may become more significant later, with more observations in the project):

&not_in_project=153322

In the second case, review the observations in the project and add more IDs and comments:
https://www.inaturalist.org/observations/identify?quality_grade=casual%2Cneeds_id&verifiable=any&project_id=153322


I use the exclusion filter above when searching for observations candidates to be pushed to other projects (see here) for helping to indentify observations. For this purpose at least, this project is useful, now and in the future.


Update: replaced by another more complete project, and another filter, see below.

1 Like

I’m not sure if formally agreeing with an ID is necessarily encouraged by Identification Etiquette on iNaturalist - Wiki since it makes it seem like observer’s agreement with community is just as good as specialists who ID it.

For some of my observations, like this bird, I still have my rough ID because I’m no birder so my agreement with community wouldn’t be genuine.

Granted, I treat some plants differently since that’s what I identify.

1 Like

Thanks! I am unclear how this works. Are you adding observations one at a time to this project? Wouldn’t it be more efficient to be able to add opted-out users to the rules, so that all of their observations are included? Of course, some will have opted out of letting others add their observations to projects too…

1 Like

I am adding observations one at a time, and only automatically (by software).

Adding opted-out users to a collection project would be indeed more efficient (but can’t be automated, by software):
https://www.inaturalist.org/pages/managing-projects#collection

But I can’t even paste an enumaration of many users.
I have to enter them one by one:

…let’s do it anyway!

Here it is (still adding more users…):
https://www.inaturalist.org/projects/user-has-opted-out-of-community-taxon-collection

I could keep the traditional project as an entry point, for collecting (by software) observations from users not yet in the rules of the collection project.

2 Likes

Update:

New project containing observations of 453 users (so far) that have opted-out (in their profile):
https://www.inaturalist.org/projects/user-has-opted-out-of-community-taxon-collection


For excluding these observations, append one of these filters to your search URLs:

&not_in_project=user-has-opted-out-of-community-taxon-collection
&not_in_project=153984

BTW, by substracting from the 1st project all observations in this 2nd projects, remain only a few observations (26 so far), for which the observers have opted-out, but only for these observations, not for all observations. This illustrates how minoritary are the cases of opting-out only for some observations.

3 Likes

I would suggest removing @silversea_starsong since I know from an earlier post that their opted out is because they ID to species, and want to avoid … I don’t know what that is, so I will push the ID back to something very broad where I am confident. Theirs is an informed and deliberate opting out with good reason.

(I have clashed with your number 25 and my autopilot skips that in future)

2 Likes

Done.

2 Likes

A lot of this predates my active iNat usage, but I think it might help to understand how the Community ID and opt-out processes came about.

If I understand correctly, the concept of Community ID (and the requirement for >2/3 agreement) was introduced in early 2014 in order to try to improve data quality. Here is the github discussion where it was fleshed out in the second half of 2013 and here is a Google Groups discussion in January 2014 around the time Community ID was introduced.

@kueda starts by explaining how IDs worked before 2014.

Apologies in advance for the novel. We’re tinkering with how observations are linked to taxa and could use your feedback. Currently, you are in full control of the taxon associated with your
observation. Everyone else can add identifications, but your observation isn’t associated with a taxon until you agree with those identifications.

However, this is a problem for people who don’t realize they are responsible for their own data, or for people who just add some data and then abandon the site. The community puts work into adding
identifications, but the observations remain unlinked to taxa and ineligible for research grade status. It’s a bummer for identifiers, some newbies, and especially for project owners who often recruit a bunch of one-time users for an event who never return to confirm IDs.

I suspect we can all agree that situation (where all IDs depended on being accepted by the observer) is a whole lot more frustrating than anything we’re dealing with now. Ken-Ichi then explains how Community ID will work…

What we’d like to do is introduce the idea of a “community taxon,” which is sort of like the identification that the community of identifiers agrees on. The algorithm we’ve come up with is a bit convoluted, but roughly, it chooses the taxon that more than 2/3 of identifiers agree with. You can see an example of this by appending test=cid to any observation added in the last week, e.g.
http://www.inaturalist.org/observations/505772?test=cid

(If you want the gory details on the algorithm click the “About” link beneath the community ID, or wade through the even more crazy diagrams at https://github.com/inaturalist/inaturalist/issues/88). So far we’re just calculating the community taxon without affecting any existing data or quality grade, but I think what we want to do is set the community taxon as the primary taxon affiliation for an observation, unless you opt out. This would mean that if you like the current system of personal control (as I do), you would have to set a preference saying you don’t want to automatically accept the community taxon as the taxon for your observation.

Assuming my verbose explanation was comprehensible, what do you guys think?

In these discussions, both Ken-Ichi and @loarie expressed some personal desire to be able to opt-out, and I think that explains why the option was there from the start. More generally, I think iNat power users of 2014 were conflicted between the clear need (from a community, identifier and research perspective) for a mechanism to determine the taxon based on the preponderance of input and their doubts (from an observer perspective) about whether they could really trust this process in all cases. (Interestingly, neither Ken-Ichi nor Scott appears to opt out by default currently, so I guess they grew to trust the process they created!)

My take on the above is that the opt-out exists primarily because knowledgeable users had doubts about whether they could always trust the Community ID logic, because they perhaps had some experiences with overconfident identifiers messing with their observations, and because they felt that making the logic optional provided a safety valve consistent with iNat’s respect for each user’s control over their data.

I’m not sure when iNat chose to make the Community ID opt-out an option in the settings for new users, but a non-negligible portion of new users do enable this option. Given that an informed decision about opting out of Community ID requires one to understand quite a bit about how IDs combine to determine the community taxon, it seems reasonable to assume that most new users make this decision based on “gut feelings” about privacy and don’t understand the implications.

I find dealing with orphaned and incorrect observations from opted out users to be a minor annoyance at worst. I add my ID plus a comment using a text macro and move on.

It looks like you may have opted out of community ID, so other users’ suggestions won’t change how iNat identifies this observation. If you opt back in to community ID, this observation has a good chance to reach research grade.

The concern I have is that this issue (mistakenly letting new users opt-out of Community ID) is one of maybe a dozen other UI-related issues that all combine to make iNat harder for new users to understand, degrade the quality of observation data and decrease the efficiency of identifiers’ time. Most of these issues have been known for at least three years (some for more like ten), and there seems to be no progress on addressing them. [I’m not going to list my top ten here, but I’d be glad to contribute to a prioritization process when the dev team is ready to start taking these on.]

Now I know that iNat has prioritized things like site stability (absolutely essential to deal with the exponential growth; in 2013 there were 300,000 observations vs 140 million today), mobile apps, computer vision (transformative!), educational and community development, and multi-lingual global access. Necessarily, a site used by a few thousand English-speaking nature nerds could innovate more quickly than the world’s biggest global citizen science platform. But I do feel that retaining and developing identifiers (and observers) is going to require making the UI seamless and bullet-proof beyond where we are today. I’m also confident that many of these UI and process fixes have been throughly hashed out in Feature Request discussions, stem naturally from the maxim of “least astonishment” and can be reliably guided by the voluminous dataset within iNat.

I would love to see a more open process of assessing candidate features and selecting them to receive limited development resources, so that the ever-growing community of experienced iNat users has some understanding about what improvements to expect, and why their pet features may have to wait.

10 Likes

I appreciate that I am removed from this list, though I see several people on there who I can vouch for as being “trustworthy” as well. I am unsure if this list really helps in the end more than it hurts the ID of genuinely valuable observations. I guess I cannot say.

4 Likes

Thank you for the offer. I use macOS—and mostly R, for this kind of thing—so an exe wouldn’t be much help. I don’t suppose you could point me in the direction of resources for interacting with the iNaturalist API in R, though? I work well with tabular data, but APIs are foreign to me.

I think this, err…, blacklist will help @jeanphilippeb and a few others who are frustrated when they encounter an opted-out observation. And it will have very little effect more broadly because most identifiers will be unaware of it or unbothered by this issue.

Personally, I’m already adding more than enough URL filter terms to my searches, but I appreciate Jean Philippe’s ingenuity. Even though I’m no fan of the community ID opt-out, I would strongly oppose implementing this exclusion in the UI. Fortunately, the chance of that occurring is vanishingly small.

Sorry, I can’t help. I even don’t know what R is. I develop in C# and had to find out how to sent the requests to API (and I had to search again how to do it when using https became mandatory, about one year ago).

1 Like

The point (for me) is not at all judging if people had a good reason to opt-out. The point is, as an identifier, if I like or not to spent time on observations that will remain in the same state (= still calling for more IDs) after I ID them.

In other words, I think that an expert who needs full control of the Community Taxon should opt out but should (consistently) not be “calling” for more IDs, which means being registered in an exclusion list, as there is no other way to do it.

I removed your login from the project rules just because @dianastuder suggested to do so, but I didn’t understand the reason.


In the early times of iNat, as well as now when opt-ing out, IDs from other persons are just like informal comments meaning “I think this might be this… don’t you think so?”. If you are an expert wanting to protect your observations from a bad Community Taxon, then you don’t need comments like “I think this might be this… don’t you think so?”, then it’s fine if your observations get “black listed” (just by identifiers and just while identifying). Isn’t it?

IDs are not supposed to be informal, they are supposed to be bold (see the 1st point in the identification etiquette).


In short, this is just a matter of being consistent.

Maybe I ought not to remove your login from the rules of this project, for consistency and for clarifying. For me the point is clearly not discriminating some observers from others (depending on the reasons they have, or not).

4 Likes

Background info is interesting. For South African observers who moved from iSpot to iNat (not me, before my time) it was an adjustment from IDs scored by reputation to iNat we are all equal (unless we opt out then I win, every time :smile:

May I tweak your opt out copypasta and use it?

All I want, is to see - as we do with ‘Casual’ - this is Opted Out - before I put time and effort into What is it??

I don’t need a filter, but in the same way that identifiers can choose not to see Cultivated / Captive, we should be able to choose not see Opted Out.

5 Likes

The point (for me) is not at all judging if people had a good reason to opt-out. The point is, as an identifier , if I like or not to spent time on observations that will remain in the same state (= still calling for more IDs) after I ID them.

Admittedly for me, a “good reason” for opting-out would not result in observations remaining in the same state after ID, generally speaking. Though if you’re referring to this short window (between the observer updating the ID from when you add the ID), I understand. For me it is rarely more than a matter of hours to see the suggestion and update my observation, because I like to be on top of things. For them it may be a day or more due to working lives.

Due to my personal workflow, this is a contrast to those who just do not update their observations at all, or take weeks or months to do so. That’s where I see your exclusion list being the most useful.

1 Like

No worries. Figured it was worth asking. :-)

1 Like

Of course! I’m sure it can be improved, maybe with a link to some guidance?

I feel that a checkbox to exclude Opted Out observations is the same as a filter, but I understand why some would want this.

1 Like

I shall try this, with tweaking to fit each obs. Would like a kind tutorial about opting out, but there is only a brief paragraph in the help guidelines. Since I focus on mid-level IDs and trying to get obs to where taxon specialists can see them, I start with Unknowns and Kingdom Disagreement and broad planty IDs. If I can get it to Family at least, the IDs trickle in as I watch! After languishing for as long as five years …

Since you have opted out of Community ID, taxon identifiers can’t filter for your observation. If you would opt back in to Community ID, you would get a better ID.

https://forum.inaturalist.org/t/opting-out-of-community-taxon/38062

1 Like

I’ve added your recommendation to my file of iNaturalist responses.

1 Like