Make impossible the deletion of committed taxon changes

In the same way that it is impossible to delete a taxon with associated identifications or an associated taxonomic change, I am requesting that it be made impossible to delete a taxonomic change that has been committed.

Several times now, I have left a comment on a taxon change asking a question about it only to find later that someone has deleted it, presumably under the mistaken assumption that it will fix a mistake, or perhaps just in an attempt to hide it. This makes a change hard to reverse, since it can’t really be pointed out anymore, and difficult to keep track of, since there is no longer much record of it having happened. Additionally, I see no benefit to being able to do this sort of deletion since it only destroys information without conferring a benefit.

No longer allowing the deletion of committed taxonomic changes would maintain greater information about curatorial activity, and I believe would benefit the community.

re: “someone has deleted it”

Do you mean they deleted a taxon change or only deleted a record of it along with your comment?

“that makes a change hard to reverse”

Do you mean a change has been committed but the fact that it’s been committed has been obscured?

Just to clarify, are you suggesting that a taxon that has been swapped/merged/split should no longer be open to further swaps/merges/splits etc? Sorry if it’s a dumb question, I just don’t understand what you mean by “delete”

Deleted in the sense that when you go to the page for the taxon change, it says there is nothing there (e.g., It is hard to give a concrete example, which is exactly the point I was trying to make above. The only evidence left of this swap, as far as I can tell, is the ID changes like here: This shows that the swap was indeed committed, and if you click the link, it goes to the same swap I cited above, but all you see is the search mole. The fact that the changed IDs remain also indicates it was not reverted then deleted, but was just deleted after it was committed.

I am not trying to say taxa that have undergone a change should not be changed again; I am saying the concrete evidence of any change should not be deletable.


Yeah, that seems reasonable. Keeping a history of changes makes sense


You may know this, but there are also taxon change notification pages which can be commented on, at least if a user follows the taxon prior. I’m unsure if those are saved. As for the feature request, I see a benefit of keeping track of changes which affect things. The only exception would be if there are circumstances where a change was made briefly in error and fixed immediately (if that’s possible to occur without changing things permanently; I haven’t yet made direct taxon changes).

Given this topic, I’d also suggest taxon changes which are likely to be debated, or which are so complex as to be slightly uncertain, should be things all curators are made aware of and given time to review and comment on, before being made. Because it seems like you refer or imply things partly about taxon change errors, or the fact that in some cases many curators may disagree with changes some are making.

What do you mean by

? Could you give an example?

Curators cannot undo a mistaken taxon swap on their own; it just is not possible. The mechanism by which it is undone involves contacting site staff and having them revert it which removes the IDs created by the swap and reinstates previous IDs. The swap itself is reverted to a draft. I don’t really care if such a draft were deleted, though they are often good places to have a conversation about why it was reverted, and what needs doing. My issue is with committed, unreverted swaps being deleted.

For the second part of your comment, I think this is a separate issue best discussed elsewhere, as it isn’t directly related to this feature request.


Taxon change example (comments can be added at bottom). These show up in notification feeds if you’re subscribed to applicable taxa. I just noticed individual taxon changes link to a searchable listing of 3,132 taxon changes. If this solves the issue, this topic could be moved to bug reports as solved.

Observations/flags/etc. you’ve commented on. I was previously using this as a way to re-find changes I’d commented on. (Anyone know how to find the above taxon changes listing when starting from the homepage?)

Good call - I’m trying to think of an example situation where we’d want to be able to delete a committed change and coming up short… even a staff-reverted change can (should) always be clarified to say in the description that it was reverted.


Related, I’ve heard some curators suggest on forum that iNat taxon changes typically be accompanied by comments providing citations but also further info. when applicable (e.g. locations where it occurs, ID details to distinguish from similar spp., how common vs. rare it is). I sometimes paste an excerpt from the cited source (in curation requests/taxon changes). Considering that some of the issues seem to relate to the justification for complex, contested, or changed taxon changes, I suggest that more vs. less info. be given specifically for those kinds of taxon changes. It can also help to raise the coming intended taxon change before committing it (or in forum), to give others time to review and discuss (e.g. if they disagree or would like to further confirm the source).

1 Like

Okay, this is what I thought you meant. It is precisely this page being deleted; you can see that the format of the link you supplied and that which I supplied which shows only the search mole are identical. Once deleted, it also no longer appears in the list of taxon changes; note that the most recent ID numbers for taxon swaps are near 100,000, but only ~30*3132~=94000 are visible when searching taxon changes. Similarly, once deleted there is no record of any comments on the taxon change, since it no longer exists.

Again, while this is a good idea, this is not relevant to the feature request and is best discussed elsewhere.

1 Like

I assume by page deleted we each mean an individual taxon change page is deleted and so it no longer shows up on the larger page that has records of all the taxon changes. I don’t know if your original links have enough information for me to check if the search filter can find it. If you haven’t already I recommend trying to search using filters for taxonomic group, trying different search settings, to ensure it’s deleted. If it turns out some are deleted, someone else would have to determine what the plan is for it, or may know how often or why it happens.

Yes, I understand that there is not much available information in the links I gave…which is entirely the point. It should not be possible to just delete that information. I can assure you that there is nothing left for search filters to find. Site staff might be able to see something on their end, but exchanges I have had in the past with them suggest this is not the case.

Thank you for your advice, but I am quite familiar with taxonomic changes; I have committed over 8000 of them, including some mistakes of my own that I had to go through the process of fixing. I know that this one and others I have commented on have been deleted. Though I can’t say confidently by whom or for what reason, the point I am trying to make here is that is shouldn’t be possible in the first place.


The remains of another two deleted swaps can be seen here: A swap of Lundia longa into Lundia cordata was committed two years ago (, And another swap in the opposite direction was committed six days ago ( Both were deleted.


We might also wonder if some, all, or none of the deletions are occurring unintentionally via some system process, or unknowingly in some taxon or framework changes made by curators. In which case this could also be a bug request. Unless all the deletions were just made intentionally by curators.

1 Like

This should be deployed next week.


OK, it should now be impossible to delete committed taxon changes.


I’m seeing a Delete button on uncommitted changes, but not on committed changes. So I think this one is solved and done. Thanks @kueda for the quick work on this one!