Wikipedia Revision Deletion Best Practices: A Guide for Administrators

Imagine you are a Wikipedia administrator who is a user with technical privileges to perform maintenance tasks on the encyclopedia. You spot a revision that contains leaked private data or a severe copyright violation. Your instinct might be to just delete it. But in the world of open collaboration, "delete" is rarely the right word. The process is nuanced, governed by strict policies, and carries significant ethical weight. Getting it wrong can lead to legal issues for the Wikimedia Foundation or erode trust within the community.

This guide breaks down the best practices for revision deletion, ensuring you handle sensitive content correctly while maintaining the integrity of the project.

Understanding the Scope of Revision Deletion

Before touching any buttons, you need to understand what you are actually doing. Revision deletion is the administrative action of hiding specific edits from public view while preserving them for authorized users. It is not the same as page deletion. When you delete a page, the history remains visible unless revisions are also hidden. This distinction matters because transparency is core to Wikipedia's ethos.

There are two main types of hidden revisions:

• Deleted Revisions (RevDel): These are visible to other administrators and bureaucrats but hidden from regular readers and editors. This is used for most privacy leaks, vandalism containing personal info, or severe harassment.
• Oversighted Revisions: These are hidden from almost everyone, including standard administrators. Only Oversighters who are trusted stewards with access to highly sensitive information can see these. This level is reserved for extreme cases like doxxing, child sexual abuse material (CSAM), or non-consensual intimate imagery.

The key difference lies in accessibility. If you hide something via RevDel, another admin can unhide it if they disagree with your decision. If you oversight it, even an admin cannot see it without applying for special access. Always start with the least restrictive option necessary. If RevDel solves the problem, do not escalate to Oversight.

Identifying Valid Grounds for Hiding Content

You cannot hide revisions simply because you dislike the content or think it is poorly sourced. There must be a clear policy violation. Here are the primary scenarios where revision deletion is appropriate:

1. Privacy Violations: This includes phone numbers, home addresses, email addresses, Social Security numbers, or medical records. Even if the editor added their own info, it should often be hidden to prevent scraping bots from collecting data.
2. Copyright Infringement: Large blocks of text copied from books or websites. While fair use images have specific rules, unauthorized text copies usually require removal from the current version and often hiding of the history to avoid liability.
3. Severe Vandalism: Edits that contain hate speech, threats of violence, or graphic descriptions of illegal acts. Simple silly vandalism (like adding "lol" to a sentence) does not warrant hiding; it just needs reverting.
4. Bio of Living Person (BLP) Issues: Unverifiable negative claims about living people. If a claim is defamatory and unsourced, it must be removed. If it was widely visible before removal, hiding the revision prevents further spread.

A common mistake new admins make is hiding revisions for minor grammar errors or neutral point of view disputes. These are editorial disagreements, not grounds for censorship. Keep the history visible so the community can learn from the discussion.

The Role of ORES in Decision Making

ORES (Objective Revision Evaluation Service) is a machine learning tool that predicts whether an edit is likely to be constructive or damaging. It provides probabilities for bad faith, vandalism, and good faith errors. While ORES is incredibly helpful, it is not infallible.

When deciding on revision deletion, use ORES scores as a signal, not a verdict. For example, if an edit has a 95% probability of being vandalism but only adds a single swear word, a simple revert is sufficient. Hiding the revision is overkill. However, if ORES flags a high probability of bad faith combined with the addition of an IP address or email, that is a strong indicator for RevDel.

Always check the diff manually. ORES can miss context. An edit might look like vandalism to an algorithm but be a legitimate correction of a typo by a novice. Human judgment remains the final authority. Relying solely on automated tools can lead to false positives and unfair treatment of new contributors.

Step-by-Step Execution for Administrators

Here is the practical workflow for handling a sensitive revision:

1. Assess the Severity: Determine if the content violates privacy, copyright, or safety policies. Ask yourself: "Will this cause harm if left visible?"
2. Check for Precedent: Look at similar cases in the past. How did other admins handle this? Consistency builds trust.
3. Choose the Right Tool: Use the "Hide revision" link in the history tab. Select "Delete" for standard hiding or "Oversight" for extreme cases.
4. Provide a Reason: Always add a comment explaining why you hid the revision. Examples include "privacy leak," "copyright violation," or "severe BLP violation." This helps other admins understand your decision.
5. Notify Relevant Parties: If the edit was made by a registered user, consider leaving a polite note on their talk page explaining what happened and why, without revealing the hidden content.

If you are unsure whether to use RevDel or Oversight, err on the side of RevDel. You can always request escalation later if the situation worsens. Escalating too quickly can create bottlenecks for the small team of Oversighters.

Common Pitfalls to Avoid

Even experienced admins make mistakes. Here are some frequent errors:

• Over-Hiding: Hiding revisions for minor infractions. This reduces transparency and makes it harder for the community to audit admin actions.
• Under-Hiding: Leaving severe privacy leaks visible. This exposes individuals to real-world harm and violates Wikimedia's legal obligations.
• Ignoring Context: Deleting a revision without checking if the information was already published elsewhere. If the data is public knowledge, hiding the Wikipedia edit may not be necessary.
• Lack of Documentation: Failing to log the reason for hiding. This creates confusion and can lead to disputes during admin reviews.

Remember, your goal is to protect the community and its subjects, not to punish editors. Approach each case with empathy and caution.

Comparison of Revision Hiding Levels

Handling Disputes and Appeals

Sometimes, an editor will argue that their revision should not have been hidden. This can happen on their talk page or in admin noticeboards. Here is how to respond professionally:

First, remain calm and factual. Quote the relevant policy section. Explain clearly why the content violated the rule. If the editor misunderstands the policy, provide a link to the help page. Do not get into a heated argument. If the dispute escalates, consider seeking a second opinion from another admin. Consensus is key in Wikipedia governance.

If you believe an admin incorrectly hid your revision, you can request review on the Administrators' Noticeboard which is a forum for discussing administrative actions and disputes. Other admins will evaluate the case based on policy and evidence. Be prepared to show diffs and explain your perspective.

Best Practices Summary Checklist

• Always verify the severity of the violation before acting.
• Use the least restrictive hiding method possible.
• Document your reasons clearly in the hide comment.
• Consult ORES but rely on human judgment.
• Notify affected users politely and privately when appropriate.
• Seek consensus in disputed cases.
• Regularly review your own actions to ensure consistency.

By following these guidelines, you contribute to a safer, more trustworthy Wikipedia. Remember, with great power comes great responsibility. Handle every revision with care.