From Wikipedia, the free encyclopedia
Previous discussion at Wikipedia talk:Selective deletion

Revdel email in an edit summary?

I thought we revision-deleted email addresses given in edit summaries, particularly when it is from a throw-away IP such as Special:Contributions/2001:8F8:153D:447B:3DCD:6B3F:A44:C8C4. Before doing that I thought I would read the documentation to see what RD number I should use. Surely not RD4 Oversightable information? I'm not going to bother an oversighter for simple disruption like this? And if it were RD4, I can see the wise advice to not use RD4 but instead to just email oversight. If that is really intended, the documentation should say so. Johnuniq ( talk) 06:06, 20 April 2023 (UTC) reply

Revdel and block logs

  • Full previous discussion. It's very long so I've tried to summarise the relevant bits here.
  • In the above block review discussion on AN/I, it emerged that EEng's been the victim of some bad blocks. Users were quoting the length of EEng's block log as grounds to indef him. Ritchie333 remarked on how a high proportion of EEng's blocks weren't well founded, and I added that I wish we could edit people's block logs. Ritchie333 tested and found out that in fact we can, using REVDEL. On a technical level sysops can do this.
    Ivanvector challenged whether it would be appropriate because amending people's block logs would reduce sysop accountability, which is a fair and understandable concern, but I think that this use of REVDEL leaves the block in the performer's log. It only erases it from the target's log.
    The Wordsmith pointed out that on a policy level, we can't do this. WP:REVDEL says:

    Especially, RevisionDelete does not exist to remove "ordinary" offensive comments and incivility, or unwise choices of wording between users, nor to redact block log entries.

    My view is that many Wikipedia editors are living people, and WP:BLPDEL protects us. For some, having bad blocks in their block log has caused measurable harm and distress. I don't know whether it's harmed EEng because I haven't asked him; but I'm morally sure that it's harmed others.
    Therefore I'm minded to propose that we change WP:REVDEL to permit Arbcom, checkusers, and oversighters to modify block logs at their discretion, and sysops to amend block logs if there's consensus to do that at a community block review. That kind of change would need a community RfC, but I thought it best to ask for your thoughts and advice here before I start one.— S Marshall  T/ C 15:49, 14 January 2024 (UTC) reply
  • Thanks for the ping. I'm against removing anything, ever, from a sysop's action log (i.e. the log[s] of actions performed by the sysop), but it maybe was shown that it's possible to revdelete a log entry in a way that it's hidden in the user's block log but visible in the sysop's. I say maybe because it seemed to leave behind a database error, and so I think the jury remains out on whether or not we technically can do this without causing problems, but the discussion became silly and I stopped paying attention before that was resolved. I am not strictly opposed generally to removing actions from user logs (i.e. the log[s] of actions on the user), but this isn't the time to have this discussion, framed as it is not around what's good for the community but around something that EEng's circle of friends doesn't like. Bad cases make bad policy, and all that. Ivanvector ( Talk/ Edits) 19:13, 14 January 2024 (UTC) reply
    I am not now, nor have I ever been, a member of EEng's circle of friends.— S Marshall  T/ C 21:14, 14 January 2024 (UTC) reply
    I can confirm that -- we're bitter enemies. While Ivanvector licks his wounds, let's continue the useful discussion. I don't think it's necessary (or desirable, actually) to remove/revdel entries for "bad" blocks; rather, they should be annotated somehow. You'd think that an adjacent unblock entry saying, "Unjustified block, see ANI diff" would be enough, but there's plenty of evidence that there are people who don't take the trouble to notice such things. (If the determination of unjustified-ness comes only after the block's expired, a dummy 1-second block can be enacted with a description referring to the prior block. But then we're still back to: there are people who just don't notice.) I think it would be enough to modify a given block's descriptive text -- if people overlook an all-caps THIS BLOCK OVERTURNED right there in the block itself, then there's nothing we can do for them -- but I don't know if that's technically possible. An analogy would be modification of edit summaries, and that's not possible either (though I don't know if that's for technical reasons, policy reasons, or just dev laziness.) E Eng 00:07, 15 January 2024 (UTC) reply
  • I'm generally opposed to removing 'bad blocks', or at least I've never heard a solid proposal I'd agree with, and think that people should learn to properly contextualise them rather than just count them. I do just want to offer some insight on the technicals. I don't know what's going on with the error in ThisIsaTest's block log, however, I don't think it would work as it's described above, at least with the current software. If you remove the edit summary you'd still have a log entry for the user, and still a long list of blocks, but every non-admin will see no reason provided. And it will be exactly the same for the admin's log. For an example see the block log of 37.186.45.90 (the admin also shares this log). [1] You'd have admin-only access to the reasons (via the revdel log). Limiting access to admins seems of questionable added value to me. And by the way, a not-well-enough-known fact: log redactions have their own logs. Go to Special:Log and enter Special:Log/block (or any other log) as the target. [2] They can be very interesting on occasions. -- zzuuzz (talk) 01:59, 15 January 2024 (UTC) reply

Process for requesting revision undeletion

I couldn't find a description on this page of how a non-admin can request revision undeletion, short of contacting an admin directly. Some images with deleted versions don't actually meet RD1 -- usually because the image was tagged as non-free at some point, but is now free (e.g., copyright expired recently). Should we have a centralized process/tag for these? Wikiacc ( ) 21:48, 17 April 2024 (UTC) reply

I assume you mean file revisions deleted per F5. Those can be requested at Wikipedia:Requests for undeletion. —  JJMC89( T· C) 22:20, 21 April 2024 (UTC) reply
Thanks JJMC89. I'd like to add text to the main page (likely in the "Appeal and discussion of actions" section) to make this clear. Would the following text be an accurate description of existing policy?
To reverse uncontroversial revision-deletions made under RD5 or RD6 (including image revision-deletions under WP:F5), make a request at Wikipedia:Requests for undeletion.
Wikiacc ( ) 01:40, 22 April 2024 (UTC) reply
That seems reasonable to me. (Other cases are best discussed with the admin that performed the deletion.) —  JJMC89( T· C) 02:14, 22 April 2024 (UTC) reply
I’m not sure that revision deletions made under RD5/RD6 are currently eligible to be undone at WP:REFUND. I don’t recall seeing an RD5 revdel recently so I can’t comment fully on that specific case right now (although, if an admin has a valid reason for deleting something under the deletion policy, it seems like something that might need to be appealed in the normal way rather than being unilaterally undone by editor request). However, some of the revdels I’ve requested in the past have been to delete something that was missed when an admin performed an earlier revdel. Some of these were logged under RD6 (i.e., as correction of clear and obvious unintended mistakes in previous redactions), but these aren’t (imo) the type of redactions that should be able to be undone at WP:REFUND. All the best, ‍—‍ a smart kitten[ meow 06:55, 22 April 2024 (UTC) reply
Striking RD6. Since RD5 is supposed to incorporate the standard deletion policy, I'd think standard undeletion processes should apply (including REFUND when the deletion was uncontroversial). Wikiacc ( ) 21:58, 22 April 2024 (UTC) reply
I see where you’re coming from - my worry would be that the current wording might increase the scope of what revdels can be undeleted from what the current practices are, as to reverse uncontroversial revision-deletions made under RD5 could be read as implicitly stating that all revdels made under RD5 are uncontroversial and can be REFUNDed. My worry is that this is beyond what is current practice, and would therefore (in effect) represent a change to the policy. All the best, ‍—‍ a smart kitten[ meow 07:08, 26 April 2024 (UTC) reply

Point taken that my suggested wording is ambiguous in scope. How about this rewrite? @ A smart kitten:

To contest or reverse revision-deletions, discuss with the deleting admin. For revision-deletions made under RD5, you may instead follow standard undeletion processes:

Wikiacc ( ) 16:15, 27 April 2024 (UTC) reply

That looks mostly okay to me - just a few things that came to mind:
  1. I’d suggest potentially changing For speedy deletions or deletions that resulted from discussions, to something like If a discussion with the deleting admin fails to resolve the issue,: this takes out the term speedy deletions (which, as far as I’m aware, isn’t generally used to describe revdels), and also makes clear that a discussion with the deleting admin would generally be expected before filing a DRV.
  2. Would this be incorporated into #Appeal and discussion of actions? If so, would the existing paragraph there need to be modified at all?
  3. I’m not sure whether introducing DRV as a review forum for RD5 revdels would represent a change in policy or not — on the one hand, RD5 is for deletions made under the deletion policy; but on the other hand, WP:REVDEL currently states that revdel reviews should take place at WP:AN. I guess I’m neutral on this bit.
As a slight side note, do you mind if I drop a note at Wikipedia talk:Deletion review about this discussion?
All the best, ‍—‍ a smart kitten[ meow 20:01, 27 April 2024 (UTC) reply
@ A smart kitten: Strikeouts added. And yes, please go ahead and drop that note. To your specific points:
  1. I'd rather not codify that a discussion with the deleting admin must come before DRV. Pointing to WP:DRV allows the language there to take precedence -- as of now, discussing with the deleting admin is described as "good practice" but "not required".
  2. This language could go in "Appeal and discussion of actions" (probably above the existing text) or in a different section. I don't think the existing language needs to change.
  3. I'm also not sure; I'd just like the language to be consistent with current practice. If DRV is explicitly not for RD5 revdels then that should be made clear at WP:DRV.
Wikiacc ( ) 22:05, 27 April 2024 (UTC) reply
From Wikipedia, the free encyclopedia
Previous discussion at Wikipedia talk:Selective deletion

Revdel email in an edit summary?

I thought we revision-deleted email addresses given in edit summaries, particularly when it is from a throw-away IP such as Special:Contributions/2001:8F8:153D:447B:3DCD:6B3F:A44:C8C4. Before doing that I thought I would read the documentation to see what RD number I should use. Surely not RD4 Oversightable information? I'm not going to bother an oversighter for simple disruption like this? And if it were RD4, I can see the wise advice to not use RD4 but instead to just email oversight. If that is really intended, the documentation should say so. Johnuniq ( talk) 06:06, 20 April 2023 (UTC) reply

Revdel and block logs

  • Full previous discussion. It's very long so I've tried to summarise the relevant bits here.
  • In the above block review discussion on AN/I, it emerged that EEng's been the victim of some bad blocks. Users were quoting the length of EEng's block log as grounds to indef him. Ritchie333 remarked on how a high proportion of EEng's blocks weren't well founded, and I added that I wish we could edit people's block logs. Ritchie333 tested and found out that in fact we can, using REVDEL. On a technical level sysops can do this.
    Ivanvector challenged whether it would be appropriate because amending people's block logs would reduce sysop accountability, which is a fair and understandable concern, but I think that this use of REVDEL leaves the block in the performer's log. It only erases it from the target's log.
    The Wordsmith pointed out that on a policy level, we can't do this. WP:REVDEL says:

    Especially, RevisionDelete does not exist to remove "ordinary" offensive comments and incivility, or unwise choices of wording between users, nor to redact block log entries.

    My view is that many Wikipedia editors are living people, and WP:BLPDEL protects us. For some, having bad blocks in their block log has caused measurable harm and distress. I don't know whether it's harmed EEng because I haven't asked him; but I'm morally sure that it's harmed others.
    Therefore I'm minded to propose that we change WP:REVDEL to permit Arbcom, checkusers, and oversighters to modify block logs at their discretion, and sysops to amend block logs if there's consensus to do that at a community block review. That kind of change would need a community RfC, but I thought it best to ask for your thoughts and advice here before I start one.— S Marshall  T/ C 15:49, 14 January 2024 (UTC) reply
  • Thanks for the ping. I'm against removing anything, ever, from a sysop's action log (i.e. the log[s] of actions performed by the sysop), but it maybe was shown that it's possible to revdelete a log entry in a way that it's hidden in the user's block log but visible in the sysop's. I say maybe because it seemed to leave behind a database error, and so I think the jury remains out on whether or not we technically can do this without causing problems, but the discussion became silly and I stopped paying attention before that was resolved. I am not strictly opposed generally to removing actions from user logs (i.e. the log[s] of actions on the user), but this isn't the time to have this discussion, framed as it is not around what's good for the community but around something that EEng's circle of friends doesn't like. Bad cases make bad policy, and all that. Ivanvector ( Talk/ Edits) 19:13, 14 January 2024 (UTC) reply
    I am not now, nor have I ever been, a member of EEng's circle of friends.— S Marshall  T/ C 21:14, 14 January 2024 (UTC) reply
    I can confirm that -- we're bitter enemies. While Ivanvector licks his wounds, let's continue the useful discussion. I don't think it's necessary (or desirable, actually) to remove/revdel entries for "bad" blocks; rather, they should be annotated somehow. You'd think that an adjacent unblock entry saying, "Unjustified block, see ANI diff" would be enough, but there's plenty of evidence that there are people who don't take the trouble to notice such things. (If the determination of unjustified-ness comes only after the block's expired, a dummy 1-second block can be enacted with a description referring to the prior block. But then we're still back to: there are people who just don't notice.) I think it would be enough to modify a given block's descriptive text -- if people overlook an all-caps THIS BLOCK OVERTURNED right there in the block itself, then there's nothing we can do for them -- but I don't know if that's technically possible. An analogy would be modification of edit summaries, and that's not possible either (though I don't know if that's for technical reasons, policy reasons, or just dev laziness.) E Eng 00:07, 15 January 2024 (UTC) reply
  • I'm generally opposed to removing 'bad blocks', or at least I've never heard a solid proposal I'd agree with, and think that people should learn to properly contextualise them rather than just count them. I do just want to offer some insight on the technicals. I don't know what's going on with the error in ThisIsaTest's block log, however, I don't think it would work as it's described above, at least with the current software. If you remove the edit summary you'd still have a log entry for the user, and still a long list of blocks, but every non-admin will see no reason provided. And it will be exactly the same for the admin's log. For an example see the block log of 37.186.45.90 (the admin also shares this log). [1] You'd have admin-only access to the reasons (via the revdel log). Limiting access to admins seems of questionable added value to me. And by the way, a not-well-enough-known fact: log redactions have their own logs. Go to Special:Log and enter Special:Log/block (or any other log) as the target. [2] They can be very interesting on occasions. -- zzuuzz (talk) 01:59, 15 January 2024 (UTC) reply

Process for requesting revision undeletion

I couldn't find a description on this page of how a non-admin can request revision undeletion, short of contacting an admin directly. Some images with deleted versions don't actually meet RD1 -- usually because the image was tagged as non-free at some point, but is now free (e.g., copyright expired recently). Should we have a centralized process/tag for these? Wikiacc ( ) 21:48, 17 April 2024 (UTC) reply

I assume you mean file revisions deleted per F5. Those can be requested at Wikipedia:Requests for undeletion. —  JJMC89( T· C) 22:20, 21 April 2024 (UTC) reply
Thanks JJMC89. I'd like to add text to the main page (likely in the "Appeal and discussion of actions" section) to make this clear. Would the following text be an accurate description of existing policy?
To reverse uncontroversial revision-deletions made under RD5 or RD6 (including image revision-deletions under WP:F5), make a request at Wikipedia:Requests for undeletion.
Wikiacc ( ) 01:40, 22 April 2024 (UTC) reply
That seems reasonable to me. (Other cases are best discussed with the admin that performed the deletion.) —  JJMC89( T· C) 02:14, 22 April 2024 (UTC) reply
I’m not sure that revision deletions made under RD5/RD6 are currently eligible to be undone at WP:REFUND. I don’t recall seeing an RD5 revdel recently so I can’t comment fully on that specific case right now (although, if an admin has a valid reason for deleting something under the deletion policy, it seems like something that might need to be appealed in the normal way rather than being unilaterally undone by editor request). However, some of the revdels I’ve requested in the past have been to delete something that was missed when an admin performed an earlier revdel. Some of these were logged under RD6 (i.e., as correction of clear and obvious unintended mistakes in previous redactions), but these aren’t (imo) the type of redactions that should be able to be undone at WP:REFUND. All the best, ‍—‍ a smart kitten[ meow 06:55, 22 April 2024 (UTC) reply
Striking RD6. Since RD5 is supposed to incorporate the standard deletion policy, I'd think standard undeletion processes should apply (including REFUND when the deletion was uncontroversial). Wikiacc ( ) 21:58, 22 April 2024 (UTC) reply
I see where you’re coming from - my worry would be that the current wording might increase the scope of what revdels can be undeleted from what the current practices are, as to reverse uncontroversial revision-deletions made under RD5 could be read as implicitly stating that all revdels made under RD5 are uncontroversial and can be REFUNDed. My worry is that this is beyond what is current practice, and would therefore (in effect) represent a change to the policy. All the best, ‍—‍ a smart kitten[ meow 07:08, 26 April 2024 (UTC) reply

Point taken that my suggested wording is ambiguous in scope. How about this rewrite? @ A smart kitten:

To contest or reverse revision-deletions, discuss with the deleting admin. For revision-deletions made under RD5, you may instead follow standard undeletion processes:

Wikiacc ( ) 16:15, 27 April 2024 (UTC) reply

That looks mostly okay to me - just a few things that came to mind:
  1. I’d suggest potentially changing For speedy deletions or deletions that resulted from discussions, to something like If a discussion with the deleting admin fails to resolve the issue,: this takes out the term speedy deletions (which, as far as I’m aware, isn’t generally used to describe revdels), and also makes clear that a discussion with the deleting admin would generally be expected before filing a DRV.
  2. Would this be incorporated into #Appeal and discussion of actions? If so, would the existing paragraph there need to be modified at all?
  3. I’m not sure whether introducing DRV as a review forum for RD5 revdels would represent a change in policy or not — on the one hand, RD5 is for deletions made under the deletion policy; but on the other hand, WP:REVDEL currently states that revdel reviews should take place at WP:AN. I guess I’m neutral on this bit.
As a slight side note, do you mind if I drop a note at Wikipedia talk:Deletion review about this discussion?
All the best, ‍—‍ a smart kitten[ meow 20:01, 27 April 2024 (UTC) reply
@ A smart kitten: Strikeouts added. And yes, please go ahead and drop that note. To your specific points:
  1. I'd rather not codify that a discussion with the deleting admin must come before DRV. Pointing to WP:DRV allows the language there to take precedence -- as of now, discussing with the deleting admin is described as "good practice" but "not required".
  2. This language could go in "Appeal and discussion of actions" (probably above the existing text) or in a different section. I don't think the existing language needs to change.
  3. I'm also not sure; I'd just like the language to be consistent with current practice. If DRV is explicitly not for RD5 revdels then that should be made clear at WP:DRV.
Wikiacc ( ) 22:05, 27 April 2024 (UTC) reply

Videos

Youtube | Vimeo | Bing

Websites

Google | Yahoo | Bing

Encyclopedia

Google | Yahoo | Bing

Facebook