Community Wishlist Survey 2023/Admins and patrollers/Enable removing block log entries entirely, not just redacting

From Meta, a Wikimedia project coordination wiki

Enable removing block log entries entirely, not just redacting

  • Problem: When an administrator perceives a wrong block and/or one considered incorrect by the local community, it is in the Block log history (Special:Log/block) of the user.
  • Proposed solution: The idea would be to delete this permanently, keeping only a record of correct and valid blocks.
  • Who would benefit: Everyone would benefit, as the history of incorrect blocks could be removed, in addition to the administrators being more cautious in the application of blocks that are in the local blocking policy.
  • More comments: The approved proposal would be implemented in all Wiki projects. Each local community would establish rules to remove the "block log" from users (obviously it would be for cases of wrong blocks).
  • Phabricator tickets:
  • Proposer: WikiFer msg 14:26, 5 February 2023 (UTC)[reply]

Discussion

Comment Comment Although it is possible to hide the blocking log, the suppression policy of each local community may not allow this use to hide a blocking considered incorrect. That's why I created this proposal, so that there would be no link with the suppressors. WikiFer msg 04:56, 6 February 2023 (UTC)[reply]

@WikiFer If I'm understanding you correctly, are you proposing a mechanism by which the community could collectively remove the log entry without requiring an admin/suppressor to be the one to enact the consensus? Samwalton9 (WMF) (talk) 10:42, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) The admin will still be responsible for clearing the lock log, but it wouldn't be considered a hide in the way suppressors use it. The consensus for applying this removal would be by consensus among local administrators. WikiFer msg 11:34, 6 February 2023 (UTC)[reply]
@WikiFer I'm not sure I understand your proposal and how it's different from what is currently possible - could you elaborate on what the difference is? Samwalton9 (WMF) (talk) 12:49, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) See this example here, it has the block log where a user was unblocked because another administrator objected to the block. My proposal is to remove this block log of user, leaving the his account without any blocking records. If it was unlocked because the lock was incorrect, it shouldn't be part of this history. WikiFer msg 13:03, 6 February 2023 (UTC)[reply]
@WikiFer Here you can see a test I just did where I removed blocks from the logs for my test account. Are you suggesting that the software should enable you to remove those log entries entirely, rather than have "removed" text in the log? Samwalton9 (WMF) (talk) 13:35, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) Exactly. The proposal is for the software to remove log entries of locks that the local community has deemed to be incorrect. In the example you showed, the lock configuration change is another log. The proposal is not to remove only text, but not to appear in the account history anymore. WikiFer msg 13:56, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) Another better example was this administrative war of blocking and unblocking this account only on December 30, 2020 on Portuguese Wikipedia. My proposal is to leave this entire history blank, as if there were no blocks. WikiFer msg 14:00, 6 February 2023 (UTC)[reply]
@WikiFer Gotcha. I've updated the proposal title to clarify this. Samwalton9 (WMF) (talk) 14:50, 6 February 2023 (UTC)[reply]
@Samwalton9 (WMF) @WikiFer Note that if you use RevDel (aka redaction) on all fields, the entry is completely hidden from the log. Only users who have the ability to change the visibility of the log entry will be able to see it, and they will see it as "([field] removed)". In this case that is only admins, but you can use suppression to hide it from them, too. Are we sure that doesn't satisfy the wish?
I don't think full proper deletion from the database is something that would be considered. We could add yet another layer of visibility, as in something above suppression, but is there really any point in doing that? MusikAnimal (WMF) (talk) 16:49, 6 February 2023 (UTC)[reply]
@MusikAnimal (WMF) In this example, it would be unfair for a person to have a history of having their account blocked due to an administrative war. I think that in situations like this, deleting database locks would resolve unfairness. WikiFer msg 16:58, 6 February 2023 (UTC)[reply]
@WikiFer "Deleting" isn't really a thing. I see now above you said you wanted something that worked without the assistance of suppression, but I still have the same concerns. We need a log of everything that happens. Anything done by an admin should be auitable by another admin. If we want it hidden from admins, use suppression. In your example, if you use RevisionDelete, the log entries are only visible to 49 users (and those users will see it as "hidden" and have to click through to see what actually happened). To everyone else (non-admins), they won't see the log entries at all. If suppression is used, it brings down the visibility to just three users, who again will see them as "hidden" and have to click through if they want more information. MusikAnimal (WMF) (talk) 17:02, 6 February 2023 (UTC)[reply]
@MusikAnimal (WMF) Oh, huh. I swear I tested looking at the Samwalton9Testing block log from a non-admin account and could still see the deleted logs, but now I'm looking again I don't see them, so maybe it was an account cache issue. I agree that there's not much else to be done if that's the current behaviour. Samwalton9 (WMF) (talk) 17:29, 6 February 2023 (UTC)[reply]
I'd like to hear confirmation from @WikiFer first, but I'm thinking this proposal could be archived as there are existing solutions. I'm unclear on why we would need the ability for admins to completely hide block log entries from other admins. Those other admins will see "[field] removed", and if they use the "Change visibility" link or check the deletion log, they will see the rationale which for this use case would say something like "accidental block". That is by design. All actions in MediaWiki are intended to be audited. Imagine a rogue admin who remove visibility of the blocks they made, and also the log entries of them changing the visibility.
As I said suppression can be used to hide the entries from admins, too, but I don't see the point as admins can already confirm the blocks are invalid. MusikAnimal (WMF) (talk) 18:57, 6 February 2023 (UTC)[reply]
@MusikAnimal (WMF) As I already opened the proposal, the ideal thing is for the community to manifest itself in a vote, since the tool for hiding administrators is just another blocking log, a new administrative action that can only be used if the username is incorrect, or the edit summary violates the local hiding policy. I believe that wrongs blocks should be removed from an account's history, and admins will be able to set this by consensus on each project. WikiFer msg 19:16, 6 February 2023 (UTC)[reply]
My point is that what you're proposing is already possible. I don't think anything new needs to be engineered. But, the proposal is actually already approved, so as it stands now it's going to voting. MusikAnimal (WMF) (talk) 17:22, 7 February 2023 (UTC)[reply]

I come to this discussion from a situation where this was an issue. I opposed because I agree that, as framed, leaving it solely to administrative discretion is too open a door to abuse.

But ... certainly someone who gets mistakenly blocked for a few hours after, say, 15 years of productive, block-free editing might be entitled to ask for this sort of expungement, which could be granted through community consensus and only a limited number of users (i.e., the OS team, maybe) could actually do it.

Maybe we'll consider that proposal next year. Daniel Case (talk) 02:37, 12 February 2023 (UTC)[reply]

I am that soldier! (Hi Daniel!) Yes, I would like my 15-year clean block log record back, please! Note also the provisions of the EU's General Data Protection Regulations. Included in the seven principles of GDPR are two that are very relevant: a) the requirement for accuracy (and the consequent right to have incorrect information amended or deleted!); and b) the principle of accountability (which means that Data Controllers need to ensure that they not only comply with the principles, but also have appropriate processes and records in place to demonstrate compliance.) Other jurisdictions have similar laws in place. Now, it may well be the case that RevDel meets those criteria (as only other delegated Data Controllers can see the logs), but the proposal should not be dismmised out of hand. Bastun (talk) 11:09, 13 February 2023 (UTC)[reply]

Voting