Research Grade with only one ID at that rank

[spiphany]

@tiwane

I suspect this wouldn’t be a common case? And can be remedied with a Yes vote for now.

Not all that uncommon, no. And a “yes” vote in the DQA is a bad solution.

A lot of what I ID falls in the category of “often cannot be ID’d to species based on photos”. In many cases there are various levels between genus and species to help narrow down the ID. It is not unusual for an observation to end up with multiple IDs at different levels, depending on how good the IDers are at understanding which of these finer categories they need to use if the possibilities can be narrowed beyond genus but not to a single species.

If people are using the DQA to make observations RG above species level as part of managing workflows or cleaning up a difficult taxon, any of the following may occur:

1 or more ID at genus, 1 ID at subgenus, DQA “ID cannot be improved” because the IDer wants to take the observation out of “needs ID” and may not be paying attention to whether the community ID is the same as the observation ID.

2 IDs at genus, second IDer clicks the DQA, a third IDer comes along and suggests a subgenus. “ID cannot be improved” to make the observation RG would still be correct because a species ID is not realistic. Clicking “yes” to keep the observation from becoming casual is exactly the opposite of what one wants to do here.

1 ID to species, 1 non-disagreeing ID of genus, a 3rd ID to subgenus disagreeing with the species ID, DQA. First person withdraws their ID or adds a genus-level ID.

In all of these situations the observations now become casual. They should never be casual because they are not broken – there is nothing wrong with them except that the community ID and observation ID are not the same. They should remain at needs ID.

This change is not a minor side-effect of a fix for issues with how subspecies are treated. It has a huge impact on my regular IDing workflow for my ongoing attempt to clean up European Xylocopa observations and it seriously hampers the effectiveness of any strategy to try to manage the needs ID pile.

I also suspect it will result in affected observations becoming casual because a user didn’t happen to notice the effect of their action, and these observations are unlikely to ever get rescued because so few people look at casual observations.

As I wrote elsewhere, I think other changes will need to be implemented alongside this change in order to prevent it from creating new problems:

@spiphany

It seems that what we need is for the DQA to only be active (both in terms of being votable and in terms of how it affects the observation) as long as the community ID is the same as the observation ID. But note that this would leave us without a way to deal with opted-out observations that the community has tried in vain to refine, so maybe there would need to be an exception (I think this would be covered by something like “community ID must be the same as or more specific than the observation ID” but I would need to work through more possible scenarios).