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

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

Case clerk: TBD Drafting arbitrator: TBD

Purpose of the workshop: The case Workshop exists so that parties to the case, other interested members of the community, and members of the Arbitration Committee can post possible components of the final decision for review and comment by others. 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. Components proposed here may be general principles of site policy and procedure, findings of fact about the dispute, remedies to resolve the dispute, and arrangements for remedy enforcement. These are the four types of proposals that can be included in committee final decisions. There are also sections for analysis of /Evidence, and for general discussion of the case. Any user may edit this workshop page; please sign all posts and proposals. Arbitrators will place components they wish to propose be adopted into the final decision on the /Proposed decision page. Only Arbitrators and clerks may edit that page, for voting, clarification as well as implementation purposes.

Behaviour on this page: Arbitration case pages exist to assist the Arbitration Committee in arriving at fair, well-informed decisions. You are required to act with appropriate decorum during this case. While grievances must often be aired during a case, you are expected to air them without being unnecessarily rude or hostile, and to respond calmly to allegations against you. Accusations of misbehaviour posted in this case must be proven with clear evidence (and otherwise not made at all). Editors who conduct themselves inappropriately during a case may be sanctioned by an arbitrator or clerk, without further warning, by being banned from further participation in the case, or being blocked altogether. Behavior during a case may be considered by the committee in arriving at a final decision.

Motions and requests by the parties

Template

1)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

2)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

3)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed temporary injunctions

Template

1)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

2)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

3)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

4)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Questions to the parties

Arbitrators may ask questions of the parties in this section.

Proposed final decision

Proposals by User:Wnt

Proposed principles

1) On Wikipedia, decisions concerning both content and formatting have been left almost exclusively to the editing community.

Examples: the choice of figures to include in an article, the preview resolution, the decision not to hide images e.g. in Muhammad, and the cropping of images in advanced tools like [1].

Comment by Arbitrators:

Is this really true, though? Aren't there some very basic aspects of how Wikipedia pages appear and work—the sort of things that experienced editors take for granted—that were established by the original developers long before any of us got here? Newyorkbrad (talk) 14:25, 21 July 2014 (UTC)

Comment by parties:

Comment by others:

Newyorkbrad: I think the original developers made decisions about the default appearances of figures and text that were quite good, enough that editors didn't go out of their way to change them. (So I would say, the decision was indeed left to us) We always had the right to make the text or the links in the article a different size or color, make all the previews 100px or 400px, etc., but we didn't want to. In this way the developers did guide the appearance of the site; but they did so by listening to the editors and trying to make popular decisions. So I'd say you're choosing between two competing models of "governance":

a) Devs design code that editors will like, editors mostly use it, and when they don't, they are free to change it, so devs take the hint and improve the defaults.

b) Devs design code that will somehow look good for them, editors hate it, and when they try to change it, the devs threaten them with sanctions.

We need to stick to model A here. Wnt (talk) 18:14, 21 July 2014 (UTC)

Not only is the second half mistaken, the examples all involve things in the context of article content. The Media Viewer opens a new window shorn of article content, and does not change article content format. And part of its rationale is less server load. Alanscottwalker (talk) 12:22, 24 July 2014 (UTC)

@Alanscottwalker: There are times when content and presentation can be separated in a writing project, but for our purposes this is a problematic boundary to use. Entire forests of virtual trees have been put to the axe to sustain Wikipedia debates about where images appear on a page, out of the belief that putting them up the wrong way will bias the article. For example, I recently had kind of a low point myself on an issue like this at [2], where I felt that technical difficulties with marking a dot on a map in an infobox had led us to convey a greatly exaggerated impression of the power and reach of a terrorist group.

I would encourage you to submit any data you have on the server load to the Evidence page, as this is potentially an argument and the issue should be examined closely. However, I would also ask how much of the server load improvement occurs simply by making it really difficult for inexperienced readers to find (or know about) the full-res versions of our images. I mean, the sysadmins could reduce server load by simply decreeing that no one uploads images at more than screen resolution in the first place. But that would be going too far - though they have indeed imposed hard limits, those limits are meant to be far out of the way of most participants. My feeling is that they're more within their proper authority to say that "this is too much for the servers and we say you just can't do it" than "this is putting some load on the servers so we insist you make it non-obvious how to do it". Wnt (talk) 13:14, 25 July 2014 (UTC)

The case page is in evidence. The point is, even were you able to run rings around the sysadmins' reasons, the decision still lies with the owner of the sys and not with Arbcom. That's the problem of this case, wrong forum. Alanscottwalker (talk) 13:40, 25 July 2014 (UTC)

I think it is still helpful to restate relevant evidence concisely on the Evidence page. Taking your hint, I did find this data that Eloquence signing as "Erik Moeller (speaking for the WMF)" referred to at [3]. I am a bit perplexed what to make of that data because initially the Media Viewer was no more efficient than the file page, and what actually changed (between June 3-7) was that the load time for anonymous users nearly doubled - 1.2 to 2 for the median, 4.5 to 7 for the 90th percentile. During the same period the numbers for anonymous file page readers dropped from 11M to 5M, and the numbers for Media Viewer increased from 62,000 to 7M. What this tells me is that first, there's reason to doubt the test comparison when the control group changes, and second, that the most common type of user, reading a page that was still being served to half the users at the time, could experience a nearly two-fold delay without anyone seeming to get upset about it. By comparison in the later data the Media Viewer is at 1.7 vs maybe 1.9 for logged-in and 2.0 for anonymous users, a smaller difference - and a value that is more than what it was for the average reader viewing the File pages before this started. I'd like to hear some explanation. Wnt (talk) 14:06, 25 July 2014 (UTC)

@Wnt:: as the person who has coded those charts, I would advise against jumping to conclusions from them - as the caption below the graph you have linked to warns, it is an experimental metric which contains some untested assumptions and should not be relied on. (I can go into details if you are interested.) Also, the numbers are quantiles - they change when the group which is being measured changes, even if there is no objective change to software behavior. --Tgr (WMF) (talk) 07:46, 27 July 2014 (UTC)

Well, my conclusion above was that I was "a bit perplexed", so I'll accept that this simply is not evidence of anything either way. But that leaves any claim of decreased server load without support, so far as I know. Wnt (talk) 23:47, 27 July 2014 (UTC)

That's a misunderstanding, or maybe I am misunderstanding what is meant by it, but decreasing server load was never a goal. (Media Viewer actually increases server load, although not so much that it would matter.) Decreasing loading time for the user was a goal, but the big difference between the old and the new workflow makes quantitative comparisons hard. (For example, Media Viewer preloads the next image, so it will display pretty much instantly; with the file page, going through multiple images is much slower. We know that users press the next button a lot, but whether they end up seeing an image which they care about (and so the user experience is much faster compared to the file page) or they are just shown an image they are not interested in (and thus their time has been wasted) is not something that can just be measured.) The graph you linked to only tries to make a comparison in one very specific case: between the file page and the first time Media Viewer loads any image on a given page (and so there is no preloading, and possibly the JS code itself needs to be loaded). For that case, I would go with "no definitive evidence either way". --Tgr (WMF) (talk) 05:01, 28 July 2014 (UTC)

I would tend to think of MV as "interface" not "content" or "formatting" and so this seems a bit of a red herring. A good analogy might be the switch to Vector - appearance is changed and interface is changed, but content/layout effectively untouched. Andrew Gray (talk) 22:22, 29 July 2014 (UTC)

2) The standard required to enable a MediaWiki tool in the English Wikipedia is stricter than mere availability or utility.

i.e. Many existing MediaWiki modules are not presently enabled on Wikipedia.

Comment by Arbitrators:

Comment by parties:

Comment by others:

i.e. Many existing MediaWiki modules are not presently enabled on Wikipedia.. From a technical point of view, the standards required to deploy a MediaWiki extension on WMF infrastructure is VASTLY higher. They go trough security reviews, performance reviews, overall code reviews, does it fit in with long term architectural views of the developers, does it do what it 'promises' to do. These steps often include volunteer developers. Wether or not something in that subgroups is enabled on Wikipedia, depends solely on wether or not it is usable for Wikipedia's, has been requested or denounced by the community or is currently in an evaluation or testing phase....

Is it being implied that English Wikipedia is different from Hindi Wikipedia and that Wikipedia is different from Wikisource (or should be) in required quality ???? I think the above statement (it's byline and the principle 3) therefore need to be much more specific in describing the context, or a separate principle needs to be added that clarifies this for ALL of WMF, before diving into English Wikipedia. —TheDJ (talk • contribs) 10:34, 31 July 2014 (UTC)

3) The standard for including a MediaWiki tool in the English Wikipedia may differ from that used by other Wikipedias.

For example, the other projects may enable different modules, have a different level of familiarity among editors for the fine details of image preview formatting, or have a different average ratio of Commons images to natural language text in its existing article base.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed findings of fact

1) The default use of the Media Viewer tool presently does not have consensus on English Wikipedia, and has been rejected by the standard RfC mechanism. Though it may be worthy of development and release, most readers do not find the tool useful, and even if a majority might eventually find it useful after becoming familiar with it, they have not yet used any community discussion mechanism to show widespread support for it be made the general default.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed remedies

1) The Arbitration committee has been given the power to determine whether an edit is supported by consensus. Ordinarily, its remedies involve the sanctions of users or admins who defy consensus, but this cannot apply to the WMF, which potentially can claim broad authority. However, ArbCom can make a very effective statement of the broad community consensus by directing a clerk or one member to make a carefully considered edit to Common.js that the Committee finds to be a fair interpretation of an established community consensus.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposals by User:Ariconte

Proposed principles

1) Staff and volunteers work together to make the foundation succeed. See: Shared power

Comment by Arbitrators:

Comment by parties:

Comment by others:

I thought I was working for creation of an encyclopedia, not for the success and greater glory of a foundation. The foundation handles the platform and creates software tools, the community creates the content, using the tools that suit it best. Carrite (talk) 18:47, 30 July 2014 (UTC)

I have tried to say the 'shared power' should be more clearly defined. I think the volunteer roles are different - editors volunteer to the projects... SW developers volunteer to the foundation. See below (in the remedy section) and here. Regards, Ariconte (talk) 22:13, 30 July 2014 (UTC)

I do not volunteer my software contributions to the foundation, I volunteer to the greater good of a Free and Opensource wiki software that can be used in large and complicated environments. I also volunteer to enable and facilitate the editors of the English Wikipedia community that I am a part of. —TheDJ (talk • contribs) 10:37, 31 July 2014 (UTC)

Thank you for all your contributions. Would you agree that you work *with* other volunteers and the foundation's paid employees in supporting the communities of encyclopedia (readers and editors) and wiki software users? Regards, Ariconte (talk) 03:36, 1 August 2014 (UTC)

Yes, that would be a better assessment. —TheDJ (talk • contribs) 12:07, 1 August 2014 (UTC)

2) Volunteer editors of the projects and other volunteers are in very different roles - they are volunteering to different causes - editing the projects vs supporting the foundation in it's mission.

Comment by Arbitrators:

Comment by parties:

Comment by others:

"editing the projects vs supporting the foundation in it's mission" much of my software volunteering is specifically to help out my fellow editors of the Wikipedia and Commons projects. It's why the whole software stack got built in the first place. The software is part of the mission. We are a movement and it takes many wheels to make it move forward. I'm part of the movement and I will not be relegated to being just a "volunteer for the foundation". Likewise I doubt anyone is here to just 'edit the project'. —TheDJ (talk • contribs) 11:00, 31 July 2014 (UTC)

Perhaps "foundation" should be "community"? (They are very different things, but these sentences feel like they're meaning to talk about the community of a hundred thousand not about the offices in SF) Andrew Gray (talk) 23:18, 31 July 2014 (UTC)

It is interesting to draw venn diagrams of the groups of people. I will do some work on this and see if I can produce better a explanation. Regards, Ariconte (talk) 03:36, 1 August 2014 (UTC)

Thank you for taking the time to come to a better definition. —TheDJ (talk • contribs) 12:07, 1 August 2014 (UTC)

Venn diagram showing relationships in the Wikimedia movement.

The motivations of the various parties working in the 'Movement' is important. The venn diagram helps when considering the relationships between the participants. Circle A represents the users of the movement; they may be readers, editors, or other groups that make use of the 'projects', within the circle are all the needs the users have - information, education, tools, etc.. Circle B represents the foundation and the services it delivers; along with the needs of the foundation to maintain itself including funding and PR. Circle C represents the motivations and needs of the volunteer community, these may include a desire to help, a political agenda, a desire to learn, etc. (McCurley, 2011, p.6 - see reference in 3 below)

The motivational circles overlap and these areas lead to different problems and opportunities. Area 1 is termed the 'perfect match' where the needs of the user, the foundation, and the volunteer are all satisfied; in the WMF this might be the OTRS volunteers answering mail sent from users to the foundation. Area 2 is 'still a good match' in that the volunteer views the foundation as the recipient; possibly a member of the FDC advisory group. Area 3 is where the foundation provides the service to the user - providing servers is a clean example; but some could be offered by volunteers as historically happened in Taiwan and the Netherlands. Area 4 is where editors who only edit articles are providing a direct benefit to the users. This are is the most likely area of conflict if as *in this case* a volunteer does something the foundation feels is their role. Regards, Ariconte (talk) 04:21, 2 August 2014 (UTC)

3) These two references:

McCurley, Stephen; Lynch, Richard, 1944- (2011), Volunteer management : mobilizing all the resources of the community (3rd ed.), Interpub Group Corporation, ISBN 978-1-895271-63-8{{citation}}: CS1 maint: multiple names: authors list (link) CS1 maint: numeric names: authors list (link)

Sakaduski, Nancy (2013), Managing Volunteers: how to maximize your most valuable resource, ABC-CLIO, ISBN 978-1-4408-0364-2

speak to 'how to run a volunteer program' and have lots of guidance.

Comment by Arbitrators:

Comment by parties:

Comment by others:

4) The movement has grown like a hippie flower - it now needs more structure in the foundation and the foundation's volunteer roles. Adding structure will alienate some people but most will acknowledge the need.

Comment by Arbitrators:

Comment by parties:

Comment by others:

I like hippies. I like flowers. And if Wikipedia is to have more structure it should be the structure of a hippie flower, with teams of creative volunteers freely drawing each petal on their own authority. This involves a certain lack of concern for whether the petals are uniformly consistent in the hobgobliny kind of way, and a certain need for genuine inspiration and sincere communication. Wnt (talk) 01:49, 26 July 2014 (UTC)

5) In this instance I believe both 'actors' acknowledge their mistakes; therefore no action required.

Comment by Arbitrators:

Comment by parties:

Comment by others:

6) Volunteers should be integrated into the foundations work.

Comment by Arbitrators:

Comment by parties:

Comment by others:

7) Each volunteer should know their role and the boundaries of that role.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed findings of fact

1) Arbcom does not have jurisdiction.^{Wikipedia:AP#Jurisdiction}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed remedies

1) Recommend to the Board of Trustees: The ED to hire a 'Manager of Volunteers' in the HR department. Manager of Volunteers to gradually bring the foundation into compliance with some quality standard such as: "Investing in Volunteers, Quality Standard". Volunteering England. Jan 2014. Archived from the original (PDF) on 2014-07-14.

While this document is a useful cross-check against a few dysfunctional aspects of Wikipedia, by and large I doubt it has received more insight, time, or critical consideration than Wikipedia's own policies, many of which are broadly consistent with it. Its description of the selection of volunteers through an application process is very different from Wikipedia's bold and successful vision. And hiring a manager to impose it as the master of all Wikipedia volunteers? Unless I misunderstand you this sounds like a huge mistake. Wikipedia does not need yet more hierarchy and bureaucracy in oversight of its volunteers (by which I take it you mean standard en.wiki administrative processes like ANI and ArbCom). What it needs is more democratic and popular outcomes through the use of a jury system for individual cases, and structurally a federalist arrangement with enumerated powers that distinguish the overall software development from decisions on content and presentation at individual wikis. Wnt (talk) 01:42, 26 July 2014 (UTC)

I think you misunderstand. I think the current en.wikipedia processes like ANI and Arbcom work well for editors of the encyclopeadia; I don't think these processes work for foundation volunteers (SW devs, FDC members, etc) see proposal 2 above. Also see: https://meta.wikimedia.org/wiki/User_talk:Ariconte/Volunteer_Management for a more involved explanation of what I am trying to say. Regards, Ariconte (talk) 14:39, 26 July 2014 (UTC)

@Ariconte: I find your essay informative but not persuasive. I would not see us routinely demand things like "loyalty" from volunteers who are working for the good of the project. Their work itself is all the loyalty we need; and when you assess loyalty, you mean loyalty to who? Because throughout history those are called disloyal who put their country above those in power.

In specific regard to images, I see for example that you would require all "Foundation volunteers" to follow "Foundation policies", i.e. [4], which includes for example a friendly space policy that I hold in particularly low regard. That policy might indeed provide a friendly space for someone like Elliot Rodger, the editor who removed the picture of a blowjob from blowjob; but so far as I understand it also clearly bans those such as Wikipedia:WikiProject Pornography from being properly represented at WMF events. Now, some might argue that such a policy is "realistic" given that there are those who would try to come into WMF events and do things to put them in ill repute, but ill repute would only accrue to those who allow themselves to be ashamed that we are not censored and cover whatever the world has given us to write an article about. The community has faced similar decisions and decided, in reality, to do things differently than this WMF policy wherever we have the power to do so. And the fact is, the community has worked many, probably most articles this way (Rodger notwithstanding), while the WMF's reach extends only to a few obscure conferences that very few of us ever attend and nobody ever hears about on the news.

So no, I don't want all volunteers regimented as Foundation volunteers under a single code of conduct enforced by a single master; I would rather focus on what we can do to make the project freer. Wnt (talk) 19:08, 26 July 2014 (UTC)

Editors are not foundation volunteers; making that clear is part of the problem. If the definitions here are accepted then the difficulty you are having goes away.

Project volunteers (editors) have no responsibility to the foundation. No leadership / managerial relationship. It is a very loose 'volunteering'.

Volunteers who agree to volunteer to the foundation have a responsibility to fulfil AND the foundation has a responsibility to the volunteer.

I think the poor communication resulting from unclear relationships leads to the misunderstandings --- people don't talk to each other. Regards, Ariconte (talk) 03:21, 27 July 2014 (UTC)

I understand the distinction you're trying to draw (such as it is), but our top priority here has to be to draw a clear line between the user community controlled content and presentation of the wiki and the supportive activities of WMF. If it is not absolutely clear that the "foundation volunteers" are not granted a supervote, then increasing the force of policies on the foundation volunteers means increasing the force that they have on our content. For example, to continue with the Muhammad images example I used before (see Evidence talk), a foundation volunteer right now is at risk of being accused of creating an "unfriendly space" by displaying a Muhammad image only if he does so at a conference, and the extent of the enforcement would appear to be (though I don't really know) limited to actions taken against him at that conference (plus the usual backbiting). However, if every foundation volunteer is obligated to follow all policies under the constant supervision of a master with the power to discharge them, then such policy would have greater reach -- for example, the volunteer might argue, having come up with a Javascript hack to the Media Viewer to hide those images unless the user logs in, requests they be displayed, says he's over 18 and not a Muslim, whatever ... then expanded to ban display of such images on user pages, talk pages, wikiproject pages, etc... that he is enforcing policy (the policy that now would apply universally to him and the other foundation volunteers) if he fails to force this on en.wikipedia like the Media Viewer was just forced on en.wikipedia. So I'm not seeing this suggestion as a productive option for us; it is a distraction from the real point that the community should be able to make its own content and presentation decisions. Plus, it is totally beyond ArbCom's purview anyway - how can they be telling WMF how they should supervise volunteers who are not specifically associated with the English version or the Wikipedia project in particular? Wnt (talk) 05:15, 27 July 2014 (UTC)

Hopefully someone gets some value from the discussion. Regards, Ariconte (talk) 07:53, 27 July 2014 (UTC)

2) The roles of the volunteers and the foundation be better defined (see proposal 3 above); this will result in the parties not 'stepping on each other's toes'.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposals by User:John F. Lewis

Proposed principles

1) Per the arbitration policy, "The Committee has no jurisdiction over: (i) official actions of the Wikimedia Foundation or its staff;"

Comment by Arbitrators:

Comment by parties:

Comment by others:

2) Per the policy about consensus, "Some matters that may seem subject to the consensus of the community at the English-language Wikipedia (en.wikipedia.org) are, in fact, in a separate domain. [...] operate however they deem necessary or appropriate, such as adding, removing, or changing software features (see meta:Limits to configuration changes), or accepting or rejecting images, even if their actions are not endorsed by editors here. [...] reminder that the decisions taken under this project apply only to the workings of the self-governing community of English Wikipedia."

Comment by Arbitrators:

Comment by parties:

Comment by others:

I think it is important to view this entire quote in context:

Some matters that may seem subject to the consensus of the community at the English-language Wikipedia (en.wikipedia.org) are, in fact, in a separate domain. In particular, the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, and the activities of Wikimedia Commons, are largely separate entities, as are the many non-English Wikipedias. These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features (see meta:Limits to configuration changes), or accepting or rejecting images, even if their actions are not endorsed by editors here. This does not constitute an exhaustive list as much as a reminder that the decisions taken under this project apply only to the workings of the self-governing community of English Wikipedia.

From this it is clear that they are speaking of the ability of Commons participants on the Commons project to accept or reject images for submission to Commons, not that developers have some kind of control over whether or how we display images in articles on en.wikipedia.org itself. The policy is emphasizing that we have control over en.wikipedia.org but not www.mediawiki.org or commons.wikimedia.org; it is clearly not disavowing control over the former.

It is true that meta:Limits to configuration changes lists some cases in which configuration changes approved by the community have been rejected by the sysadmins. However, these are not edits to pages on the wiki. The wiki pages have been placed under the control of editors and administrators, and as of the present this policy does not list any pages on this wiki, or any editing actions or decisions, that are outside of the purview of the community, apart from the narrow cases of board decisions, office actions, and decisions of this committee. Wnt (talk) 17:40, 21 July 2014 (UTC)

The issue here is; the community are 'abusing' (can't think of a better word right now) a privilege to overcome a decision by the WMF. This is the issue here. John F. Lewis (talk) 17:18, 27 July 2014 (UTC)

This remains to be decided. I think it's clear that WMF employees don't have a supervote over how we edit the Main Page, In The News, or any other high profile page, apart from the very narrow case of office actions of very limited scope that are initiated with a certain degree of care and legal consultation. Generally speaking, it appears that when a setting is accomplished by changing a page on the wiki, the users of the wiki (or the admins thereof) are supposed to decide how to set it. If Common.js is actually an exception to this, then somebody somewhere needs to actually draw out this exception, explain it and say exactly what pages "aren't really part of en.wikipedia and the admins here are just able to access them by courtesy or accident". So far it is not clear to me that this was ever an intended distinction. This isn't strictly a play for power; it's necessary for good order, a matter of knowing who actually does have the say over a page like this in the event of an edit war. What we should not accept is a situation where a few people from the WMF decide they get to override en.wikipedia about whatever issues they feel like today, and they can choose out new ones tomorrow. Because in that event we're not really in charge of writing an encyclopedia at all - we're only pretending and messing around in the WMF's draft space until they get around to reverting us. Wnt (talk) 23:57, 27 July 2014 (UTC)

Proposed finding of fact

1) The Wikimedia Foundation had given sufficient notice to the community that it had intended to enable Media Viewer for the whole community by default. (See the evidence)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Are you saying that silence implies consent? If so, silence in what forum? Whenever surveyed, whenever discussed, the community gave notice that it did not approve of the Media Viewer. If someone looks at the small numbers at the small tail of the survey and says that they're proof that someday, people might support more than oppose its use, is the community required to respond to this with great volume, multiple RfCs, letter writing campaigns, people picketing the WMF and climbing the Reichstag? I would say not, so I'd say this point is not relevant to the case. Wnt (talk) 17:47, 21 July 2014 (UTC)

I hope it is not the intention, but this proposed finding rather suggests that new software features are to be enabled regardless of the views of those who actually use the software. WJBscribe (talk) 10:45, 22 July 2014 (UTC)

I note in particular Resolution:Wikimedia Foundation Guiding Principles (Share Power): "The Wikimedia Foundation works in partnership with a global community of volunteers made up of article writers, copy-editors, photographers, administrators, page patrollers, quality assessors, translators, wiki-gnomes, help-desk staffers, developers, bot creators, people who do outreach work and many others. These are the people who build the projects, and they are the Wikimedia Foundation's partners in developing the platform." I think a lot (most?) of the editor community does not feel that it is a "partner" in the development of the platform, quite the contrary. This needs to be rectified. WJBscribe (talk) 10:53, 22 July 2014 (UTC)

My intention was the say, the fact the community didn't go 'we disagree' but instead let hell break loose after it was enabled, is the communities issues not the Foundations. They gave notice - the community should have came to decision before the feature was enabled not after. If before, the Foundation most likely would have gone 'We're listening, we'll hold off for now, but explain why please.' John F. Lewis (talk) 17:18, 27 July 2014 (UTC)

I agree with WJBscribe. What should be given is not "notice", but consultation. If the en-wp editor community doesn't want a feature, it shouldn't be getting enabled. Seraphimblade ^{Talk to me} 10:47, 22 July 2014 (UTC)

What I am trying to get across is; it is a two-way street. If we wait on the edge for consultation - many wikis will be out of date. Just because the enwiki has an active community does not exempt it from the same treatment every other wiki gets. The Foundation has a role to provide new features and allow communities to grow by providing features for them. It is the communities responsibility to come to a conclusion on whether they want these feature by default prior to their release, not after it is released and then play up because they don't get what they want. We're a community, not someone who plays up because we don't get what we want. We need to grow and communicate, the Foundation provide us with features, options and discussions - it is not their fault we choose to use these options after we've been given 8 months to use them. John F. Lewis (talk) 17:18, 27 July 2014 (UTC)

It's also worth bearing in mind that while consultation may not have been perfect, there was some. Groups of users were being brought it to discuss this with developers from late-2013 (I know, I was at one of the discussions...). The tool was released as a live beta available on enwiki from March onwards, during which time feedback was sought and the tool was developed and revised. While I understand the objections to the level of consultation, I think we should be careful not to interpret this as "the Foundation rocked up one day and deployed the software". Andrew Gray (talk) 22:32, 29 July 2014 (UTC)

2) The English Wikipedia administrator Peteforsyth added a piece of javascript code to MediaWiki:Common.js with no knowledge insufficient understanding of what the code would do. As a result, he was swiftly reverted by administrator Eloquence acting in his role as Deputy Directory of the Wikimedia Foundation.

Comment by Arbitrators:

Comment by parties:

The phrase "no knowledge" isn't quite right, but I would be fine with "inadequate knowledge," "insufficient knowledge," or -- maybe best -- "insufficient understanding" -Pete (talk) 18:36, 21 July 2014 (UTC)

(I also don't really understand why this is a finding worthy of inclusion. I made a mistake, which had a consequence no more negative than the state of Wikipedia for the last decade or so; that consequence was reversed in 7 minutes. This is a wiki; occasionally things like this happen. I don't see the purpose of calling this one out -- nor of calling out Erik's words accompanying his reversion. -Pete (talk) 18:43, 21 July 2014 (UTC)

I've changed it respectively. It is also here as it provides a small insight in the fact the community tried something, but it was reverted for valid reasons. John F. Lewis (talk) 17:18, 27 July 2014 (UTC)

Comment by others:

(Non-administrator comment) This finding is not worthy of inclusion. Regardless of the efficacy of Peteforsyth's edits, he did not act unwittingly and his change to the default settings cannot be seen as an obvious mistake reverted by a well-meaning WMF employee. Chris Troutman (talk) 19:35, 21 July 2014 (UTC)

Explain? From what I see, he did make an edit that was obvious mistake and was reverted probably not by a well-meaning employee, but was reverted by an employee for more than valid reasons. John F. Lewis (talk) 17:18, 27 July 2014 (UTC)

Peteforsyth acted to carry out the consensus of an RfC and his bungled change to the coding is immaterial to his intent. Eloquence/Erik Möller acting on behalf of WMF reverted that edit not as a matter of coding but as a rejection of en-wp consensus. Eloquence/Erik Möller's statement after the fact confirms that he wasn't simply reverting an accidental edit but was taking an OFFICE action and he threatened a extrajudicial desysop as well. To portray otherwise, I assume, is an attempt to excuse imperial overreach under the guise correcting a javascript error. I feel the finding is unworthy of inclusion because it's plainly false. Chris Troutman (talk) 04:00, 30 July 2014 (UTC)

Proposed remedies

None yet; working on drafting a few out - John F. Lewis

Proposals by User:Kww

Proposed principles

Consensus for a feature doesn't automatically extend to overriding WMF

1) It is quite possible that the community can reach a consensus on an issue without simultaneously agreeing that it is worth a battle with the WMF.

Comment by Arbitrators:

Comment by parties:

Comment by others:

.js files are within the Wikipedia community's remit

2) Wikipedia's consent process, including RFCs, extends to all files that a Wikipedia editor or admin can edit.

Comment by Arbitrators:

Comment by parties:

Comment by others:

True, but it also requires people to defer to those with the specialized knowledge that is required to properly edit these files. And website infrastructure stability, performance and user security trumps community consensus. —TheDJ (talk • contribs) 11:08, 31 July 2014 (UTC)

Overriding the WMF requires explicit consensus

3) When an edit is known in advance to be against the desires of the WMF, the editor making that change should, through community discussion, ensure that there is consensus that the issue is sufficiently important that risking a conflict with the WMF is justified.

Comment by Arbitrators:

Comment by parties:

Comment by others:

WMF membership is an explicit conflict of interest

4) Being an administrator on Wikipedia makes an administrator subservient to community consensus. It is impossible to simultaneously be a member of the WMF and subservient to community consensus.

Comment by Arbitrators:

An administrator who is an WMF employee or contractor can perform almost all routine administrator functions on a day-to-day basis without any conflict of interest, so long as he or she is scrupulous about keeping his or her roles separate. It is only in the rare instances where the staffer/administrator action is one on which the WMF has a specific position in tension with that of the editing community that a COI would be implicated. Newyorkbrad (talk) 21:12, 31 July 2014 (UTC)

Kww, suppose a staff member who is also a community-chosen administrator (hypothetically, Eloquence himself or one of the others you mentioned) spends some hobby time doing everyday administrator stuff, closing some routine XfD's and blocking a few vandals. How does he or she have a conflict of interest? In other words, whose interest would he or she be at risk of promoting over Wikipedia's? Newyorkbrad (talk) 03:23, 2 August 2014 (UTC)

Comment by parties:

Comment by others:

Administrators are only administrators on a privately owned website. Alanscottwalker (talk) 14:30, 29 July 2014 (UTC) Moreover, consensus on Wikipedia means Administrators and Users acknowledge that it is constantly subject to change, and challenge and that it is limited, provisional, and preempted. Alanscottwalker (talk) 15:37, 29 July 2014 (UTC)

This gets to the meat of the issue here, in my opinion, lectures to me by some folks about peace-love-hugs-harmony-and-happiness notwithstanding. We have in this case (once again) a clash of interest groups, the solution of which needs to be negotiated. On the one hand are the readers, who just want something that looks nice and works fast. Then we have the volunteer community, who wants software that helps produce content efficiently. Then we have WMF, which is now a $50 million a year company heading for 240 paid employees, with its specific own set of internal interests — executives with careers, engineers seeking success and promotion, and so forth. Where contradictions emerge between the desires and interests of the volunteer community and the internal desires and interests of WMF, it is impossible to serve two masters. Administrators on the WMF payroll should be stripped of community tools and those individuals identified with a "(WMF)" user name when they participate on-wiki so that the inherent group interests can be readily identified. This suggestion is a big step towards that necessary state of affairs. Carrite (talk) 18:24, 31 July 2014 (UTC)

Newyorkbrad, I'd be interested in trying to flesh that out. Erik, Phillipe, WhatamIDoing, Maryam, and a few others are clearly in the group I'm trying to address here. Can you give a few examples of people that wouldn't have an inherent tension and maybe a suggestion as to how to delineate the distinction? If you are saying that Phillipe and Erik are only occasionally conflicted I'm fairly certain that I would disagree with that, but I'm willing to concede the point on people with lesser roles.—Kww(talk) 21:43, 31 July 2014 (UTC)

Newyorkbrad, that's not the definition of a conflict of interest: the test isn't on an edit-by-edit basis or an action-by-action basis. The question is whether their position places them in a situation where there are times that they may use their tools to further the WMF's interests over the community's.—Kww(talk) 06:35, 2 August 2014 (UTC)

Proposed findings of fact

Template

1) {text of proposed finding of fact}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

2) {text of proposed finding of fact}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed remedies

Note: All remedies that refer to a period of time, for example to a ban of X months or a revert parole of Y months, are to run concurrently unless otherwise stated.

Unofficial WMF administrative accounts forbidden

1) All administrative accounts owned by WMF members that are not designated as WMF accounts are hereby desysopped, with all advanced permissions removed.

Comment by Arbitrators:

Absolutely not. AGK [•] 11:21, 2 August 2014 (UTC)

Comment by parties:

Comment by others:

This is right on the money. One person-one account. And those on the WMF payroll need to be identified as such. Carrite (talk) 18:29, 31 July 2014 (UTC)

Would this affect any account that actually got permissions through the normal community processes? Nikkimaria (talk) 01:06, 1 August 2014 (UTC)

As written and intended, certainly.—Kww(talk) 01:32, 1 August 2014 (UTC)

Then I would object very strongly to it. The benefits gained from desysopping someone like User:Moonriddengirl/User:Mdennis (WMF), who in her volunteer capacity does incredible work addressing copyright issues, are far outweighed by the costs. Nikkimaria (talk) 02:33, 1 August 2014 (UTC)

Remaining WMF administrative accounts restricted

2) Remaining administrative accounts, those explicitly designated as WMF accounts, are restricted to using their permissions only for OFFICE actions. Any administrator, upon observing an action taken by one of these accounts that is not accompanied by an explanation of precisely how the action is mandated by WP:OFFICE, is free to reverse said action at any time. If the action is justified by WP:OFFICE but exceeds the minimum action necessary action to accomplish the legal requirements upon the WMF, any admin is free to modify the action to bring it to the minimal compliant state.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Admins don't have any competence or authority to govern the WMF concerning its legal and technical domain. Alanscottwalker (talk) 14:28, 29 July 2014 (UTC)

That's untrue. Look at the fiasco involving Phillipe earlier this year, where he attempted to claim a legal mandate to protect Conventional PCI at PC2, which not only violates our protection policy but, given the current state of PC2 on English Wikipedia, allows random editors to approve changes to the article. He falsely labeled that as being an WP:OFFICE action, refused to admit that his misapplication of PC2 protection was not justified by WP:OFFICE, and, just as in this case, made threats to desysop an admin out of process. It didn't take any special competence to see that he was in the wrong. This would attempt to make it clear that WP:OFFICE is a policy with a boundary: it's intended to keep the WMF out of legal trouble, not an avenue to make irrevocable changes to things while making illegitimate threats.—Kww(talk) 13:31, 1 August 2014 (UTC)

No. Admins have no ownership, no authority nor control of the WMF's domain. Admins have no legal competence; have no legal authority; and have no relevant legal liability, and cannot dictate to the WMF. The purpose, here, is not to re-litigate that: [5]. Alanscottwalker (talk) 14:27, 1 August 2014 (UTC)

I'm not asking that my admonishment be vacated: pretty much any neutral party recognizes that it was groundless. Phillipe's action there combined with Erik's similar overstep here does form a pattern of overstepping the bounds of WP:OFFICE to enforce personal preference.—Kww(talk) 14:33, 1 August 2014 (UTC)

No. They are acting as agents for the WMF. Personal preference is irrelevant, except to the extent that you just want to replace the WMF's decisions with others' personal preference (the preference of those without ownership or competence). As for your first sentence, the committee already disagreed. Alanscottwalker (talk) 14:43, 1 August 2014 (UTC)

These two remedies would effectively define that employment by WMF makes anyone, regardless of who they are, no longer a trusted member of the community regardless of whether they are acting in an official capacity or not. If that's intentional, it seems very disproportionate. Andrew Gray (talk) 22:40, 29 July 2014 (UTC)

To say that someone has an irreconcilable conflict of interest doesn't cast aspersions on their character: it simply says that one role precludes the other.—Kww(talk) 00:09, 30 July 2014 (UTC)

It's also based on the reality that most WMF accounts seem to have gained their admin status through direct appointment rather than the normal community vetting process. So in a sense the community hasn't determined that they're trusted members in the standard, formal sense. Intothatdarkness 18:34, 30 July 2014 (UTC)

Not really; the first section explicitly talks about removing adminship from personal accounts (which in most cases predate employment), hence the deeply problematic effect of the two sections combined. I'm entirely happy with the idea that admin rights issued to (WMF) accounts should be used for the limited purposes it was given - and WMF has also been clear on this in the past - but that's a very different thing to saying "and you can't have adminship otherwise". Andrew Gray (talk) 20:10, 30 July 2014 (UTC)

I'm not of the opinion that they "can't have adminship otherwise" (I don't assume to speak for KWW, of course), but they should have to go through the standard processes (RfA) for their non-WMF account just like anyone else. Intothatdarkness 21:53, 30 July 2014 (UTC)

That's a bit more relevant to the earlier point. This point is about what they can do with an account designated as a WMF account.—Kww(talk) 13:20, 31 July 2014 (UTC)

Proposed enforcement

Template

1) {text of proposed enforcement}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

2) {text of proposed enforcement}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposals by User:Dank

Proposed principles

Appreciation for a job well done

1) In the day-to-day experience of most enwiki users, the mediawiki interface runs so well that we don't even think about it. Appreciation for a job well done is in order, to the paid and volunteer coders who share our vision and are part of our community.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Requests for Comment (RfCs)

2) The enwiki community likes to participate in votes (generally through RfCs) on questions of interest, and this system seems to have served us well: no one predicted that volunteers would be able to create the world's busiest site for serious content with nothing but informal discussions and votes to guide us. RfCs allow voters from different backgrounds and with different goals to speak in their own voice and work at their own pace. It's not reasonable to expect that all the voters in an RfC will focus on a single question and reliably deliver a quick answer that reflects the views of the larger community, but a series of RfCs and informal discussions will usually produce a result everyone can live with, eventually.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed findings of fact

Lack of effective communication

1) The coders seem to have been genuinely surprised by the enwiki community's reactions to Image Filter, Pending Changes, Visual Editor, and now Media Viewer. Although the coders have generally invited feedback during development, the invitations don't seem to have worked well with the enwiki community, which generally prefers to discuss proposed changes through informal and formal processes on enwiki. The community has been slow to initiate RfCs on desirability and functionality of proposed interface changes.

Comment by Arbitrators:

Comment by parties:

Comment by others:

There's genuine surprise, certainly, but I think it's a cultural gap, not a communication gap. The coders tend to view us as a part of the user community and are quite surprised to find that we think we can tell them what they should do, reconfigure the software they deliver, and even disable it when it fails to meet quality expectations. We, on the other hand, tend not to understand why they consider anyone's opinion but our own to have any importance.—Kww(talk) 14:38, 31 July 2014 (UTC)

When we face a difficult new question, we tend to start off that way, resistant to outside influence. After we've gained some confidence through a process of figuring out what our community wants, we usually ease up a bit. - Dank (push to talk) 15:20, 31 July 2014 (UTC)

As a volunteer who regularly attends MW technical meetings, I can say beyond reasonable doubt that it is hardly a surprise to the developers... Unfortunately, it is by now sort of a given that deploying features to the larger Wikipedia's is an excruciating painful proces that few developers look forward to... If we look at this feature in particular, I would like to mention that this is a relative new team, so it's more difficult for them to assess and think of the 10000's of things that the more experienced teams know about our very diverse community. —TheDJ (talk • contribs) 19:17, 2 August 2014 (UTC)

Proposed remedies

Continuing discussions

1) A series of RfCs and informal community discussions are recommended for all interface changes (including Media Viewer, Visual Editor, and Flow). Discussion is also recommended on how to get better results in difficult RfCs.

Comment by Arbitrators:

Comment by parties:

Comment by others:

I would suggest: "....informal community discussions and formal RfCs are recommended..." — It is important to state that the RFCs are the binding expressed consensus of the community. It is also vitally important to make it clear that this case is not just about the (relatively innocuous in the big scheme of things) MediaViewer, but also relates to the VisualEditor and Flow projects — one of which has already proven to be massively disruptive and one of which may potentially have an even bigger and longer-lasting negative impact. This proposal names the software projects, and so should ArbCom's final decision. Carrite (talk) 18:36, 31 July 2014 (UTC)

How about "RfCs and informal community discussions"? (Thanks for catching that!) - Dank (push to talk) 18:41, 31 July 2014 (UTC)

Although I appreciate it that the community feels this way, it is simply no way to build code. Unless the community also does the design and startup fases of the software development, realistically, this will simply not work (aka, create such a convoluted proces that developers rather would NOT contribute to the software/work for the foundation). The community is always welcome to track the progress of any software development, but historically, they have simply NOT, this is part of the problem. —TheDJ (talk • contribs) 19:22, 2 August 2014 (UTC)

Proposals by User:Andrew Gray

I haven't contributed to an Arbcom discussion before this one; please accept my apologies for any missteps in protocol!

Proposed principles

1) Wikipedia is a collaborative project, where both the volunteer editors and technical contributors, both paid and unpaid, are part of a broad community working to create an encyclopedia. Conflicts between groups in this community are inevitable but do not imply fundamental and irreconcilable differences.

Comment by Arbitrators:

Comment by parties:

Comment by others:

2) The Wikipedia community expects major discussions to be taken by consensus, with progressively higher levels of community involvement as decisions become more significant. Participants in these discussions are expected to be respectful and reasonable, and endeavour to resolve their differences amicably. This system usually works out in the long run (it's certainly got us this far).

Comment by Arbitrators:

Comment by parties:

Comment by others:

3) While "bold, revert, discuss" does not have the status of a policy, it is widely accepted as a standard and neither "bold" nor "revert" is usually considered inappropriate if done in good faith. This approach is often used on meta-issues as well as in content editing.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed findings of fact

1) In the past, there have been a number of major software deployments or proposals by the Foundation (or occasionally by third parties) which have caused significant controversy and led to detailed community discussions, either on enwiki or at a meta level. This can be considered as a recent instance of this ongoing history.

Comment by Arbitrators:

Comment by parties:

Comment by others:

2) In most cases, this discussion has resulted in an agreed path forward. This has in some cases (image filter) been "remain on the status quo" and a complete dismissal of the technical proposals. In others, the software has been modified after deployment (Notifications and the "orange bar") or withdrawn/sidelined pending further work (visual editor, pending changes). Even on highly divisive and disputed site changes, representing significant amounts of invested effort, the consensus arising from these discussions has generally been honoured by all parties, including WMF.

Comment by Arbitrators:

Comment by parties:

Comment by others:

3) The approach of a public beta-test period followed by widespread deployment for all users was used for the change to the Vector skin (in 2010) and was broadly successful in handling this change. A similar approach was planned for MediaViewer.

Comment by Arbitrators:

Comment by parties:

Comment by others:

4) The request-for-comment to shut off MediaViewer was organised in good faith and was advertised to the community, with around 110 editors participating of whom perhaps 70 expressed a firm opinion. However, this number is historically low; for example, the initial RFC on Visual Editor issues attracted around 150 users while the subsequent RFC on its default state (a direct analogy to this discussion) had around 900 participants. Through no fault of the participants, this falls below the level of participation normally expected for discussions about major interface elements or software deployments.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed remedies

Note: All remedies that refer to a period of time, for example to a ban of X months or a revert parole of Y months, are to run concurrently unless otherwise stated.

1) Given the relatively low turnout in the discussion - and the clear community interest - this RFC should be reopened for further discussion by the community, building on the precedent of the second VE RFC. It is likely that a larger turnout will give a firm sense of the overall community consensus and provide a clear path forward.

Comment by Arbitrators:

Comment by parties:

Comment by others:

It would perhaps be interesting for this RFC to look at approaches such as enabling MediaViewer in specific namespaces, enabling it only after certain changes are made, etc. - but not sure if suggesting that is out of scope here. Throwing it in as a footnote anyway. Andrew Gray (talk) 23:22, 31 July 2014 (UTC)

Proposed enforcement

For these proposals, enforcement would seem inappropriate.

Proposals by User:Carcharoth (principles)

These draft proposals are from a copy worked on by a number of arbitrators (though primarily by the drafting arbitrators). They are not set in stone and the aim is to make additions/changes as needed before the case moves to the voting stage. Carcharoth (talk) 16:51, 2 August 2014 (UTC)

Role of the Arbitration Committee

Advanced permissions

1.1) The role of the Arbitration Committee, as laid out in the Arbitration Policy, includes handling requests relating to administrative conduct and the removal of administrative tools, as well as overseeing the granting, removal and use of other advanced permissions. The processes related to the handling of administrator tools and other advanced permissions are documented at the Committee's procedures page, and involve liaison on the English Wikipedia with Bureaucrats, and outside the English Wikipedia with Stewards, Wikimedia Foundation staff, and the Foundation Ombudsman Commission.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Jurisdiction

1.2) The Arbitration Policy states that the Committee has jurisdiction within the English Wikipedia, but has no jurisdiction over: (i) official actions of the Wikimedia Foundation or its staff; (ii) Wikimedia projects other than the English Wikipedia; or (iii) conduct outside the English Wikipedia. The Committee may take notice of conduct outside its jurisdiction when making decisions about conduct on the English Wikipedia if such outside conduct impacts or has the potential to impact adversely upon the English Wikipedia or its editors. The Committee's procedures page notes in relation to the CheckUser and Oversight tools that "Stewards and Wikimedia Foundation staff granted CheckUser and Oversight permissions by the WMF are outside of the jurisdiction of the Arbitration Committee."

Comment by Arbitrators:

Comment by parties:

Comment by others:

Role of the Wikimedia Foundation

The Wikimedia Foundation (WMF - wikimediafoundation.org) exists to support the Wikimedia projects, including the English Wikipedia. It manages programmes, community advocacy, and software development and roll-out across many projects. To further that mission, WMF staff and contractors are often (but not always) given labelled "(WMF)" accounts to separate their work and personal contributions. If needed, they are granted advanced permissions, usually accomplished through a grouping of global rights permissions known as 'staff' (established September 2008). These staff permissions include the 'userrights' permission (added 30 June 2010), which allows user rights for any user on any WMF wiki to be changed.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Wikimedia Foundation-community relationship

Shared power (1)

The English-language Wikipedia (en-WP) is built, produced and maintained by a large number of individuals and groupings, sometimes referred to collectively as 'the community' (see Wikipedia:Wikipedians). The role of such communities was acknowledged by the WMF's Board of Trustees in Resolution:Wikimedia Foundation Guiding Principles (Share Power) (30 May 2013):

"The Wikimedia Foundation works in partnership with a global community of volunteers made up of article writers, copy-editors, photographers, administrators, page patrollers, quality assessors, translators, wiki-gnomes, help-desk staffers, developers, bot creators, people who do outreach work and many others. These are the people who build the projects, and they are the Wikimedia Foundation's partners in developing the platform."

Comment by Arbitrators:

Comment by parties:

Comment by others:

Shared power (2)

The relationship between the Wikimedia Foundation and the communities that build its projects is based on the principles of mutual respect and shared power (WMF Board of Trustee's resolution: 30 May 2013). In the case of the English Wikipedia, this applies to the pursuit of a common goal: the creation of a free encyclopaedia. Software features developed by the Foundation are meant to make it easier for editors to achieve that result; consequently, the Foundation ought to heed and act in good faith on the feedback of the community, even when the consensus is that a specific feature should be disabled by default.

Comment by Arbitrators:

Comment by parties:

Comment by others:

MediaWiki and Media Viewer

MediaWiki (mediawiki.org) is free and open-source software used by WMF wikis and other wikis; its development is led by the Wikimedia Foundation. Media Viewer is an extension to the MediaWiki software that is intended to improve the appearance of and user interaction with images.

Comment by Arbitrators:

Comment by parties:

Comment by others:

MediaWiki namespace and CSS and JS files

The MediaWiki software includes an interface known as the MediaWiki namespace. On the English Wikipedia, this is used primarily to store text to be used in messages elsewhere on the site. The MediaWiki namespace also contains sitewide JavaScript and CSS (Cascading Style Sheets) files that are used for styles and scripts that are specific to the English Wikipedia. Any changes to these files affect all users of the English Wikipedia. The editing of the sitewide CSS and JavaScript files (limited to administrators) has been carried out primarily by MediaWiki developers and administrators familiar with the coding language, or following an edit request and discussion on the talk pages (1, 2).

Comment by Arbitrators:

Comment by parties:

Comment by others:

Consensus (limits and exceptions)

The English Wikipedia policy on consensus states that: "Consensus is Wikipedia's fundamental model for editorial decision-making". The policy further states that some decisions relating to the English Wikipedia are not subject to consensus of editors (WP:CONEXCEPT), giving the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, as an example of a community that: "operates however they deem necessary or appropriate, such as adding, removing, or changing software features [...], even if their actions are not endorsed by editors here."

Comment by Arbitrators:

Comment by parties:

Comment by others:

Communications, discussions and liaisons

A variety of mechanisms and locations exist for communications and discussions between the Wikimedia Foundation, and the developer and editorial communities. These include newsletters, noticeboards, mailing lists, on-wiki discussion pages and fault-reporting sites such as Bugzilla. These communication and discussion methods are used to a varying extent by WMF staff, developers and members of the English Wikipedia editorial community. In addition to this, a number of individuals hold specific community advocacy roles to liaise between the WMF and the English Wikipedia editorial community.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Requests for comments mechanism

Requests for comments (RfC) is one of the dispute resolution mechanisms in use on the English Wikipedia. RfCs are an informal process used to gather opinions and form consensus on a wide range of issues, from local article talk page disputes involving a small number of editors, to site-wide changes affecting large numbers of editors. RfCs may be publicized as described at the RfC page. Further guidance is provided at Wikipedia:Publicising discussions. An RfC is advisory rather than regulatory: any closing statements are recommendations, and actions proposed following some RfCs will require a further discussion or decision in another venue prior to enactment. Any uninvolved editor can close an RfC, though some large-scale RfCs have been closed by one or more experienced administrators and editors. Formal closure can be requested, and guidance is provided at Wikipedia:Closing discussions.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Administrators

Administrators (care and judgement)

Administrators are expected to use care and judgement in the use of their tools. This includes the ability of administrators to edit protected pages and pages of a technical nature that can affect the entire site. In such cases, administrators are expected to act with caution, to respect warnings and edit notices, to recognize their personal limitations, and to consult and obtain specialist assistance as needed.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Administrators (community trust)

Administrators are expected to lead by example and to behave respectfully and civilly in their interactions with others. They are expected to follow Wikipedia policy and to perform their duties with care and judgement. Administrators who lose the trust or confidence of the community may have their access removed. Administrators are also expected to learn from experience and from justified criticism of their actions or conduct.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Administrators (authority to desysop)

Barring cases of emergency, the authority to impose sanctions (including desysopping) on administrators on the English Wikipedia rests solely with the Arbitration Committee. Temporary desysoppings can be requested using existing processes (see Level I and Level II procedures). Emergency use of global staff permissions on the English Wikipedia should be reported to and reviewed by both the WMF and the Arbitration Committee.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Official WMF actions

The labelling of staff accounts with "(WMF)" in the name is best practice and increases accountability and scrutiny of official Wikimedia Foundation (WMF) actions and actions taken in an individual's role with the WMF. The label in the name allows other editors looking at page histories and watchlists to identify official WMF accounts and actions. Despite this, there are WMF staff members that use accounts without this label to take official WMF actions. Those staff members need to take extra care to make clear at every stage that they are taking official WMF actions. It is not acceptable for those with unlabelled accounts to make edits elsewhere to retrospectively apply WMF status to an earlier action.

Comment by Arbitrators:

Kww, as this is a principle it addresses what the current situation is. Recommendations to change this (which we have no real power to enforce) would come as a remedy. Some form of Beeblebrox's motion (suggested at the request stage) will likely form part of the final decision. My view is that the WMF need to bite the bullet and clean up the inconsistent labelling of such accounts (which is mostly a historical artefact). One major inconvenience is when reading discussions months or years later, is not realising that some account without "WMF" in its name is actually a WMF staffer (or was at the time). One of the findings I have drafted identified several such inconsistencies. IIRC, there are 16 of the 43 WMF staff accounts with global staff permissions that do not have 'WMF' in the account name (there are also examples in the wider set of general WMF accounts, but going through a list of around 200 names is something I'd prefer to leave to others). What might also be useful for the WMF to consider is splitting the staff permissions into a bundle assigned to Engineering (i.e. developers) and a bundle assigned to LCA (Legal and Community Advocacy). But that is getting a bit beyond the scope of the case. Carcharoth (talk) 20:58, 2 August 2014 (UTC)

Comment by parties:

Comment by others:

This is pretty gutless. Why permit such accounts at all?—Kww(talk) 18:44, 2 August 2014 (UTC)

Proposals by User:Carcharoth (findings of fact)

Draft being finalised. Carcharoth (talk) 16:51, 2 August 2014 (UTC)

Template

1) {text of proposed finding of fact}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposals by User:Carcharoth (remedies)

• Draft being finalised. Carcharoth (talk) 16:51, 2 August 2014 (UTC)
• Note: All remedies that refer to a period of time, for example to a ban of X months or a revert parole of Y months, are to run concurrently unless otherwise stated.

Template

1) {text of proposed remedy}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Analysis of evidence

Place here items of evidence (with diffs) and detailed analysis

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

General discussion

Comment by Arbitrators:

Comment by parties:

Comment by others: