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

Case clerks: Lord Roem (Talk) & Callanecc (Talk) Drafting arbitrators: Carcharoth (Talk) & GorillaWarfare (Talk)

Wikipedia Arbitration
Open proceedings
Active sanctions
Arbitration Committee
Audit
Track related changes

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[edit]

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.

Evidence presented by John F. Lewis[edit]

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.

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:

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[edit]

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:

Evidence presented by Ariconte[edit]

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

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

Media viewer: Staff and volunteers attack each other[7]

Thread on how does one deal with staff.[8]

Larger foundation staff reduces perceived value of volunteers

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

Cary Bass was the 'volunteer coordinator' but left in 2008?[10]

Volunteers to the foundation are not encyclopedia editors

Quoting Sue Gardner: "...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. ..."[11]

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.[12]

Volunteers who work with foundation staff (SW Devs?) are not integrated with staff

The staff page shows only employees and contractors (here) implying others don't make a contribution.

Evidence presented by Dennis Brown[edit]

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)[reply]

It's déjà vu all over again

I hate to throw Erik's own words against him, but I found this link [13] while reading this [14]. 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 [15], or at least that was the basis for the original request. Dennis Brown | 2¢ | WER 12:41, 24 July 2014 (UTC)[reply]

Evidence presented by Alanscottwalker[edit]

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:[16]

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

Votes are evil

Pete knew who he was dealing with and why it was Erik

Pete, who was reverted, knows Erik, and Pete knew why it was Erik that showed up and it was not for Erik to make some personal edit [34], and Erik's edit summary said that his reversion was being done because of the WMF representative's earlier statement.[35] This fulfills the "otherwise stated" prong on Eric's user page, even if minimally, because "otherwise stated" does not restrict him to a specific formula, and there is no doubt under the full circumstance with the near simultaneous posting on Pete's page. Alanscottwalker (talk) 21:27, 15 August 2014 (UTC) Alanscottwalker (talk) 18:18, 17 August 2014 (UTC)[reply]

Evidence presented by Wbm1058[edit]

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)[reply]

I note today that the number of open bugs has grown to 105, i.e. not the direction one would expect of a product that's ready for prime-time.

There is one bug report I just noticed, that reflects the first issue that I noticed the first time I used the product. See T64266, MultimediaViewer should not leave so many history entries when closed. I don't know why I didn't notice this report before, except that it's listed as Status: REOPENED. Not sure whether closed items are included in the list, or when it might have been reopened. Anyway I find this one an eye-opener. The developers commenting seem to have a strong consensus that this is a problem needing fixed. I agree with the comments of Gergő, Vibber, Peterzell, Hartman, and kipod. Yet we have a lone developer who takes a dissenting view, and unfortunately, as they seem to be the only one commenting who is an actual developer of the product, this bug, or "unprioritized enhancement", remains unfixed since first reported on March 5. Quoting this developer: I think the mediawiki bias of "the articles are everything" is affecting your judgement. ... The question is not why 3 people on this ticket who share a bias by having spent too much time on a product that's always focused too much on text would prefer it to be that way. It's whether the majority of web users would find it to be a better/more logical experience. So far nobody here seems to have made any effort to justify the "pro" view using tangible arguments or real-world examples. It seems to be only driven by mediawiki distortion field where fullscreen images are so secondary that they don't deserve a place in the permanent browser history. – So that's it... we need to cater to readers who just read the encyclopedia for the pictures—like Playboy.

As this is all about user-interface design specifications, which if created at all, are created without community consensus, and the developers themselves cannot come to a consensus on the best program behavior in this situation, shouldn't they start an RfC to find out what the community of users wants? Wbm1058 (talk) 23:51, 16 August 2014 (UTC)[reply]

For those who may not be Jimbotalk-stalkers, I include in evidence this link to his subpage on MV:

Evidence presented by Erik Moeller (WMF)[edit]

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 [36] 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:

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 RFA 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 NE Ent[edit]

Contrary to Erik's statement above the main action which triggered this RFA / arbcom case was his acting like an ass [37]. Clearly WMF owns the site and can do what they want, but an assume bad faith threat to execute an out of (English Wikpedia) process desysop of an editor -- lacking any evidence that such action would be necessary is, in fact, incredibly not rational. (As a general rule, if you're using the phrase "no offense intended" [38], you are in fact, being offensive.) Given that the implicit mission of WMF is to try to motivate folks like Pete to continue to work for free, such engagement is counterproductive. NE Ent 22:08, 27 July 2014 (UTC)[reply]

Evidence presented by Risker[edit]

My evidence is in response to the questions asked by arbitrator Carcharoth on the evidence talk page.

Locus of the dispute

I disagree with Carcharoth's identification of the locus of the dispute as being the RFC. The locus of dispute is the MediaWiki:common.js page.

Requests for comment

Requests for comment are advisory, not regulatory; they suggest a course of action but do not require such action. As well, RFCs may come to a conclusion that is not enforceable or actionable, because it would violate an existing policy (e.g., an RFC that "approves" the use of an unreliable source for contentious information, or one that "requires" blocking or banning an editor), does not adequately take into consideration other related issues, may cause harm to the project, or has inadequate participation. Many RFCs, particularly on article talk pages, are never formally closed. As a more similar example, the RFC to remove VisualEditor as the default editor on this project showed a consensus to make that change, but the solution for implementing that change was discussed in multiple other forums prior to its application. Specific examples:

WMF Staff rights

History of WP:CONEXCEPT

MediaWiki:Common.js

Evidence presented by Pete Forsyth[edit]

WMF's Usability Testing: 0 of 3 users find "details" page

The Multimedia Team, which developed and implemented the Media Viewer, appears to agree with the Wikimedia community's conventional wisdom, that the information on the longstanding File Description pages has at least some importance, and is not completely irrelevant: on the main page for the Media Viewer, they have distinguished "Primary Info" from "Secondary Info." Central to the question of whether this software serves our purposes as a project, in my view, is whether or not a user is able to find that more detailed information when they want it. We are fundamentally in the business of empowering our users to access and share free knowledge. I believe ArbCom should carefully consider whether deploying this software was compatible with our shared vision and goals, and here I present evidence that should make it easy to do so.

The team ran a series of usability tests, in which readers were asked to perform a series of tasks to gather information about images in a Wikipedia article. The most recent round of tests, from May 2014, are available online.

I urge all arbitrators to watch these three videos (between 10-20 minutes each) to learn more about the understanding of reader experience the team developed prior to deploying the software. User 1, User 2, User 3.

Several of the questions might be effectively answered by consulting the original File Description page; Task #9 ("Can you find the camera model used to take this picture?") appears to be specifically designed to determine whether the user is able to find the more detailed File Description page. Other tasks, such as #12 "...can you make it bigger..." could also be answered by getting to that page.

In spite of trying in good faith to find this detailed information, not one of these three users ever clicked on the link to the File Description page that would have answered these questions.

At 12:49, User 1 tried to determine what camera model was used. Note where her cursor is hovering as she considers the question; she did not click.

Specifically:

I believe this is the best evidence generated by the Wikimedia Foundation's Multimedia Team about how end users will experience the Media Viewer software. It clearly demonstrates that three intelligent people, dedicated to completing a reasonable task, failed to even find the page -- the File Description page -- that would permit them to do so. But prior to the Media Viewer deployment, they would have landed on that page simply by clicking on the image.

Evidence presented by JMP EAX[edit]

I generally don't want to get involved in this kind of e-drama, but those videos posted by Mr. Forsyth remind me of this unmitigated fiasco of Windows 8's UI. JMP EAX (talk) 09:17, 1 August 2014 (UTC)[reply]

Evidence presented by Lixxx235[edit]

Eloquence made the revert of Peteforsyth on MediaWiki:common.js in his capacity as a regular member of the community and administrator, not a legal or official action.

Because this edit was not explicitly stated to be otherwise, per Eloquence's user page as of the revert, saying "Unless otherwise stated, any edit to Wikimedia projects by myself is an act of a regular member of the community and administrator, not a legal or official action", that edit is not an official action of the WMF. Eloquence did say that his threat to Peteforsyth was an official action, but did not say his revert was. Also, staff cannot decide later that edits they made were ‘official’ and that they accidentally omitted to say so. Cheers and Thanks, L235-Talk Ping when replying 15:39, 12 August 2014 (UTC)[reply]

Evidence presented by Alvesgaspar[edit]

The community appears to refuse any discussion with WMF while MV remains enabled by default

Following the RfC and the subsequent conflict an attempt was made by Fabrice Florin to resume dialogue with the community, not only in the English Wikipedia but also in Commons and MediaWiki. However only a couple of editors participated and the few responses were all negative (please see here, here and here). A recurrent argument used by the participants, including myself, is that no effective discussion between this community and WMF is possible while MV remains enabled by default. In my opinion the refusal of the editors to discuss the issue any further is extremely relevant and should be considered. It seems obvious that most of the pressure in the present conflict would deflate if the MV were disabled as a sign of good faith. Alvesgaspar (talk) 12:02, 20 August 2014 (UTC)[reply]


Evidence presented by {your user name here}[edit]

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.

More