Platform:
App version number, if a mobile app issue:
Browser, if a website issue: vivaldi (chrome)
URLs (aka web addresses) of any relevant observations or pages:
Screenshots of what you are seeing:
Description of problem: When an observation is mistakenly tagged as “No Flowers Or Fruits”, you can´t edit this until the person that did it removed it. The website only shows an error message: “Failed to save record. Please try again later.”
Step 1:
Step 2:
Step 3:
https://forum.inaturalist.org/t/make-annotations-correctable-not-just-marked-disagree/34660
Feature request. Under Review. From August 2022 ! With 148 votes. This is still a burning issue.
just to clarify this a bit, you are able to:
also, if the person who added the annotation is not the observer, the observer can remove the annotation altogether (not just downvote it).
the only edit you can’t make here is adding a different annotation related to flowering or fruiting when No Flowers or Fruits is present. (i think this is true even if the annotation has been downvoted enough to effectively negate that annotation.)
i think what the system is trying to do is to prevent you from adding another annotation that would logically conflict with the existing one. (if there are No Flowers or Fruits, it can’t also have Flowers or Fruits.) if you look at the underlying error returned by the API, it’s code 422 (Controlled value blocked by another value).
in my mind, the system’s interfaces should not allow you to select a logically conflicting annotation in the first place, such as is already implemented for other cases. for example, here’s an observation that was annotated as Flowering, and you can’t select No Flowers for Fruits:
but i guess to make the underlying error more available to regular users, the screen should probably show the underlying error rather than just throwing up a generic “Failed to Save Record” message.
i’m not sure what’s proposed in this feature request is necessarily the best way to handle the problem of incorrect annotations. the current implementation of the annotation system suggests that iNat overseers wanted to allow the community to come to a consensus for annotations, not to allow individiual non-observer users to annotate by edit war.
the current annotation consensus implementation obviously has shortcomings. those could be fixed by making the voting mechanism more complex, but i’m not sure that’s worth the effort and overhead to make that happen, since relatively few observations are annotated and even fewer have disagreements on those annotations.
That is difficult for me to understand. Shall we abandon all annotations ? I annotate all my own obs – especially since @annkatrinrose pointed out that most flowering plants are not annotated as such. I also annotate as I ID, but not not all the things everywhere, mostly fruit or larva.
And frankly 148 votes says many iNatters would like the issue to be resolved more effectively. Now it is broken.
but it does NOT allow consensus. The first annotation, right or wrong, has won.
to be clear, what i described as the more complex voting mechanism is not what the feature request you envisioned is requesting. your request seems to be suggesting an abandonment of any consensus algorithm altogether and moving towards any random user being able to decide the annotations, as is possible with the observation fields. (that requested mechanism is what i characterize as the edit war mechanism.)
I was thinking of the DQA - is it Wild or Not - where we have consensus.
So No flowers or fruit, would be set against Flowers and / or Fruit.
The feature request is from @megachile, not me
that may be what you’re thinking about, and that’s actually closer to the more complex voting mechanism i’m describing, but that’s not what your referenced thread contemplates.
Let us achieve consensus for Annotations, as we do for IDs and DQA. Observation fields are a free for all, but iNat controls Annotations.
i don’t disagree with this necessarily, but it might be better discussed in a new feature request.
i think the fastest route to addressing the specific issue covered in this current thread is:
and then optionally:
No Flowers or Fruits is supposed to block other values for that annotation, so the setting is correct, and there shouldn’t be an option to add another. I believe this was the case a while ago, I wonder if this is a bug related to the switch to API v2 and none of us ever noticed. I’ve made an issue.
