Those are reasonable concerns, but I think they’re fixable. While investigating notification options, I was reminded that iNat lets you opt out of notifications for confirming IDs. That should avoid your getting “notifications from other users chiming in subsequently, which in most cases will not do anything to the community ID because they are correct.”
Your second concern seems largely to be about knock-on effects of mitigating the first issue. If you turn off notifications for Confirming IDs, then this should be a moot point. I agree that making a case-by-case decision about which observation might later attract erroneous IDs would be both ineffective and onerous.
For comparison I’ll share my experience, as it looks like we make a similar number of identifications. I do choose to agree with many existing RG IDs for a lot of the reasons discussed in this thread. I also (currently) choose to get notification of confirming IDs. My experience is that I typically get about 10–30 iNat notifications on an average day. My workflow is to open up each in a new tab and take a quick look. It usually takes me just a few minutes to check that there’s no action I need to take on all or most of these. If I chose to disable confirming IDs, I’m guessing that notification count would drop to about 20% of the current level.
I guess I would suggest trying something like this approach to see if it works better than your current workflow. If it’s no improvement, you can shift back at any time!
I think it’s okay if people have diferent workflows, getting a few notifications about reviewed once instead of tons of notifictions for agreed once sounds cool. I get 200 notifications each morning, then a lot of through the day, I hover by them to see current comunity taxon and check those that are higher than expected, if I were agreeing with everything instead of adding only new-level ids, it’d mean much more notifications. Disabling agreeings is probably ok for those who don’t observe, for now there’s no separation, so it’d mean you will have no idea some of your observations got attention too. As you see many voted for this request, you can’t expect all them having no observations of their own and no interest in them.
Sorry if I gave the wrong impression. I definitely agree that it’s fine for people to use whatever workflow serves them best. And having the option for the reviewed flag to be automatically turned off based on subsequent IDs is fine with me. I’m just recognizing that Feature Requests typically take quite a long time to be implemented (if at all) and an alternative workflow might give the OP a way to resolve the underlying issue without the negative effects one might assume.
Thanks for your suggestion, i appreciate your time. I could simply turn off notifications for confirming IDs, but just like i wouldn’t want to receive hundreds of agreeing notifications, i’m sure others wouldn’t either and by giving so many agreeing IDs each time, i will inadvertently be flooding others’ notifications as well. Also, i’m not sure how much of this affects the speed at which this website runs, but i’m sure that a lot of people agreeing and having thousands of notifications sent out to all those involved should affect something (correct me if i’m mistaken), so if i can minimise that, then that’s great (i forgot to mention that this is another reason why i’m often reluctant to give agreeing IDs). So unless everyone has already set notifications for confirming IDs to off, i don’t think i will be doing this anytime soon, even though it might be a viable temporary solution. I should stress again that this is a personal preference of mine and i also respect that not everyone feels the same way
Hi again. I appreciate your concerns, but I’d suggest that you don’t need to worry too much about the potential impact of additional agreeing identifications on site performance or on other users.
iNat staff have been clear about those actions that have significant performance impact (e.g. creating large new places, or taxon merges and splits that cascade to affect many observations and previous IDs). The site has more than 100 million IDs and adding a few more won’t have a detectable impact. It’s great that you’re thinking about the potential for causing performance problems, but you can be confident that routine actions don’t carry that risk.
As to the impact on observers from receiving additional ID confirmations, that might be less than you think. If you’re knowledgable enough to provide an ID and took the time to see whether the current ID is correct, then sharing that with the observer has real value and will often provide more certainty than they’ll have on their own. As intended, most iNat users are people with a general interest in nature, and the person that provided the first confirming ID may be their friend or someone with less specialist knowledge than you. When I upload observations from a hike I’m glad to get confirming IDs (one or multiple), and my experience has been that’s the case among other iNat users almost without exception.
But it’s still 100% your choice as to what workflow works for you. Even if agreeing to existing RG IDs has very little downside, you’re absolutely free to limit your IDs to those that fix or refine the Community ID. Thanks for engaging here and for raising this suggestion.
The planned (and delayed, I’m sorry) notifications revamp should address the major issues brought up here - namely being notified if the data quality grade of an obseration you’re following changed (eg research grade back to needs ID) and provide a central and searchable location for your last few months of notifications.
To me it sounds like a keyboard shorcut for “Follow this observation” might be a better solution. Then it would take just two keystrokes to mark as reviewed and to follow the observation.
Thanks @tiwane. I’m happy to hear that the notifications revamp is still an active development item. I do like the idea of being able to review a history of notifications. And notifications specifically for a data quality change will be very helpful. A keyboard shortcut to follow the observation seems like a good addition to serve those who prefer not to add redundant confirming IDs.
