Wikipedia:Arbitration/Requests/Case/Media Viewer RfC/Evidence

Main case page (Talk) — Evidence (Talk) — Workshop (Talk) — Proposed decision (Talk)

Case clerk: TBD Drafting arbitrator: TBD

Any editor may add evidence to this page, irrespective of whether they are involved in the dispute. You must submit evidence in your own section. Editors who change other users' evidence may be blocked without warning; if you have a concern with or objection to another user's evidence, contact the committee by e-mail or on the talk page. The standard limits for all evidence submissions are: 1000 words and 100 diffs for users who are parties to this case; or about 500 words and 50 diffs for other users. Detailed but succinct submissions are more useful to the committee. This page is not designed for the submission of general reflections on the arbitration process, Wikipedia in general, or other irrelevant and broad issues; and if you submit such content to this page, please expect it to be ignored. General discussion of the case may be opened on the talk page. You must focus on the issues that are important to the dispute and submit diffs which illustrate the nature of the dispute or will be useful to the committee in its deliberations.

You must use the prescribed format in your evidence. Evidence should include a link to the actual page diff in question, or to a short page section; links to the page itself are inadequate. Never link to a page history, an editor's contributions, or a log for all actions of an editor (as those change over time), although a link to a log for a specific article or a specific block log is acceptable. Please make sure any page section links are permanent, and read the simple diff and link guide if you are not sure how to create a page diff.

The Arbitration Committee expects you to make rebuttals of other evidence submissions in your own section, and for such rebuttals to explain how or why the evidence in question is incorrect; do not engage in tit-for-tat on this page. Arbitrators may analyze evidence and other assertions at /Workshop, which is open for comment by parties, Arbitrators, and others. After arriving at proposed principles, findings of fact, or remedies, Arbitrators vote at /Proposed decision. Only Arbitrators (and Clerks, when clarification on votes is needed) may edit the proposed decision page.

Evidence presented by Wnt

Media Viewer appears to be unpopular on English Wikipedia

Let's get the ball rolling. This merely summarizes the hard evidence presented in the Case statements and is doubtless incomplete; I welcome word of omissions.

• Survey: Since March 19, 6595 English survey responses have found the Media Viewer to be "useful for viewing images and learning about them" 36.16% of the time, and disagreed 53.57% of the time.^[1] (The "daily trends" data reached >50% approval for a time late in the survey, but on these days there were usually under 50 responses versus well over 100 previously.^[2])
• Survey: Of responses collected on June 20, 28% of English-language responses found the tool "useful" and 61% did not.^[3]
• RfC: Wikipedia:Media Viewer/June 2014 RfC was closed with 64 editors calling for it to be disabled by default versus 5 calling for it to be enabled.

Evidence presented by John F. Lewis

Communications of technical feature roll outs by the Wikimedia Foundation

The Wikimedia Foundation have several methods of announcing to the community that features are being considered for roll outs. These includes mailing lists, on-wiki newsletters, on-wiki notifications, IRC discussions etc. from what I see, the Foundation followed the usual deploy method and the English Wikipedia community was informed of the roll out as per standard procedure.

• In this Tech News release, it was noted Media Viewer will be enabled on the English Wikipedia with a date.
• In this Tech News release (one week later), it was noted the Media Viewer release for the English Wikipedia has been delayed to a new date.
• Again, in this Tech News release, the Media Viewer release was reminded to the community. After which, it was.
• This post introduces Media Viewer to the community and informs them that the feature will soon become default for all.
• This post notifies the community of the feature being enabled by default.
• A release plan has been around for a good few months now and has been publicised.
• The English Wikipedia's Signpost also published a report on Media Viewer before it was released. See this.

There are probably a lot more links and I will track them down later but for now - I believe the above shows a relatively strong effort to communicate the release by the Wikimedia Foundation, it's volunteers and even local users here. There is no fault with the Foundation's communication ability in my opinion.

Wikimedia Foundation processes for reviewing staff conduct

The Wikimedia Foundation has a published Code of Conduct Policy which gives a basic overview of the expected conduct of staff. While this is not specific to staff-volunteer communication, the final paragraph may be of interest to the Arbitration Committee. To my knowledge, there are no official processes or reviewing staff conduct apart from the Board of Trustees.

The RfC's validity as a result of advertisement

The English Wikipedia has always been lacking a real method of advertising requests for comment. From what I can see, the request for comment was advertised at the following places:

• The Signpost: Wikipedia:Wikipedia Signpost/2014-06-25/Discussion report
• Template:Centralized discussion

In my opinion, the RfC can not be classed as valid as it lacks the type of coverage the VisualEditor RfC received which involved site notices, watch list notifications and such.

The proposed code

The code proposed for addition which was a javascript hack should never have been added. The administrator who added the code had no idea what the code in question did nor was he experienced enough to make a call about whether this code executes the closure correctly. It was not acceptable for the administrator to add code to the sitewide javascript message without a basic understanding.

Media Viewer change log

The Wikimedia Foundation always ensure to have a basic change log available in some-way of all changes made to code deployed on their servers. Media Viewer is no exception here. While Media Viewer itself may not have a direct change log, a full list of all changes along with the code with it is available on Wikimedia Gerrit.

Evidence presented by Dank

RfCs are complicated

There's a limit on what I can say here, because these questions come up sometimes in RfCs that I close, but a few points bear mentioning. I can provide diffs on request, but I really think the overview may be more useful than the individual instances here, and I hope none of this is controversial:

• Sometimes RfCs don't have a large or representative sampling of voters. Sometimes the closer does little more than count votes, or screws up in other ways. Sometimes voters don't listen to each other or look at the data, if the data is even relevant. But formal and informal community discussion, as imperfect as it often appears, must be working, because we're the top non-fluffy content site on the internet. When the long process of discussion is allowed to play out, the result is usually something we can live with.
• "Bad" RfCs have been frequent steps along the way to eventual acceptable results. Voters who feel strongly about something often avoid discussing alternatives to their first choice during the RfC, possibly out of a conviction that offering some middle ground will weaken their position. Just like in real life, willingness to compromise sometimes doesn't happen until the brute force approaches fail ... repeatedly.
• Wikipedia works on a "publish, then vet" model, and not just in article-space. Wikipedians have generally gotten in the habit of waiting for a result of some kind before we weigh in, even on important questions. I sympathize with the Foundation on this point; coders need to know what they're supposed to be working on long before they've got a finished product. But to solve that problem, we'd need well-attended, well-informed early-stage RfCs for important coding projects ... and it might be difficult to do that, and to do it right. - Dank (push to talk) 11:21, 22 July 2014 (UTC)

Evidence presented by Ariconte

Current issue is part of continuing communication problem between volunteers and staff

De-sysop mis-communication: the drama^[4] and the apology^[5].

Media viewer: Staff and volunteers attack each other^[6]

Thread on how does one deal with staff.^[7]

Larger foundation staff reduces perceived value of volunteers

Volunteers were seen as "critical for the long term sustainability of the Foundation"^[8] when the foundation had 10 staff; now there are 211.

Cory Bass was the 'volunteer coordinator' but left in 2008?^[9]

Volunteers to the foundation are not encyclopedia editors

Quoting Sue Garner: "...We do pay staff to do things that are better done by staff than by volunteers, such as managing the trademark portfolio. Some volunteers (such as Domas) have very special privileges and powers, because they've proved over time they are exceptionally skilled. Some volunteers support the Wikimedia Foundation staff in their work in a variety of ways, because they've proved their interest and abilities. ... The ways on which we work together are becoming increasingly clear, and I think that clarity is good. ..."^[10]

Wikipedia editors are volunteers who edit the encyclopedias; not javascript!

Foundation volunteers should be integrated with the staff, support the staff, and get support from the staff. A volunteer may have more skill or knowledge; in which case the staff should be following them! Foundation leaders need to make this happen.^[11]

Evidence presented by Dennis Brown

Abuse at this level radiates through the entire community

Erik's threat to desysop an admin when he knew or should have known that 1) Pete believed he was following consensus, so was acting in good faith, and 2) It was unlikely that Pete would have edit warred, as Erik had worked with Pete before, demonstrates the highest abuse of power. As Erik is assumed to have high level access to all of Wikipedia, we must assume the threat was credible.

This has a demoralizing effect on the admin corps, knowing we are one hissy fit away from being desysoped by a disgruntled employee. The Foundation itself has dictated that all Admin must pass through a ritual similar to RFA, although some like Erik were grandfathered in, and he either doesn't understand or is unwilling to comply with community expectations in regards to admin behavior. While his abuse wasn't the actual use of the bit, it was during the use of the bit that the act occurred, making the distinction irrelevant. His conduct was clearly "conduct unbecoming of an admin" and to such a gross degree that he should either resign the bit or have it forcibly removed.

As an admin, I'm bound by certain policies regarding my accountability and behavior. If paid employees are exempted from the same standards of conduct and can freely abuse the community without fear of sanction, it reflects poorly on all admin and makes our jobs even harder. Frankly, we already have enough problems with admin/editor relations, and these kinds of nightmares make editor retention that much more difficult, and in this case, retention of admin as well. Dennis Brown | 2¢ | WER 22:30, 21 July 2014 (UTC)

It's déjà vu all over again

I hate to throw Erik's own words against him, but I found this link [12] while reading this [13]. As it touches on some of the issue before us regarding office actions and desyoping, it adds to the idea that Erik knew or should have known the impact of his inappropriate threat. Additionally, unless I have missed another email (which is possible), I thought his adminship was designed to be temporary only [14], or at least that was the basis for the original request. Dennis Brown | 2¢ | WER 12:41, 24 July 2014 (UTC)

Evidence presented by Alanscottwalker

No formal action at Arbcom should be taken against anyone

No formal action at Arbcom should be taken against Eloquence (Erik Möller), personally, for his official WMF statements, as it would either be scapegoating or holding him to a standard of perfection. As PeteForsyth has said:[15]

. . . my action that precipitated it was at best hasty and ill-informed, and at worst negligent. So a quick response from Erik was justified, even if it was imperfect. . . Erik's threat was insignificant, and doesn't demand any kind of strong reaction.

There is no evidence that anyone was acting in bad faith (although Pete was certainly acting mistakenly). Checks on local admin's power (esp. negligence) are not demoralizing to Users, quite the opposite. (see eg., WP:ADMIN (which, moreover, does not apply to staff)). The déjà vu cites, above, show appeal is made to the WMF.

Arbcom is not Govcom over the WMF

• The WMF has legal and technical ownership and control of the domain en.wikipedia.org. The WMF adopts policy, which binds all users on all projects, including English Wikipedia. As a private foundation, it is able to raise funds for platform and organization, technically distributing "free" knowledge (including code) and acts according to its governing documents and processes - its plenary authority does not arise from English Wikipedia policy.WP:WMF

• The WMF assigns Staff permissions "for primarily legal and technical reasons." "There is no requirement that community consensus be demonstrated" for Staff permissions. [16]

• Use of Staff permissions may be audited by WP:AUSC (for the checkuser and oversight permissions), if AUSC action against staff is requested it must be referred to WMF for determination, all other staff acts/decisions must also be referred to the WMF for audit, review, and determination. [17]

• User:Eloquence, aka Erik Möller, WMF DD+VP, has WMF Staff permissions. [18]

• During the Media Viewer RfC, the representative of the WMF informed Users that the fate of the Viewer default, rested with the WMF. [19]

• "Decisions, rulings, and acts of the WMF['s] . . . designees take precedence over, and preempt, consensus." Complaints concerning those decisions and acts are made in writing to the WMF. WP:CONEXCEPT. This is also consistent with WMF policy. [20]

• The WP:RFC (a "lightweight process") closed with a short closing statement that addressed no positions.[21][22] The Viewer had changed during the discussion,[23][24] meaning the !votes were on different things. The close also displaced Policy -- to determine what is and is not subject to consensus of that "lightweight" discussion. WP:RFC

• After the WP:RFC, the representative of the WMF announced that the WMF would not go along with the close.[25] This consistent with past WMF practice.[26]

• Erik Möller, using staff privileges, reverted changes to the code, referring to the previous WMF statement (code having been changed, after the WMF statements during and after the RfC, by admin action that was "ill-informed, and at worst negligent," and unsupported by consensus, nor by policy) [27] and warned, identifying the action as for the WMF, enforced by the WMF.[28]. Both Editwar and WP:Wheelwar were avoided.

• The Committee has no jurisdiction over WMF staff, when acting as staff. Legal and technical issues are committed to the WMF as owner for final determination. It's not through adversarial process in this forum that such is redressed. WP:Arbitration Policy. -- Alanscottwalker (talk) 12:38, 26 July 2014 (UTC)

Evidence presented by Wbm1058

Open bugs justify delaying the product release to default status

There are 88 items about Media Viewer in Bugzilla, as of this edit. Not all are bugs; some are feature requests. These need to be examined to determine which, if any, are "show-stoppers". Prior to making the product the default, a minimal level of quality should be assured. Wbm1058 (talk) 18:57, 26 July 2014 (UTC)

Evidence presented by Erik Moeller (WMF)

Development/deployment policy is in need of clarification

I want to acknowledge that the policy governing software development and deployments on our projects needs to be clarfied. WMF has, at different times, rejected configuration requests (in some cases, very contentiously, e.g. WP:ACTRIAL) or intervened on code in the MediaWiki: namespace (the latter usually for performance, security or policy reasons). While we've stated the organization's view for the record several times (as noted in the original statement), clearly documented policies for deployments (including code in the MediaWiki: namespace) are needed to reduce the risk of escalation in future. We will work towards that.

Our original response to the RFC was insufficiently clear

I want to acknowledge that our original response to the RFC, posted 10 July by Fabrice Florin on behalf of WMF, was not clear enough in that it stated a preliminary decision but used the word "recommendation". This was a good faith intent to engage in a conversation, but had the effect of muddying the waters. In retrospect, and after speaking more with Pete Forsyth about it, I recognize that an escalation like the one that occurred could have perhaps been avoided if we had stated principles more clearly upfront (such as the idea that administrators disabling site features is not acceptable). We will work together to develop internal guidelines on how we respond to such RFCs, specifically with an eye to clear rules of engagement.

WMF has significantly improved development/deployment processes in the last year, and will continue to do so

When this kind of conflict occurs, we always consider what we could have done differently to avoid it. After the conflict related to the (admittedly premature) deployment of VisualEditor last year, we introduced a new system, Beta Features, to pilot new features with early adopters. Media Viewer was first introduced as a beta feature in November 2013 [29] and very carefully and gradually improved and rolled out over a period of months. The project also was supported throughout by a dedicated community liaison, Keegan Peterzell. Many technical issues e.g. regarding integration of metadata have been addressed during that time in close partnership with the community. Key metrics were tracked and measurement methods improved throughout the development.

Going forward, we'll continue to assess how we can reduce friction and perceived disruption as part of development and deployment processes, including but not limited to:

• more clearly stating success/failure criteria for major features and using these to determine deployment status
• %-based rollouts to a segment of the total user population
• stronger iterative validation of user experience changes through rapid user testing cycles
• standardized micro-surveys to measure user satisfaction

We welcome suggestions along these and similar lines.

The RFC process contributes to an us vs. them relationship

The RFC process and similar polls contribute to an us vs. them relationship on software development issues that makes constructive partnership to resolve issues harder. For example, during the time of the English Wikipedia RFC, many changes to the MultimediaViewer extension were made that addressed issues, including some referenced in the RFC. The RFC process tends to present an inflexible final outcome, which puts WMF in an awkward position of either having to roll back a major software feature or being seen to oppose "the community", as illustrated by this case.

We would welcome suggestions from the community for processes that could lead to a more constructive working relationship between both groups. One possibility would be to refer a conflict related to software features to a smaller elected body, or to have a smaller group of community members nominated on an as-needed basis to negotiate an issue of concern. In any event, we are open to piloting new processes.

WMF continues to engage meaningfully with the community regarding Media Viewer

We recognize that the software feature which triggered the RFC continues to be contentious, and that there are valid reasons why community members have expressed criticism and concern related to the tool. We are continuing to explore constructive paths forward, including easier access to viewing preferences for all users, additional research to validate whether the tool serves its intended purpose, and exploration of compromise options regarding its eventual integration and configuration. This process continues to be led by Fabrice Florin, Product Manager for the feature. See his edits on English Wikipedia and Meta, for example.

The main action that triggered this RFC was an intervention to prevent an admin attempt to disable the tool. Indeed, the main principle on which we cannot compromise is that WMF maintains final authority over software deployment and configuration. In spite of stating this principle, we will absolutely continue to work rationally and constructively with the community as the most important stakeholder towards a reasonable outcome.

Evidence presented by {your user name}

before using the last evidence template, please make a copy for the next person

{Write your assertion here}

Place argument and diffs which support your assertion; for example, your first assertion might be "So-and-so engages in edit warring", which should be the title of this section. Here you would show specific edits to specific articles which show So-and-so engaging in edit warring.

{Write your assertion here}

Place argument and diffs which support the second assertion; for example, your second assertion might be "So-and-so makes personal attacks", which should be the title of this section. Here you would show specific edits where So-and-so made personal attacks.