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

Wikipedia Arbitration
About arbitration Talk Arbitration policy (CU/OS) Guide to arbitration Noticeboard + Talk Search archived proceedings Ban appeals Report
Open proceedings All open requests Case requests Clarification and Amendment requests Arbitrator motion requests Enforcement requests
Active sanctions Contentious topics (Log) General sanctions Editor sanctions
Arbitration Committee Discuss + Contact Members Procedures Elections Talk History Clerks + Talk Clerk procedures
Audit Talk Statistics Talk Reports (pre-2016)
Track related changes
t e

If you wish to submit evidence, please do so in a new section (or in your own section, if you have already created one). Do not edit anyone else's section. Please keep your evidence concise, and within the prescribed limits. When submitting evidence, please bear in mind that the locus of the dispute is the Media Viewer request for comments (RfC), and the actions that followed the RfC. If your evidence is outside this scope, please include supporting statements or background context to explain the relevance to the case. If you wish to exceed the prescribed limits on evidence length, you must obtain the written consent of a drafting arbitrator before doing so; you may ask for this on the Evidence talk page. Evidence that exceeds the prescribed limits without permission, or that contains inappropriate material or diffs, may be refactored, redacted or removed by a clerk or arbitrator without warning.

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

. 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

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.

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 63 editors calling for it to be disabled by default versus 6 ^{(see [4])} calling for it to be enabled.

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 (Added: June 23rd, Removed: July 13th)
• WP:VPT
• Wikipedia talk:Media Viewer

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.

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

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.

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]

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

(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
  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. [17]

• 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. [18]

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

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

• "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. [21]

• The
  WP:RFC

• After the WP:RFC, the representative of the WMF announced that the WMF would not go along with the close.[27] This consistent with past WMF practice.[28] [And subsequent statements by the Executive Director [29] ("MV" stands for Media Viewer) and the Board of Trustees [30]. -- Alanscottwalker (talk) 22:52, 14 August 2014 (UTC)(added this date)][reply]

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

Votes are evil

• Evidence asked to be entered to contextualize or contradict Wnt's from talk page.[33]

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]

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

]

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

• User talk:Jimbo Wales/NPOV report on problems with MV

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.

) 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:

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

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]

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:

• An Admin RFC cannot result directly in desysop; instead it can be used as evidence in a request for desysop made to Arbcom
• A user RFC cannot result directly in sanctions on a user; that must come from the usual community forums of
  WP:ANI
  or a request for arbitration
• Any RFC that establishes a "consensus" that is in turn a violation of a project policy has no validity, and
  WP:CONLIMITED
  applies

WMF Staff rights

• The staff right was first created in 2008, and its use has varied over that time. Once granted almost automatically to staff, and often granted at the sysadmin level, it is now far more restricted and is granted by stewards at the request of the designated WMF representative. The format for "staff account" usernames has changed over time.
• We do not know how often or under which circumstances staff permissions were used inappropriately; however, the community is aware of one situation where staff rights were used to inappropriately protect a page and take other actions. The staff member lost his staff permissions at least in part because of this incident. Regardless, staff rights are the domain of the WMF as an employer, and actions for inappropriate use of permissions whilst an employee are correctly the responsibility of the employer to address in a manner that respects the circumstances of the error. Arbcom may suggest whether or not rights should be retained, but it would be far beyond the scope of the committee to recommend any further disciplinary action specific to the employee operating the staff account. The community has the right to block accounts that behave in an unacceptable manner, regardless of their "owner", but the normal methods of addressing concerns with "experienced" users (i.e., starting with discussion and only blocking if there is no other alternative) still applies.
• Temporary desysops by individuals with WMF staff permissions may be reviewed by Arbcom, but Arbcom does not have the authority to reinstate the adminship - any more than the WMF could overrule Arbcom's desysop decisions. Temporary desysops are intended to prevent harm and remain in place until the threat of harm is resolved; it would be expected that the WMF would reverse the restriction once this issue is resolved. It is also possible that the WMF may elect to permanently remove admin/checkuser/oversight/steward permissions because of specific breaches of policy or ongoing risk that the user will return to the behaviour that caused the original permissions removal. For example, it is unlikely that the WMF will permit someone who has violated the checkuser policy when they were a checkuser on Project Wiki-Something to regain the checkuser permissions on any project in the future.

History of

WP:CONEXCEPT

• First appears in the consensus policy in 2007[39], at the time that the community was deciding whether or not consensus was indeed a policy and not just a guideline or commonly used process.
• At that time the WMF had three employees, and the overwhelming majority of those handling the technical maintenance, development and improvement of the WMF sites were volunteers; thus, the first entries relating to the CONEXCEPT concept refer to "developers"; I understand that volunteer developers sometimes rolled back site-specific edits, although I do not have any links for this. Over time, as the WMF has expanded its professional staff, the section has been reworded to recognize that WMF engineering staff and contractors have the same authority to invoked CONEXCEPT that volunteer developers do.
• The exact history is very tangled and seems to involve several pages whose histories may have been merged.
  • An early version appears in Wikipedia:Policies and guidelines in December 2005[40], with a pointer to how to make feature requests added in January 2006 when the policy was being re-organized.

MediaWiki:Common.js

• The current user rights configuration on all projects permits all administrators to edit this page, regardless of the administrator's understanding of the edits being made.
  • This is an artifact of the early days of adminship, where all but a few developers were volunteers; many administrators were granted their rights at least in part to handle technical/coding issues that involved the MediaWiki space. (Eloquence is an example of this, but is hardly unique. Many of those same users continue to contribute almost exclusively in the developer/technical sphere but still retain admin permissions.)
  • Many administrators have been advised not to "mess with" certain MediaWiki pages at the time that they were appointed, and it is extremely rare that any administrator candidate indicates a desire to work on the common.js or common.css, or that RFA candidates are asked about their skill level or interest in this area.
• The MediaWiki:Common.js page has user instructions at the top of the page and in the edit window that explicitly state "This is JavaScript for all users. Any changes to this page should first be proposed on its talk page or the Village pump. Please note that changes are visible within minutes. Errors you make here can disrupt the entire encyclopedia, so make sure you know what you are doing."
• On 24 July at approximately 0340 hours UTC, I made some inquiries on the #wikimedia-dev IRC channel (a logged channel) so that I could better understand the potential effects of additions to this page. Responses were received from volunteer, WMF staff and WMF contractor/volunteer developers. In brief summary:
  • Common.js doesn't run for users with Javascript disabled (i.e., the effect of a hack to this page does not affect all users equally)
  • Performance issues for all users
  • It is discouraged to do that by principle. $wg [extensions] are server configurations. They control whether code is executed and whether modules are loaded in the web browsers. [The] common.js executes inside your browser. if you disable a feauture there you basically first wait for the server to compute the feature, and for the web browser to load it all (and maybe even make part of it appear visually) only to then destroy it soon as it loads. Plus, the server configuration can also influence things you can't control in javascript. E.g. destroying LiquidThreads via common.js on a wiki where that is enabled would leave you with an empty page and no way to edit the talk page because it's controlled server side. (quoting Krinkle, who has been a volunteer developer for years and is currently a WMF contractor as well).
  • The entire server configuration is open source and editable in a wiki-page like fashion (see https://github.com/wikimedia/operations-mediawiki-config/tree/master/wmf-config). However, all changes that are placed in the server configuration undergo review by experienced developers prior to being activated. A community member could write a patch which then undergoes proper review and feedback, either submitting it directly through the existing processes or by filing a "bugzilla" and requesting that it be applied, with links to the appropriate consensus. See here for the process.
    • This is essentially what happened during the VisualEditor changeover, except that it was WMF staff who wrote the code to go into the server configuration to replace the MediaWiki:common.js hack. Note that the hack was not disabled until such time as the server configuration code was written, tested, reviewed, approved, and applied.

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.

Specifically:

• User 1 hovered over the "view details" link while considering the question, but did not try clicking it (13:10)
• User 2 never even scrolled within the Light Box/Media Viewer view, and so never found the somewhat detailed information within the new software ("Priority Info").
• User 3 has difficulty embedding the file in a Google Doc (which has perhaps been addressed by now, and if so is not in itself a problem). But her conclusion about why she had difficulty, even after exploring the Light Box page, is stunning: "It definitely looks like there are legal restrictions you'd need to know." "You'd probably need permission." This is the kind of thing we are seeking to avoid by providing access to freely licensed and public domain images. (12:30)
• User 3 hovers over the "view details" link (as User 1 did) while trying to complete the relevant task, but declines to click it. (13:51)

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.

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]

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,

]

Evidence presented by Alvesgaspar

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]

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.