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.
