Jump to content

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

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Arbitration | Requests | Case | Media Viewer RfC

This is an old revision of this page, as edited by Ariconte (talk | contribs) at 21:30, 2 August 2014 (→Evidence presented by Ariconte: fix typos). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

Case clerk: TBD Drafting arbitrator: TBD

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

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.

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:

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

Evidence presented by Ariconte

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]

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

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

  • 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. [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 (a "lightweight process") closed with a short closing statement that addressed no positions.[22][23] The Viewer had changed during the discussion,[24][25] 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.[26] This consistent with past WMF practice.[27]
  • 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) [28] and warned, identifying the action as for the WMF, enforced by the WMF.[29]. Both Editwar and WP:Wheelwar were avoided.

Votes are evil

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

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

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

Evidence presented by NE Ent

Contrary to Erik's statement above the main action which triggered this RFA / arbcom case was his acting like an ass [32]. 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" [33], 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

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:AN, 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[34], 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.

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.

Evidence presented by Pete Forsyth

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:

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

Evidence presented by JMP EAX

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Arbitration/Requests/Case/Media_Viewer_RfC/Evidence&oldid=619595854"