- Page title - WP:REVDEL/Administrators' introduction
RevisionDelete (also RevDelete or RevDel) is a redaction tool, allowing administrators to remove grossly unacceptable material from public view in a more exact and less harmful manner than the tool that's been used so far, delete/selective undelete.
RevDelete has been in use and tested by Oversighters for over a year. An unexpected premature enabling of this right for admins, without a chance to let the community know, led to some confusion. The major issues are now fixed and RevDelete will shortly be made available in full to administrators.
About deletion
On enwiki material is deleted for many reasons. For 9 years the same tool has been used, page deletion, later expanded to allow some revisions to be deleted and some (publicly) visible. This system is crude and has serious issues when it comes to removal of individual "problem" revisions, the main ones being:
Details of key issues
|
|---|
|
RevisionDelete achieves deletion goals differently. Rather than deleting revisions, it keeps the original revisions where they are in "public" contributions and "public" page history and allows grossly improper text to be selectively 'barred' from public (non-admin) viewing. It also finally allows admins to deal with text in log entries and usernames.
With the exception of copypaste move fixing, RevisionDelete is superior to the older tool in every way. Administrators should learn about it, and its appropriate use (by reading this page and the policy, and asking questions), and once they are sufficiently confident, migrate to using the new tool instead of the old one when individual revisions (but not an entire page or all revisions) need deleting.
Usage
While page deletion is well documented and its criteria known, deletion of selective revisions has always been a bit more fluid. There is no Wikipedia:Selective deletion policy for example, it's covered in various places and sometimes not discussed at all. Individual revisions have in the past been deleted for containing virus and malicious links, browser-breaking or very long (megabytes of images) HTML, grossly offensive material, and copyright breaches that don't affect all revisions of the page.
The introduction of a redaction tool means a good chance to formalize these into "criteria for redaction" - when it is considered appropriate for an administrator to delete material from the public record. The initial Criteria for RevDelete and redaction are deliberately based upon past acceptable admin usage.
- Enough revisions containing copyvios, browser crashing markup, and very gross offensive material have been deleted, to suggest the community is happy with this usage of deletion.
These become Criteria 1 - 3.
- Enough revisions containing copyvios, browser crashing markup, and very gross offensive material have been deleted, to suggest the community is happy with this usage of deletion.
- Deletion is also common to hide oversightable material prior to seeking oversight and for non-contentious housekeeping purposes.
These became Criteria 4 and 6.
- Deletion is also common to hide oversightable material prior to seeking oversight and for non-contentious housekeeping purposes.
- Finally instead of repeating all of
WP:CSD, a single "catch-all" is included that if deletion would be acceptable under speedy deletion, then it is acceptable to use the RevDelete tool for the same purpose.
This became Criterion 5.
- Finally instead of repeating all of
WP:CSD, a single "catch-all" is included that if deletion would be acceptable under speedy deletion, then it is acceptable to use the RevDelete tool for the same purpose.
These criteria all speak to the nature of the content, so they apply to logs and usernames as much as page revisions. However logs are very sensitive and should not lightly be tampered with, so as well as covering intended usage the policy is also very hard-line on improper or problem usage.
What deletion should not be used for
RevisionDelete should not be a cause for deletion to be used much differently than before. Ordinary incivility, ordinary unpleasant discussion, even 'ordinary' personal attacks and harsh words, are part of the record. We leave them standing. In most cases they can be redacted using normal reverting or blanking.
The headline areas of caution are: -
- Don't redact logs of admin actions such as block or delete logs (other than for oversight-related reasons or to remove redactable material accidentally preserved in the reason), and
- Do not use the tool to remove "ordinary" incivility or attacks etc, that others in the community may see as unpleasant but valid, or which may be seen as poorly considered but not to be deleted (use reverting, blanking or paraphrase instead or seek clear consensus).
Detail of rationale
|
|---|
|
Reading between the lines of the various discussions, community concerns existed in two areas:
As a result of these concerns, the community consensus included a strong view that in general the wider community should be able to review logs, especially block logs and other logs created by use of admin tools (because the log entry is the work of a trusted user doing a serious action). |
- Specifically:
- In cases of gross offensiveness, insult, abuse, etc, where its use would not be likely to be contentious or divisive (ie fairly universal agreement expected), RevDelete can be useful. But be wary of redacting matters which the wider community may need to review.
- "Ordinary" incivility and attacks may well have project value even if policy-breaching. For example they might allow non-administrators to understand a dispute between established users, or provide a clear record what has gone on, or need to be cited at RFC or RFAR. If truly egregious and redaction would be unlikely to be seen as contentious then it's is probably okay (and the redacted revision can easily be cited or linked in any further discussion). [1]
Log entries created as a result of admin tools (block logs, delete logs, etc) should almost never be redacted, nor need to be. This is to ensure scrutiny is possible, and because the log entry is presumed valid (being admin created). If needed, ask Arbcom or seek clear consensus at ANI.
Exceptions - if oversightable material may be involved (see below), or if the entry for a delete or move action accidentally contains redactable material copied from the article or its title of no project value (which can happen).
How serious is misuse
As a guide, misuse of RevDelete to hide a block log or hiding someone's unfavorable or poorly-conceived post (eg to make someone 'look better', rather than for oversight or such) are likely to be "direct to Arbcom" issues, similar to other gross misuse of tools, wheel warring, self unblock, etc.
Use of RevDelete in other contentious ways (eg to delete a comment without good reason) will depend case by case. It's likely cases like these would be asked to the admin concerned, or go to ANI (or if repeated/egregious RFC) as with other possibly questionable tool use.
Good faith as a clearly uninvolved admin making an honest error of judgment, may make a difference; some borderline cases may just need trouts instead.
Oversightable material
At present oversightable material is often deleted (to reduce exposure) while waiting for oversight. The same continues to apply with RevisionDelete - any material anywhere (edit summary, username, revision text, log entry) that is oversightable may be deleted or redacted while waiting for Oversight.
Administrators who RevDelete (or delete) then promptly seek suppression are protected if they use the RevDelete tool in good faith because of content that might have needed suppression:
- "Report/delete/suppress first, obtain eyeballs after" is a norm for possible oversightable material. Suppression only applies to privacy breaching and defamatory matters and is usually considered time-critical. If uncertain, action is permitted provided it's reasonable and quickly consulted. If the content is not found appropriate for suppression it should be restored or left admin-deleted as required.
- Admins may redact from their own posts as much as anyone elses' if it would be within oversight policy. (COI doesnt come into it) [2]
- Report the matter quickly to oversighters for review ( WP:Request for oversight / WP:RFO, IRC, or email) - In past drama-fests, such as an established user posting attacks or oversightable material, as little as 30 minutes delay has been claimed to show someone might not have planned to follow through on a matter. Avoid drama by reporting quickly. (Tips [3])
- Do not wheel war on a matter of possible suppression. An admin who deletes something prior to suppression is automatically implying emergency per admin policy. Even if you disagree, do not overturn it. Instead wait for oversighter review, and raise concerns at ANI in an appropriate manner if necessary.
Exposure risk
Be aware deletion logs are public (and even if they weren't around 500 - 1000 active admins can view deleted material). RevDelete also doesn't remove the entry from page history and user contributions. So deletion or redaction may be safe from public exposure but it's not the same as suppression.
In some cases it's worth redacting then seeking suppression. But in other cases it might actually be worth not deleting but seeking suppression directly. Use best judgment which draws least attention. Ask "How much attention will this get", and "Do seconds count or will 10 - 20 minutes be okay". Generally if it needs urgent immediate removal in seconds then more likely RevDelete first is a good idea. Personal information or IPs of known harassment or stalker targets is an example where even a little time can matter. If it's low attention/low interest then more likely just reporting it will be fine. Either way it's fine whichever the admin chooses to do.
In any event avoid obvious titles for any redaction ("RD4", "Waiting for oversight", "private material" etc), even if that means it has to be non-detailed or even (slightly) misleading, to reduce the risk of drawing attention in some cases.
Disagreements and disputes
Same as normal for any admin tools - discuss with user, raise at ANI/RFC, or for egregious gross misuse pass it to RFAR. Use judiciously and always have a trout handy.
If the matter is claimed to be (or looks like it might be) privacy/suppression related, then do not wheel war or undo it even if you disagree. Removal of privacy related matters is an urgent situation covered by admin policy. Other admins may believe there is a concern and 1/ you might not know all that they know, 2/ they may not be passing round all they know (to reduce harm), 3/ they are allowed to be over-cautious even if ultimately incorrect, provided they quickly report the matter to oversighters. If the matter was badly judged or in bad faith, it will wait.
(In other words, the consequences of a bystander wrongly assuming it's nothing and flaming/overturning/posting all about it, are more serious than the consequences of the acting admin wrongly being concerned it's privacy-breaching material and removing it while an oversighter checks.)
Tutorial and "how to"
See Tutorial.
Needs to cover
- how to use
- multiple revisions
- overview on revdel links + deleted page links
- converting delete to revdelete
- revdel in the delete log
- revdel's own logs
- revdeleted revisions remain in whichever table they are in - current or deleted.
and practical issues:
- Latest post on the page
- Busy or highly watched pages
- Reversion as a first step to prevent perpetuation of redactable content
- any COI issues?
FAQ
1. What happened regarding the early and disorganized switch-on?
Extended content
|
|---|
|
The sysadmins thought there was a consensus (which there was prior to the log issue being spotted) and enabled it on that basis. When they realized the mistake they put a "fix" as a critical priority and dropped everything to sort the issue out. There's also been discussion to avoid a repeat. |
2. What was the issue? What was with the incredibly dire warnings at WP:AN?
Extended content
|
|---|
|
A wiki works by users being able to review others' actions. Admins review others' admin actions, ditto checkusers and oversighters. RevDelete was released with a "bad link" log issue that could prevent that - and 500 to 1000 admins due to start using it. It was important to stop the "risk area" blowing up. Also due to the unexpected release no "heads up" or guidance existed to explain the new tool, answer user questions, or prevent abuse. |
3. Is it fixed?
Extended content
|
|---|
|
Yes, it's fully fixed now.
|
4. Technical explanation please?
Extended content
|
|---|
|
Historically, MediaWiki handled deletion by physically moving the deleted revisions to a different place in the database. This is why Deleted Contribs and Deleted History don't appear on the same page as normal contribs and history. (Originally this setup ensured deleted revisions would not be included in database dumps, by simply excluding the tables which contained them.) Unfortunately those two tables are indexed differently - deleted revisions (via Special:Undelete) have a completely different reference system based on article + timestamp rather than revision number. So RevDelete's log links to RevDeleted revisions were the same... with consequences:
The end result is that if a revision is deleted or undeleted, any link or reference to it completely changed and the old ones didn't work at all any more. What the fix does: RevDelete now checks where the revisions are, rather than assuming they are in the same place as before, and ensures appropriate links in the logs. It also handles log links correctly for actions affecting multiple revisions. So log links now work whether or not some target revisions are subsequently deleted/undeleted. RevDelete's log links were always created dynamically ("on the spot") so this wasn't as big a change as it might seem. Addressing the underlying issue further would mean changing how deletion is handled in the database. Example approaches include: - ensuring a revision number would always work (even for deleted revisions); not having a separate table for deleted revisions; making selective delete/undelete redundant by adding a "RevisionMove" function; switching all deleted revisions over to RevisionDelete programmatically with a static lookup table for any historical links (unlikely, too many side effects); or via some other technical trick. Fixes like these are noted on bugzilla. |
5. What is the status of the WP:REVDEL policy?
Extended content
|
|---|
|
It's newly drafted so it's raw. It's communally owned, had a lot of review, and expresses "reasonably well" the guidance we're starting with, so it should probably not be changed greatly in spirit. (Not least for stability's sake in the early days and to ensure that the endorsing consensus and past deletion norms are respected.) However if it can be improved in wording then users may wish to do so as for any policy. In particular this guidance may contain useful information that needs to be made clearer in the policy. |
6. Where and how should administrators test out the new tool?
Extended content
|
|---|
|
Try the sandbox, or test it via userspace sub-pages. Not on active articles or project or talk pages. |
Notes
- ^ The community historically discriminates quite well between someone who posts fuck you all, your all pedophil dicks and Admin X is a slut whore bigot and can eat my piss", and an insulting post or retort between two established users where some established users would feel it's offensive and some don't. The policy is (as usual) "if in doubt seek clear consensus".
- ^ This would include an admin who edits logged out and redacts his own IP before asking for suppression. Or indeed an admin who redacts the logged-out IP for any other user who edits logged in and asks for it.
- ^ When you are sure that any actual actions you're doing to redact oversightable material are addressed and any key blocks or other time-sensitive actions are done, report the matter quickly to oversighters, then carry on with the rest. If you have to, delegate some of this to others. It's "worth being safe" so it will be seen as quickly reported.
- Page title - WP:REVDEL/Administrators' introduction
RevisionDelete (also RevDelete or RevDel) is a redaction tool, allowing administrators to remove grossly unacceptable material from public view in a more exact and less harmful manner than the tool that's been used so far, delete/selective undelete.
RevDelete has been in use and tested by Oversighters for over a year. An unexpected premature enabling of this right for admins, without a chance to let the community know, led to some confusion. The major issues are now fixed and RevDelete will shortly be made available in full to administrators.
About deletion
On enwiki material is deleted for many reasons. For 9 years the same tool has been used, page deletion, later expanded to allow some revisions to be deleted and some (publicly) visible. This system is crude and has serious issues when it comes to removal of individual "problem" revisions, the main ones being:
Details of key issues
|
|---|
|
RevisionDelete achieves deletion goals differently. Rather than deleting revisions, it keeps the original revisions where they are in "public" contributions and "public" page history and allows grossly improper text to be selectively 'barred' from public (non-admin) viewing. It also finally allows admins to deal with text in log entries and usernames.
With the exception of copypaste move fixing, RevisionDelete is superior to the older tool in every way. Administrators should learn about it, and its appropriate use (by reading this page and the policy, and asking questions), and once they are sufficiently confident, migrate to using the new tool instead of the old one when individual revisions (but not an entire page or all revisions) need deleting.
Usage
While page deletion is well documented and its criteria known, deletion of selective revisions has always been a bit more fluid. There is no Wikipedia:Selective deletion policy for example, it's covered in various places and sometimes not discussed at all. Individual revisions have in the past been deleted for containing virus and malicious links, browser-breaking or very long (megabytes of images) HTML, grossly offensive material, and copyright breaches that don't affect all revisions of the page.
The introduction of a redaction tool means a good chance to formalize these into "criteria for redaction" - when it is considered appropriate for an administrator to delete material from the public record. The initial Criteria for RevDelete and redaction are deliberately based upon past acceptable admin usage.
- Enough revisions containing copyvios, browser crashing markup, and very gross offensive material have been deleted, to suggest the community is happy with this usage of deletion.
These become Criteria 1 - 3.
- Enough revisions containing copyvios, browser crashing markup, and very gross offensive material have been deleted, to suggest the community is happy with this usage of deletion.
- Deletion is also common to hide oversightable material prior to seeking oversight and for non-contentious housekeeping purposes.
These became Criteria 4 and 6.
- Deletion is also common to hide oversightable material prior to seeking oversight and for non-contentious housekeeping purposes.
- Finally instead of repeating all of
WP:CSD, a single "catch-all" is included that if deletion would be acceptable under speedy deletion, then it is acceptable to use the RevDelete tool for the same purpose.
This became Criterion 5.
- Finally instead of repeating all of
WP:CSD, a single "catch-all" is included that if deletion would be acceptable under speedy deletion, then it is acceptable to use the RevDelete tool for the same purpose.
These criteria all speak to the nature of the content, so they apply to logs and usernames as much as page revisions. However logs are very sensitive and should not lightly be tampered with, so as well as covering intended usage the policy is also very hard-line on improper or problem usage.
What deletion should not be used for
RevisionDelete should not be a cause for deletion to be used much differently than before. Ordinary incivility, ordinary unpleasant discussion, even 'ordinary' personal attacks and harsh words, are part of the record. We leave them standing. In most cases they can be redacted using normal reverting or blanking.
The headline areas of caution are: -
- Don't redact logs of admin actions such as block or delete logs (other than for oversight-related reasons or to remove redactable material accidentally preserved in the reason), and
- Do not use the tool to remove "ordinary" incivility or attacks etc, that others in the community may see as unpleasant but valid, or which may be seen as poorly considered but not to be deleted (use reverting, blanking or paraphrase instead or seek clear consensus).
Detail of rationale
|
|---|
|
Reading between the lines of the various discussions, community concerns existed in two areas:
As a result of these concerns, the community consensus included a strong view that in general the wider community should be able to review logs, especially block logs and other logs created by use of admin tools (because the log entry is the work of a trusted user doing a serious action). |
- Specifically:
- In cases of gross offensiveness, insult, abuse, etc, where its use would not be likely to be contentious or divisive (ie fairly universal agreement expected), RevDelete can be useful. But be wary of redacting matters which the wider community may need to review.
- "Ordinary" incivility and attacks may well have project value even if policy-breaching. For example they might allow non-administrators to understand a dispute between established users, or provide a clear record what has gone on, or need to be cited at RFC or RFAR. If truly egregious and redaction would be unlikely to be seen as contentious then it's is probably okay (and the redacted revision can easily be cited or linked in any further discussion). [1]
Log entries created as a result of admin tools (block logs, delete logs, etc) should almost never be redacted, nor need to be. This is to ensure scrutiny is possible, and because the log entry is presumed valid (being admin created). If needed, ask Arbcom or seek clear consensus at ANI.
Exceptions - if oversightable material may be involved (see below), or if the entry for a delete or move action accidentally contains redactable material copied from the article or its title of no project value (which can happen).
How serious is misuse
As a guide, misuse of RevDelete to hide a block log or hiding someone's unfavorable or poorly-conceived post (eg to make someone 'look better', rather than for oversight or such) are likely to be "direct to Arbcom" issues, similar to other gross misuse of tools, wheel warring, self unblock, etc.
Use of RevDelete in other contentious ways (eg to delete a comment without good reason) will depend case by case. It's likely cases like these would be asked to the admin concerned, or go to ANI (or if repeated/egregious RFC) as with other possibly questionable tool use.
Good faith as a clearly uninvolved admin making an honest error of judgment, may make a difference; some borderline cases may just need trouts instead.
Oversightable material
At present oversightable material is often deleted (to reduce exposure) while waiting for oversight. The same continues to apply with RevisionDelete - any material anywhere (edit summary, username, revision text, log entry) that is oversightable may be deleted or redacted while waiting for Oversight.
Administrators who RevDelete (or delete) then promptly seek suppression are protected if they use the RevDelete tool in good faith because of content that might have needed suppression:
- "Report/delete/suppress first, obtain eyeballs after" is a norm for possible oversightable material. Suppression only applies to privacy breaching and defamatory matters and is usually considered time-critical. If uncertain, action is permitted provided it's reasonable and quickly consulted. If the content is not found appropriate for suppression it should be restored or left admin-deleted as required.
- Admins may redact from their own posts as much as anyone elses' if it would be within oversight policy. (COI doesnt come into it) [2]
- Report the matter quickly to oversighters for review ( WP:Request for oversight / WP:RFO, IRC, or email) - In past drama-fests, such as an established user posting attacks or oversightable material, as little as 30 minutes delay has been claimed to show someone might not have planned to follow through on a matter. Avoid drama by reporting quickly. (Tips [3])
- Do not wheel war on a matter of possible suppression. An admin who deletes something prior to suppression is automatically implying emergency per admin policy. Even if you disagree, do not overturn it. Instead wait for oversighter review, and raise concerns at ANI in an appropriate manner if necessary.
Exposure risk
Be aware deletion logs are public (and even if they weren't around 500 - 1000 active admins can view deleted material). RevDelete also doesn't remove the entry from page history and user contributions. So deletion or redaction may be safe from public exposure but it's not the same as suppression.
In some cases it's worth redacting then seeking suppression. But in other cases it might actually be worth not deleting but seeking suppression directly. Use best judgment which draws least attention. Ask "How much attention will this get", and "Do seconds count or will 10 - 20 minutes be okay". Generally if it needs urgent immediate removal in seconds then more likely RevDelete first is a good idea. Personal information or IPs of known harassment or stalker targets is an example where even a little time can matter. If it's low attention/low interest then more likely just reporting it will be fine. Either way it's fine whichever the admin chooses to do.
In any event avoid obvious titles for any redaction ("RD4", "Waiting for oversight", "private material" etc), even if that means it has to be non-detailed or even (slightly) misleading, to reduce the risk of drawing attention in some cases.
Disagreements and disputes
Same as normal for any admin tools - discuss with user, raise at ANI/RFC, or for egregious gross misuse pass it to RFAR. Use judiciously and always have a trout handy.
If the matter is claimed to be (or looks like it might be) privacy/suppression related, then do not wheel war or undo it even if you disagree. Removal of privacy related matters is an urgent situation covered by admin policy. Other admins may believe there is a concern and 1/ you might not know all that they know, 2/ they may not be passing round all they know (to reduce harm), 3/ they are allowed to be over-cautious even if ultimately incorrect, provided they quickly report the matter to oversighters. If the matter was badly judged or in bad faith, it will wait.
(In other words, the consequences of a bystander wrongly assuming it's nothing and flaming/overturning/posting all about it, are more serious than the consequences of the acting admin wrongly being concerned it's privacy-breaching material and removing it while an oversighter checks.)
Tutorial and "how to"
See Tutorial.
Needs to cover
- how to use
- multiple revisions
- overview on revdel links + deleted page links
- converting delete to revdelete
- revdel in the delete log
- revdel's own logs
- revdeleted revisions remain in whichever table they are in - current or deleted.
and practical issues:
- Latest post on the page
- Busy or highly watched pages
- Reversion as a first step to prevent perpetuation of redactable content
- any COI issues?
FAQ
1. What happened regarding the early and disorganized switch-on?
Extended content
|
|---|
|
The sysadmins thought there was a consensus (which there was prior to the log issue being spotted) and enabled it on that basis. When they realized the mistake they put a "fix" as a critical priority and dropped everything to sort the issue out. There's also been discussion to avoid a repeat. |
2. What was the issue? What was with the incredibly dire warnings at WP:AN?
Extended content
|
|---|
|
A wiki works by users being able to review others' actions. Admins review others' admin actions, ditto checkusers and oversighters. RevDelete was released with a "bad link" log issue that could prevent that - and 500 to 1000 admins due to start using it. It was important to stop the "risk area" blowing up. Also due to the unexpected release no "heads up" or guidance existed to explain the new tool, answer user questions, or prevent abuse. |
3. Is it fixed?
Extended content
|
|---|
|
Yes, it's fully fixed now.
|
4. Technical explanation please?
Extended content
|
|---|
|
Historically, MediaWiki handled deletion by physically moving the deleted revisions to a different place in the database. This is why Deleted Contribs and Deleted History don't appear on the same page as normal contribs and history. (Originally this setup ensured deleted revisions would not be included in database dumps, by simply excluding the tables which contained them.) Unfortunately those two tables are indexed differently - deleted revisions (via Special:Undelete) have a completely different reference system based on article + timestamp rather than revision number. So RevDelete's log links to RevDeleted revisions were the same... with consequences:
The end result is that if a revision is deleted or undeleted, any link or reference to it completely changed and the old ones didn't work at all any more. What the fix does: RevDelete now checks where the revisions are, rather than assuming they are in the same place as before, and ensures appropriate links in the logs. It also handles log links correctly for actions affecting multiple revisions. So log links now work whether or not some target revisions are subsequently deleted/undeleted. RevDelete's log links were always created dynamically ("on the spot") so this wasn't as big a change as it might seem. Addressing the underlying issue further would mean changing how deletion is handled in the database. Example approaches include: - ensuring a revision number would always work (even for deleted revisions); not having a separate table for deleted revisions; making selective delete/undelete redundant by adding a "RevisionMove" function; switching all deleted revisions over to RevisionDelete programmatically with a static lookup table for any historical links (unlikely, too many side effects); or via some other technical trick. Fixes like these are noted on bugzilla. |
5. What is the status of the WP:REVDEL policy?
Extended content
|
|---|
|
It's newly drafted so it's raw. It's communally owned, had a lot of review, and expresses "reasonably well" the guidance we're starting with, so it should probably not be changed greatly in spirit. (Not least for stability's sake in the early days and to ensure that the endorsing consensus and past deletion norms are respected.) However if it can be improved in wording then users may wish to do so as for any policy. In particular this guidance may contain useful information that needs to be made clearer in the policy. |
6. Where and how should administrators test out the new tool?
Extended content
|
|---|
|
Try the sandbox, or test it via userspace sub-pages. Not on active articles or project or talk pages. |
Notes
- ^ The community historically discriminates quite well between someone who posts fuck you all, your all pedophil dicks and Admin X is a slut whore bigot and can eat my piss", and an insulting post or retort between two established users where some established users would feel it's offensive and some don't. The policy is (as usual) "if in doubt seek clear consensus".
- ^ This would include an admin who edits logged out and redacts his own IP before asking for suppression. Or indeed an admin who redacts the logged-out IP for any other user who edits logged in and asks for it.
- ^ When you are sure that any actual actions you're doing to redact oversightable material are addressed and any key blocks or other time-sensitive actions are done, report the matter quickly to oversighters, then carry on with the rest. If you have to, delegate some of this to others. It's "worth being safe" so it will be seen as quickly reported.