Superprotect: an assumption of bad faith

(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.

See also: Software

Superprotect is a new user right, granted to Wikimedia Staff, with a new policy change as mentioned here:

Hi folks,

Admins are currently given broad leeway to customize the user

experience for all users, including addition of site-wide JS, CSS,

etc. These are important capabilities of the wiki that have been used

for many clearly beneficial purposes. In the long run, we will want to

apply a code review process to these changes as with any other

deployed code, but for now the system works as it is and we have no

intent to remove this capability.

However, we've clarified in a number of venues that use of the

MediaWiki: namespace to disable site features is unacceptable. If such

a conflict arises, we're prepared to revoke permissions if required.

This protection level provides an additional path to manage these

situations by preventing edits to the relevant pages (we're happy to

help apply any urgent edits) until a particular situation has calmed

down.

Thanks,

Erik

-- 

Erik Möller

VP of Engineering and Product Development, Wikimedia Foundation

The Wikimedia Foundation Board officially supported this decision here:

At the Board meeting before Wikimania, Lila laid out her strategy to put in place best practices for product development. We will communicate sooner, we will prioritize smarter, we will test more, and we will achieve better outcomes. Her vision is to involve the community at each step of product development, including more structured feedback stages and reviews. We endorse this vision.

We realize that there is concern about the superprotect user right and how it affects power balance and influence on content and administration. We recognize the concern that we need to explain and introduce our measures better.

However, stability of the platform is necessary as we seek to improve our sites, and, for that reason, we support the creation of this tool. We also understand that with more robust rollout plans and better staged community feedback - as Lila envisions - the tool should rarely be used.

People summarised the specific case that triggered this user right:

<...> this was a response to someone hamfistedly editing en:wp's JS and *actually breaking it*. When Erik reverted this change and said "don't break the damn wiki", the response was "but we can so we should be able to!" and an attempt to take the Foundation to en:wp arbitration. The obvious response is to make it so that such blithering stupidity can't be enacted again. -- here, David Gerard

...and its philosophy:

A pattern we see over and over is that the developers talk at length about what they're working on in several venues, then it's released and people claiming to speak for the community claim they were not adequately consulted. Pretty much no matter what steps were taken todo so, and what new steps are taken to do so. Because there's always someone who claims their own lack of interest is someone else's fault. --here, David Gerard
The patch is not for the MediaWiki software but for the configuration of Wikimedia wikis (it's in the operations/mediawiki-config repository on Gerrit).

It has been merged and deployed on the production cluster. The user right has been added to the global staff user group, and it has already been used to protect the MediaWiki:Common.js page on the German Wikipedia so that no one can edit it except Wikimedia Foundation employees.

Wikimedia Foundation is using this user right to actively fight its community of volunteers.

--here, Tomasz W. Kozłowski (odder) (no longer involved with Tech News since the change)

How many times he or another dev have taken down the wikis? Compare/contrast that number of events with the number of times the community has done so. Which they have been able to do ever since common.js was added.

The fact the community has occasionally done so doesn't come near to the frequency with which the devs have done so. Therefore, the argument is both wrong and bad. --Amgine (no longer involved in Wikimedia projects since the change).

...and a procedural note:

> I understand the Engineering folks used superprotect instead of undoing the edit and adding 'This is a WMF action.' in edit summary. <...> I suppose people could go and try editing other JS pages and cause havoc, but that's still possible where superprotect only affects a single page and not a namespace. Or can entire namespaces be protected and the new user right was intended as a means to easily revoke mediawiki:* access?

I think the problem is that your question does not really relate to the subject line, Svetlana. Office actions are specifically directed at content (e.g., removal of specific content for copyvio reasons or court orders). Office actions are almost never undertaken by Engineering staff; it's usually Legal & Community Advocacy staff, or rarely another administrative staff member.

What you are talking about is something that has only been done very occasionally over the years by Engineering/Operations staff/sysadmins. There has been no designated manner in which those actions should be flagged. One must remember that until the last few years, the majority of individuals who could have taken (and in some cases, did take) such serious action were volunteer sysadmins, so labeling it a "WMF action" would not have been correct. We also have to remember that many of the systems that developers and engineers work with on a daily basis do not permit edit summaries, so adding what for many of us is an automatic and routine comment is for some of them a rare and unusual event. (Perhaps they should set their work account preferences to be "reminded" to include an edit summary?)

--Risker/Anne, here; a further discussion here.

Wikimedia projects run under one of these two assumptions:

Assume good faith, documented at Assume good faith for example.

«It is the assumption that editors' edits and comments are made in good faith. Most people try to help the project, not hurt it. If this were untrue, a project like Wikipedia would be doomed from the beginning. This guideline does not require that editors continue to assume good faith in the presence of obvious evidence to the contrary»

Never assume, documented at Wikinews for example.

«Don't assume things; be skeptical about everything. This applies to people, as well as news: don't "assume good faith", and don't assume bad faith. Also don't assume worse, or better, faith than the situation warrants.»

The superprotect user right:

Effectively assumes bad faith from sysops.
- Sysops haven't been asked to stop politely, first.
  - The wiki collaboration style of work usually involves undoing an edit you disagree with and leaving a message on a relevant contributor talk page.
  - (I would, for instance, undo the common.js edit and leave 'this is a WMF action' note in edit summary, and leave a message to all local sysops suggesting that I did this and it's an office action for 90 days with the purpose of reaching a more well-reached consencus and agreement.
  - On a second time I'd also undo and leave a warning suggesting that superprotect may be added if they continue to go against office actions.)
  - Apparently the Engineering people aren't very used to using the wiki software or edit summaries. (Quote on this above.)
- Communication is lacking (do we have the tools to deliver a message to all sysops specifically?).
- Sysops aren't trusted reading a page at, say, Meta, about UX policies, and following it.
- Wikimedia staff themselves broke wikis with their own changes, inadvertently. [More facts needed]. Why put on boots instead of proper collaboration over mistakes anyone can make?
Shows clearly that the wiki software authorization system is broken. Sysops have the technical ability to disable features in a broken way, but lack config access.
Shows clearly that the Engineering Team assumes that the sysops may do such stupidity again in less time than the wiki software is fixed (or extended; more on missing infrastructure below).

The above-mentioned authorization issue may, in theory, be fixed by either:

revoking sysops access over the software entirely, or
limiting what commons.js can do so that blatant vandalism of commons.js is harmless to the wiki, or
adding code review by Wikimedia Staff for any MediaWiki:* file changes, or
trusting sysops with requesting configuration issues. Seriously. (More on missing infrastructure for this at software).

The latter, obviously, is a more collaborative approach. (In context of past work of the Wikimedia projects, 1-2 are clear assumption of bad faith and are unacceptable, although they may work for instances of MediaWiki at other non-Wikimedia projects.)

Let's try to get these done:

That the Wikimedia Foundation acknowledges that a properly directed on-wiki office action -- undoing the edit and leaving a message about it to all sysops, for instance -- was skipped, but was necessary, as it could have sufficed for the purpose of enforcing the wish of WMF to keep MV enabled on that wiki. (It could also have failed to suffice, were the local sysops to go against an office action, but this doesn't render the earlier comment invalid.)
That the Wikimedia Foundation acknowledges that introducing the Superprotect user right is a mistake caused by skipping proper on-wiki collaboration and by software lacks termed as missing infrastructure above, and apologizes for the hurried assumption of bad faith here.
That the Wikimedia Foundation removes the Superprotect user right from the staff user group, and from production entirely.
That the Wikimedia foundation resolves the authorization issue raised above.