Taxon swap results in permanent maverick IDs when identifier is blocked

One genus was recently transferred to another, after which I realized I had a number of maverick identifications. Apparently, a somewhat prolific observer of that genus blocked me. When the taxon swap happened, my previously correct identifications were not swapped, making them maverick. I cannot withdraw the identifications. I don’t know whether this is working as intended, in which case I would want to create a feature request to allow for withdrawing maverick observations when blocked, or if I should submit a bug report.

Is this working as intended, or is this an unintentional side effect?

8 Likes

Wait, someone blocked you from adding IDs?

1 Like

A user can block another user for any reason: https://help.inaturalist.org/en/support/solutions/articles/151000173516-what-are-muting-and-blocking-how-do-i-block-or-mute-another-account-

It does seem like IDs not automatically updating is an undesired effect of blocking, though I think it might be tricky to fix, since taxonomy updates are implemented by withdrawing the old ID and adding a new one, and blocking prevents the blocked user from adding IDs.

Perhaps it would make sense to make it possible for blocked users to withdraw or delete existing content on the observations of the person who blocked them, but not interact in any other way. I am finding it difficult to imagine a situation where removal of content by the blocked user would be felt to be problematic by the blocker.

13 Likes

I agree that this isn’t optimal behavior - I think it would make sense to allow the taxon update function to proceed as normal when handling IDs regardless of whether a user is blocked or not - the blocked user is not taking an action here, iNat is.

That said, I am unsure about allowing users to withdraw or delete content once they have been blocked. A user could act vengefully against someone who blocked them by deleting any helpful IDs that they have made for that person for instance which wouldn’t be great. Additionally, deleting in general is not optimal on iNat as deleted comments and IDs make the flow of conversation/identification confusing. Withdrawal is less of an issue.

1 Like

As I’ve mentioned on other occasions, I’m very much not a fan of deletion – at least, not the way it is currently handled. But the possibility of deleting content already exists, whether we like it or not; I am not suggesting adding any function that wouldn’t be available if the user were not blocked.

There may be better solutions to the problem that motivated this thread, but my thought process here was as follows: Blocking is presumably normally the result of negative interactions between two users to an extent that one user doesn’t want future interactions. Blocking has significant enough ramifications that I find it hard to imagine circumstances that would result in blocking someone whose past input one values and wants to keep while not wanting future input.

If the actions of the blocked user happened by mistake or in an ill-considered moment, it is possible that they would want to make amends but are unable to do so because they are blocked. E.g., I believe people have mentioned getting blocked because they made a bad ID, which they then become unable to fix. So being able to withdraw IDs might allow for a path to resolution of conflicts, as well as solving the problem of what happens to IDs that are no longer valid due to taxon changes.

Allowing blocked users to edit comments seems problematic, as it could be used as a way to continue to attack or provoke the blocker. But if the blocking was motivated by comments that inadvertently caused offense, it is conceivable that the blocked user might wish to remove the offensive content; if they cannot edit, the only other way to make this possible would be to allow for deletion of comments. (I suppose an alternative might be something like flagging their own comment and asking for it to be hidden.)

The thing about blocking is that it involves a certain power imbalance between the blocker and the blockee. In a lot of cases this may be desirable (e.g. if it enables a vulnerable person to protect themselves), but blocking can also be abused. Not allowing the blocked user to continue to interact with the blocker is reasonable, but taking away the blocked user’s agency over their own IDs – to force them to permanently have an ID attributed to them which they cannot even withdraw – seems to me to be more questionable.

It is possible that I am overlooking constellations that would make the “freezing” of past contributions by blocked users desirable or advisable.

5 Likes

Well, look at it in the reverse situation (which I have seen): an identifier opts out of taxonomy updates. Then, an observation which had made RG is knocked back to Needs ID after a taxon swap because one of the two previously agreeing IDs doesn’t update. If this happened on one of my observations, I would not be happy with the opted-out identifier; they just might find me in their inbox.

How is this the reverse situation? The identifier has made a choice not to accept taxonomy updates. I agree that it is annoying, but it can be changed – by communicating with the identifier. When a user is blocked there is no possibility for communication.

Higher-level taxonomy changes can affect observations even if the IDer is not opted out. Observers do not have control over what IDs are added to their observations. Sometimes this results in the status of an observation changing. If one isn’t prepared to accept this, one can opt out of community ID.

The fact that a blocked identifiers IDs are not updated after taxonomy changes is not just a problem for the IDers – it affects the observations, too.

And they are imposing that choice on every observer for whom they identify. This is different from the observer not having control over what IDs are added, because at any given noment, the only IDs that can be added are the active taxa.

There is a difference between not wanting to accept the community ID and not wanting to be stuck with inactive taxa.

1 Like

I am not a fan of opting out in general. I think it tends to cause more problems than it solves and it clogs up the ID process. My personal feeling is that it is also not really in the spirit of the community aspects of iNat. (The only possible use I see for it is as a temporary measure for individual observations that have gotten off track because of a wildly wrong ID by an unresponsive user).

However, a user opting out of taxon updates is not analogous to the situation created by blocking. If anything, it is analogous to an observer universally opting out of community taxon.

It is true that

but this is not at all the same thing as an action that prevents another user from being able to change content that they entered themselves, which is precisely what is happening with blocking.

The observer does not own other people’s IDs on their observations. Any ID is in essence the IDer “imposing their choice” on the observations they interact with, whether the taxa in question are active or not, because an ID involves certain decisions about what sort of evidence is required, what possibilities need to be considered in a particular place, etc. IDs that hinder a community consensus are annoying, regardless of the reason, but they do not fundamentally restrict other people’s freedom of action, and it is always still possible for users to communicate to resolve the situation.

My understanding is that users who have opted out of automatic taxon updates can choose to opt back in for individual taxon changes and will often do so; unfortunately it is easy to miss taxon updates because they appear on one’s dashboard but there is no separate notification.

2 Likes

relatedly, is there a way to bulk remove my IDs of an entire taxa? Some of the taxonomic changes that have been forced on the site has made all old IDs pretty much unusable, i don’t agree with the new taxonomy and don’t appreciate getting 100 notifications about the same issue with the people who have broken the latest keystone species into an undifferentiable mess. I’d like to just delete all those IDs for others as there’s no point any more.

2 Likes

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.