So I propose a working solution? If DQA is marked as “no” for “ID can be improved” and someone adds a finer ID, that should automatically generate a vote “yes” that “ID can be improved” on behalf of the person who adds the finer ID.
Alternatively, the community ID vote would ideally be attached to the ID and not the observation as an attribute … ;)
I don’t think this
is correct. There’s also the related case where a user has opted out of community ID and their ID disagrees with the CID. If the “good as can be” box is ticked in this scenario, I believe that the observation also goes to Casual.
This is also unfortunate and has been discussed previously, since the CID is often at some level that could be Research Grade. But I think staff have described the current implementation as giving primacy/agency to the observer and their preferences.
The whole system in general has issues. Why does there need to be extra steps to get something RG just becuase it isn’t species? It’s a chore when your group commonly can only get identified to certain levels like tribe, genus, etc. Though some have it worse. Why is something “as good as it can be” above family ineligible for RG?
From my experience the current system is a chore and leads to most of my group not being RG. 10s of 1000s of obs could be RG at subfamily, tribe, genus group etc.
I doubt a perfect solution exists, I also am not sure what specific changes could be made in general to “as good as it can be” to improve it.
I agree this would be a big improvement, but the case described here:
would still be an issue.
I think this would be wonderful
My understanding is because GBIF (and maybe other data-sharing partners?) doesn’t want family-level and higher records being exported to them; they don’t find the vast majority of that level of data to be useful. So if they don’t want it, but it’s not worth further consideration for ID work, into the Casual dump it goes. I don’t know how I feel about this; on the one hand, some cobwebs as evidence that an unidentifiable spider was in my house is not really useful to anyone as a datapoint for anything, but it also seems wrong to lump it in with the data-deficient and Cultivated stuff.
IMO,
^ this is the best solution, but I’m sure it would be difficult to implement. I envision it as an observation reaching RG above species if it gets two uncontested IDs that both have “cannot be improved” attached to them. If someone adds a finer ID, then that counts as a vote for “can be improved”, and it goes back to Needs ID. If a fourth person comes in and also adds the broad ID with “cannot be improved”, then it goes back to RG with the person who added the more specific ID being labeled Maverick. So there would be a parallel CID system running for “can/cannot be improved” alongside the regular CID system we have now.
Which, if correct, is utterly nuts.
It is for GBIF and other consumers of iNaturalist data to implement filters to prevent family-level or whatever IDs getting imported into their systems, NOT for iNaturalist to implement contortionist-level behaviour that produces nonsensical outcomes as described in this thread.
To be clear the rule causing most of the behavior described in this thread (an observation whose community taxon and observation taxon don’t match becomes casual if there are more “No” votes than “Yes” votes in the “Can the ID be improved?” DQA item) is completely independent from the rule that family-level observations can’t become Research Grade, though I’m also not a fan of either of these.
I mean okay, but that case you described is the observer’s choice. The situation described in this thread is something entirely outside the observer’s control.
I would say it is somewhat outside the observer’s control as they can make their own ID and cast their own vote in the DQA. But the CID in general is somewhat outside the observer’s control - this is the case for many other aspects of any observation (annotations, observation fields, etc.) as community input matters. In fact, opting out of CID is one of few ways on iNat that an observer has to exercise total discretion/optionality over the community’s input. To me that is the exception rather than the rule.
Even if it’s not ideal at least in that case it is clear that there is some argument for the existing system. Having such an observation stay at Needs ID would lead to many identifiers wasting time leaving IDs with no potential of getting it out of the Needs ID pool. Sending it to Research Grade would either send over a taxon with no community consensus being exported to GBIF (in the case the observation ID is exported) or risk going against the observers wishes (in the case the community ID is exported).
It is not clear to me what if anything is gained by having observations like those OP describes get sent to Casual rather than Needs ID. I think the “can the community ID be improved?” DQA system needs to be overhauled (and ideally in the process they could give it a terser name :P) but a good bandage solution would be to completely disregard votes in the case the community ID does not match the observation ID.
If it was my observation, I would delete and reload.
It is in no way acceptable to send my (or anyone’s) completely good observation to casual over a refinement. This is a bug.
It’s not a bug and it was deliberately introduced relatively recently (see further up in the thread). It was a pretty unpopular change and I feel like it would have been fixed earlier if it weren’t so obscure than only extreme iNat nerds (i.e. the most valuable identifiers) notice it. Or perhaps the developers just have a principled framework for what observations are and how their statuses work that’s at odds with how the community understands them and they happen to conflict on this point in particular.
My take was that it was a quick and botched fix to a problem occurring in the opposite direction- that voting “can’t be improved” and then improving the ID made things show up as species-level and RG with only one species vote. So the idea was it’s better to have something go casual when it really shouldn’t than go RG and get exported when it really shouldn’t. Of course ideally it would actually go to Needs ID as expected. But I guess it’s up for debate whether the current undesirable behavior is technically an improvement over the previous undesirable behavior.
It’s a change that disproportionately affects taxa that cannot consistently be identified from photos. These taxa are not particularly few and not necessarily particularly obscure and may have thousands of observations.
In other words, it is exactly the same group of taxa that is not handled well by the CV.
My impression is that developers are either not familiar enough with these taxa to understand the ways the identification process and identification workflows are different from taxa where one can reasonably expect to determine the species the vast majority of the time, or they have not been able to come up with a concept for addressing the challenges such taxa pose. iNat’s identification system on the whole is strongly skewed towards the assumption that most observations will eventually get a species label.
This is my impression as well.
It also seems to have been intended at least in part to address the somewhat different situation of how the community taxon is calculated for observations where there are infraspecific IDs. In any case, the blog post in which the community was asked to provide input on possible alternatives to the current system focused almost exclusively on the issue of infraspecific IDs. (I will note that we have had no updates on current plans in this regard, either for infraspecific IDs or otherwise, since that time, though the blog post was several months ago.)
Given the discussions that played out at the time the “fix” was released and the initial non-announcement of the change, I don’t think staff were aware of the other undesired effects of the change at the time. I am not entirely certain that they fully understand the extent of the undesired effects now or how many observations are potentially affected.
Why delete when you can just check the “yes” box though?
I don’t use “As good as it can be” on my observations
Delete and reload after others have added an ID for you ?
No, thank you.
I my own experience with software development, it is not unusual for developers to have little ‘real world’ knowledge of how the software they work on is “supposed” to work. Even when they had a general, high level idea of how the product should work, but they frequently lacked detailed knowledge of how the actual user interacted with the software “in the trenches”. To some extent, this deficiency can be addressed if they develop software based on a set of detailed specifications.
A good organization will have someone making sure that those requirements specifications are very detailed and specific (covering edge cases, error conditions, etc), and verifiers who test that the finished product conforms to them.
Unfortunately, this is rarely the case (at least in my experience). Developers are left to make their best guess as to how the product should behave in these edge cases (if they consider them at all), and products are rolled out with only cursory testing (“Let the end user test it and provide feedback!”). If you’re lucky, your product/feature is coded by a conscientious developer who knows the application intimately and covers all the bases. If not, then well, you’re not.
Now, you could argue that this kind of thing shouldn’t be left to luck, but this is the world we live in.
One of the new staff is an identifier, so perhaps that will unfold better in future.
rounds
Any other workarounds?