User:Rschen7754/Help, my wiki went rogue!

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Noto Emoji Pie 1f4c4.svg (English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.
Translate

Disclaimer: I was a steward from February 2014-March 2015 and have watched stewards perform public actions on Meta for years. But I am no longer a steward and regardless, this is not and would never be an official statement from them.

Scope[edit]

This essay generally applies to small to medium-sized wikis without an Arbitration Committee, where the entire active administrator team of a wiki can be corrupted, or where a few administrators can intimidate other administrators into submission. It definitely does not apply to big wikis like English Wikipedia.

General advice[edit]

Getting another perspective[edit]

Have you considered that you may have been blocked for legitimate reasons? If you are getting blocked on multiple Wikimedia sites (or even non-Wikimedia sites) - then maybe the problem is you.

But if you have been blocked for legitimate criticism or edits, then read on.

A warning[edit]

This process could take months, if not years. Please be patient.

Too long; didn't read[edit]

Keep in mind that stewards are very busy. Many of them are not native speakers of English. Therefore, your posts requesting for assistance need to be concise, and to the point. Remove anything that is ambiguous or not necessary to make your point.

I cannot emphasize this enough. I believe one of the reasons why Requests for comment/Global ban for Kubura was successful was the clear and concise case that anyone could understand.

Stewards are not a global ArbCom[edit]

They aren't, per Stewards policy. They are bound to follow consensus, so stewards are generally reluctant to intervene in local matters.

However, they can intervene in emergency situations, or if there is a global consensus gained through RFC.

Step 1: open a request for comment[edit]

Open a request at RFC. Be sure to notify the affected parties as per Requests for comment/Policy. In your request, concisely state the problem and why stewards or the Wikimedia community at large should intervene in the matter.

What if there is no response or very little response from outside parties? Then go to step 2.

If you get no response, don't go open another RFC. This just clogs the system with another request and makes things more difficult for other editors to sort out.

Step 2: make a proposal[edit]

Ideally, some other editor who is uninvolved will do this. I would wait at least 1 month. But if not, you may have to do it yourself.

Make a proposal as to what to do, for stewards to carry out. Some tips:

  • Make a list rather than using paragraphs
  • Only propose the minimum intervention needed to get the wiki back on the right track.
  • Look at past proposals (see below) to see what works and what doesn't.

Then, make neutral notifications to places like Wikimedia Forum.

Proposals that generally don't work[edit]

  • Setting up a local, global, or cross-wiki ArbCom
  • Any policy or action relating to content itself
  • Appointing administrators from some other wiki

What will get stewards to desysop someone[edit]

Emergency desysop[edit]

Warning: the procedure for an emergency desysop will refer the decision of whether to resysop back to your local bureaucrats. If the administrator is a bureaucrat, those rights will be removed through this process as well.

  • Wheel warring, if reported to stewards in a timely manner
  • Self-unblocking or anything to that effect (note that self-unblocking is no longer technically possible)
  • Blocking someone as a retaliation for a desysop vote or a vote on a Meta RFC; using protection to interfere with a desysop vote
    • This can be incredibly hard to prove, however
  • In some cases, sockpuppetry on a global scale (especially if it results in global locks)
  • Repeated posting of privacy-violating JavaScript
  • In some cases, blocking a global sysop or steward
  • Blatant vandalism
  • Signs the account was compromised - but this may result in a global lock instead

Regular desysop[edit]

Note that if the administrator has other rights such as interface admin, bureaucrat, CU, or OS - those rights must also be specified in these processes, or those rights will not be removed. Such removal is not automatic.

  • A community vote for an administrator to be desysopped
    • If your community does not have official rules on this, stewards will generally look to make sure the vote was in a prominent place, had a decent number of voters, and was at least 50% in support of a desysop
  • A proposal to that effect in a Meta RFC that has community consensus
  • Your community's local inactivity policy, or AAR if your community does not have one
    • Note that CU and OS have a stricter inactivity policy that cannot be superseded
  • A global or WMF ban (because all rights are removed in this scenario)
  • Proof that a user is deceased (because all rights are removed in this scenario)
    • Obviously, this user won't be the cause of the problems, but it might help in determining why other administrators are non-responsive
  • Closing the wiki, if the wiki meets the criteria under CPP
    • If the wiki is to a point where the content is completely unusable

Additional factors[edit]

These factors will generally be taken into account:

  • Temporary administrators can be removed a lot easier than permanent administrators
  • Whether a wiki is a global sysop wiki
  • Whether a wiki is a content wiki or a test wiki
  • Whether there are bureaucrats

Case history[edit]