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

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

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.

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

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:

Arbitrators may ask questions of the parties in this section.

Proposed principles

Principle 1

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

Wnt, a couple of comments. One example of image presentation changes that I found when looking at some of the village pump archives was this discussion (from June 2014, regarding changes that affected the display of infobox images). That is not a complete extension roll-out, but was a change to the latest version of Mediawiki (I think). It is also a good example of a change that was mistaken and after objections was rolled back. The developers (both volunteer and paid) do a lot that hardly gets noticed (and which should be appreciated more). It is the stuff that goes wrong or that some dislike that gets a lot of attention. Anyway, that discussion is also a good example of one where there are two WMF developers pitching in. From the context you realise (though maybe not straight away) that they are both developers, but neither have 'WMF' in their account name. Tim Starling is a name that many will recognise, but not everyone will. Some will also recognise cscott, but again not everyone will. When someone like User:Tgr (WMF) joins the conversation (see below), seeing 'WMF' in the name does help some taking part in the discussion orientate themselves. What confuses me sometimes is when volunteer developers (a very fluid distinction, I'm told) pitch in. Sometimes it helps to take a step back and introduce yourself when posting in a discussion where it would help for people to know what your background is. But that would get pretty tiresome after a while. Is there an unstated assumption that if you want to know who someone is, you pop over to their user page and read that? Carcharoth (talk) 21:46, 2 August 2014 (UTC)[reply]

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

cscott: First, it is indeed my assumption that people will click through to my user page to find out my affiliation. I have been at various times a developer on Wikipedia projects on behalf of OLPC, a contractor for Wikimedia, and a full-time Wikimedia employee. My participation as a developer in the community has remained roughly the same in all roles; my employment doesn't confer any special code commit privileges that weren't available when I was a volunteer (and indeed I got commit bits before I was an employee). So (in my opinion, at least), framing the discussion in terms of "WMF developers" and making my WMF association foremost is a distortion of the process -- on the code side at least. It's just "developers". And changes in parser behavior (intended or not) are certainly not done exclusively by WMF.

Second, let me discuss "changes in parser behavior" from a developer perspective. It might not always be obvious to editors, but the existing PHP parser is a huge mess. There are tons of *unintended* weird behaviors and corner cases, and just as many *intended* features that have, over time, grown increasingly crusty. Changes to parser behavior which result in visible differences in pages occur all the time, in the process of maintaining the code, cleaning it up, or adding a new feature. (I can provide a dozen sample bugzilla issues if there is interest.) Usually we (the author or reviewer of the patch) take special care to ensure that the changes are not *obvious* -- that is, the syntax in question or change in appearance happens on a very small number of pages, and where possible we proactively fix up broken markup before the parser patch lands. It's not always easy to do these checks, they involve searches through the complete template-expanded content of all Wikimedia projects. In the cited case, that review failed to anticipate issues, and was reverted. Mistakes like these happen.

This RfC seems to be concerned more with UI. But, since I was mentioned, indulge me as I finish my discussion of wikitext and parsers. Wikitext is a very old syntax, and images in particular are a minefield of conflicting and not-always-useful options. Most editors want something like a consistent appearance of images in articles. This consistent appearance may very well change depending on how you view the page: a nice layout for a printed page or PDF will have different conventions than Wikipedia in a browser (and then again, on a retina display), and mobile browsers will probably be different still. So I expect that, in the near future, we will have another big-ish change to wikitext to introduce better semantic classes for images and avoid the low-level pixel tweaking which the current syntax is geared to. I haven't heard anyone propose any really good ideas for how this would work, yet, although the general idea is floating around. Hopefully there will be tools to support any new wikitext syntax, and to support editors migrating to the new page layouts or image format options or what have you. I expect this will be an ongoing discussion.

All that said, on the dev side we do try to delegate as much control of appearance to the individual wikis as possible. So I expect that (for instance) if we introduce new semantic labels for images that the code side will only provide the skeleton; the wikis themselves will chose the labels to use and the styling that goes with those labels, etc.

Whew. Sorry of the wall of text. Hopefully my perspective as a developer is helpful. C. Scott Ananian (talk) 19:19, 4 August 2014 (UTC)[reply]

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

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

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

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

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

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

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

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

• @Carcharoth: The edit ([4]) is clearly within the purview of someone at MediaWiki. Conceivably Wikipedia could have been run on open source software generated by an entirely separate organization and might have to adapt to upgrades that would come without warning. Even though it had the effect of temporarily altering how many images on Wikipedia were displayed, the complaints were based on the work involved in reverting the change, not the right to revert the change. So I regard this as completely consistent with my principle: the community did in fact have the power to make the final decision what the content looked like. What made the edit legitimate was that the developers weren't crossing over from general work on the software as a whole into making the final decisions of what the content has to look like on our Wiki. Nonetheless, though legitimate, it was clearly recognized to be a bad idea; even when they don't technically have to, developers try to make things easier for the people who use the software they make. Wnt (talk) 01:37, 3 August 2014 (UTC)[reply]

Principle 2

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:

The comment below by TheDJ shows how useful it is to have those with a technical background and knowledge commenting in such discussions. I made a comment above about volunteer developers, and I think TheDJ is a good example of that? (Please correct me if I'm wrong!) A good example of this is the comment made here. Carcharoth (talk) 22:27, 2 August 2014 (UTC)[reply]

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

Yes, I think the English Wikipedia should have different quality standards than other WMF projects when it comes to many of these features. This is because the balance of available resources is different. On a small Wiki with just a few hundred people editing, you want them to be able to put together galleries of images from Commons easily, yet clicking through to a Commons description page (in English) may not be seen as especially useful. People reading in that language may, on average, have different bandwidth limitations. I'm sure there are many other relevant differences. Wnt (talk) 03:53, 3 August 2014 (UTC)[reply]

That's what I wanted clarified. You want to increase the level of quality required for deployments of en.wp regardless of the levels of other sister sites. —TheDJ (talk • contribs) 20:00, 5 August 2014 (UTC)[reply]

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

Finding of fact 1

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:

This proposed finding of fact is a start, but fails to give enough context. Statements such as "most readers do not find the tool useful" go too far. There are better ways to put all this, which hopefully will be clearer when the draft findings are published (they have been drafted, just waiting for a final review). Carcharoth (talk) 22:32, 2 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed remedies

Remedy 1

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:

If another RfC was run and got massive input, maybe (but even then, probably not). From the results of the current RfC? No. That was not broad community consensus, the numbers were just far too low. The numbers given below by Andrew Gray with regards to the participation here compared to other RfCs show this clearly. The irony though is that the numbers at the RfC were still far higher than the numbers discussing Media Viewer on the English Wikipedia before it was launched. Unless I'm missing something, the amount of publicity leading up to the launch can only be described as 'low key' at best (beta testing really doesn't count here as people being 'aware' - it was publicity to the wider community that appeared to be failing to generate discussion here leading up to the launch). Carcharoth (talk) 22:41, 2 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Remedy 2

The Common.js file requires better protection than it currently receives. Despite present issues, the most important reason for this is to improve security against an attacker who hacks an admin's account and changes the file to reference a script with zero-day browser hacks. Although it is possible for MediaWiki to change its status to that of a configuration variable, this is undesirable because many wikis need to function without a sysadmin on call; MediaWiki must have added on-wiki control over this page for a reason. Therefore, it is instead requested that MediaWiki develop a new safeguard called "sandbox protection".

The way sandbox protection could work on an already-protected page is that a page is subjected to it as a configuration parameter, e.g. $wgSandboxProtected = "{ {page: 'Config.js', sandbox: 'Config/sandbox.js', delay = 1800} }" This particular string might even become the default when setting up a new wiki. When making an edit to Config.js via the wiki, the edit would only be accepted if (a) it was identical to some previous version of Config.js that had not been revision deleted, or (b) it was identical to the present version of Config/sandbox.js and that page had not been edited for more than 30 minutes [1800 seconds].

If MediaWiki would develop such a feature, the experienced editors who watch Config.js could watchlist Config/sandbox.js and evaluate proposed changes before they went live. Any editor with admin or template editor status could revert in the sandbox to hold up deployment on the live page if the situation were perceived as serious. Those with direct file access, of course, would have other means to change the file if need be, but should be expected to avoid inappropriate intervention. There could still be drama if some holdouts had to be persuaded by some means to stop reverting, but it would not be live drama.

Comment by Arbitrators:

Comment by parties:

Comment by others:

In 2001, there were no sysadmins on call. In 2014, there is always at least one: the WMF Operations team is staffed 24/7/365. (There is an advantage to having paid staff, and this is one of them. Many of us forget the frequent inexplicable downtimes, the need to roll back entire upgrades, and so on. Now every bit of code that goes into the system is reviewed and tested, there is so little downtime that many can't remember the last one they saw, the tools we use are in many cases considerably superior. There is a real benefit to having paid staff, which many here on this page are forgetting. They don't work for us. We don't work for them. We *all* work for the readers.)

Technically speaking, if MediaWiki is going to develop a new feature, it should be separation of the .js and .css pages from ordinary, unschooled admins, and making them solely the domain of developers (volunteer and staff, including non-admins who are currently excluded) who have demonstrated their ability to develop appropriate code, and to actively participate in code review and testing. This would probably require the creation of a new "developer" permission. Nonetheless, I think the proposal here is well outside the remit of the Arbitration Committee. Just as importantly, I am absolutely certain that we'd be exactly the same place we are in now if the same change had been reverted by WMF staff for the same reason had it been in a "pre-live" sandbox rather than on a live page. I'll let people who have a better understanding of the technical aspects of your proposal comment, but this would essentially break the history of whose edits have changed the common.js, and I believe from a technical point of view that is inherently problematic. Risker (talk) 17:17, 3 August 2014 (UTC)[reply]

@Risker: I wasn't picturing breaking the history. What I describe would essentially be a sort of edit filter, not much different than the spam blacklist, only instead of rejecting links that are on the spam blacklist it would reject any page revision that is not "whitelisted" by being present verbatim on the Config.js/sandbox page. (But it would also check how long that had been the most recent version)

I did admit the same core conflict would occur if my suggestion were implemented. However, I think it is less disruptive to have an argument at a sandbox page than to actually change the site javascript then revert it. And as I said, my deepest concern here isn't even about this sort of good faith change, but bad faith change. If somebody manages to infect thousands of Wikipedia readers with a virus by changing this file it's going to be a huge black eye for the project.

As for leaving it to sysadmins who are professional, I understand the argument. However, we need to remain aware that Wikipedia is a) continually shrinking, and b) subject to the whim of a near-monopoly search provider. Half our hits come straight from Google, and who knows how many of the others are reached indirectly but pretty quickly from a first hit there? If they decide at some point to go with some other option and greatly decrease Wikipedia's ranking, we're not going to get even five minutes' warning. We'll have a huge budget that we can't sustain, and even the volunteer developers who are career-building will jump ship to whatever new option the company picks. So we have to be ready to crash-land this site at any time, making do with a severe surprise reduction in resources. That means we shouldn't give up the flexibility that is built in with the current Wiki interface for this page. Wnt (talk) 22:51, 3 August 2014 (UTC)[reply]

Wnt, I envision the "developer" permission to require ability to code, and to have submitted code somewhere or other in the MediaWiki world that has been found to be acceptable, properly reviewed and tested, secure, and deployed successfully - even if that means a tool on Labs or a bot or some other similar example. None of that requires adminship, let alone WMF employment; and indeed hundreds of volunteer developers work in these areas. It would also eliminate the requirement that volunteers who really want to code would have to do things they don't like all that much in order to gain adminship so they could code. Much of our common.css is developed by highly skilled volunteer developers. Risker (talk) 22:59, 3 August 2014 (UTC)[reply]

Risker - we already have WP:Template editor, which is something like this, but they don't have higher rights than admins. I'm not sure how admins administer if they don't have the right even to revert a non-admin's change, or how many people you want to have sysadmin-level access to the servers. So I don't really understand how your idea would work. Wnt (talk) 23:17, 3 August 2014 (UTC)[reply]

So that when Flow comes along we have no line of defense? That would seem problematic.—Kww(talk) 17:33, 3 August 2014 (UTC)[reply]

Oh Kww. Your hack, which was at least posted in various places, and MZM's hack here, are not solutions. They affect only users who have JavaScript enabled (there are a lot of people who turn it off for security and performance reasons), they create major load problems for many users, and they're usually written in a way that does not permit users any options but bad common.js. (And yes, I include your hack here - loading times were obviously affected, although you might not have noticed if you were on your usual Western World High Speed internet connection.) It's supremely arrogant to think that this is the "right" solution for any problem. And I say that as someone who believes Flow is the sign of a bunch of developers who do not understand how Wikipedia actually works, only how they fantasize that it should work. Risker (talk) 19:28, 3 August 2014 (UTC)[reply]

The right solution would be for WMF to not install tools as default until there's a consensus to do so, and probably not even to begin work on them until there's a consensus to do so. Imagine how much better Wikipedia could be if the resources wasted on VE, MV, and Flow had been devoted to useful software. However, in the absence of the right solution, I'm not willing to throw away the only solution we have.—Kww(talk) 19:32, 3 August 2014 (UTC)[reply]

With the big fat disclaimer that talking about an RfC (or vote-and-discussion of some kind) before we've agreed to do that is premature ... Kww, is there any result from an RfC that would be satisfy you that we don't need the .js hack? - Dank (push to talk) 19:50, 3 August 2014 (UTC)[reply]

I don't think we need this particular .js hack at all, because I don't think there was a consensus that this particular issue was important enough to force a confrontation with the WMF. I'm just not willing to do anything that prevents us from having .js hacks at our disposal.—Kww(talk) 20:04, 3 August 2014 (UTC)[reply]

Risker: You mention users who have JavaScript disabled. Can you please explain how MediaViewer functions at all with JavaScript disabled?

You also mention "major load problems for many users." Can you please provide citations for this claim? I'm very curious what load problems would arise from disabling a supplementary feature.

While I'm trying to assume good faith, it's very difficult to look at your comments here and not feel as though you're simply trying to spread fear, uncertainty, and doubt. --MZMcBride (talk) 14:55, 7 August 2014 (UTC)[reply]

MZMcBride, modifying the common JavaScript to disable a site-wide feature is poor practice, because not all site features are entirely javascript-based; in this case, you don't actually know how it would have affected people with JS disabled, because you did not test for it, based on your own comments.[5] More importantly, what your script did was to disable Media Viewer after it had already loaded; it did not prevent it from loading in the first place. Thus, there would be the normal load time for the page, plus the additional load time to reload without Media Viewer. It is impossible for someone making use of very high speed internet connections on very good, fast computers to accurately assess the impact of modifications that have any effect on load time; it's what I call the "Western World" effect, and you're certainly not the only developer who has forgotten or not properly understood how even a brief snippet of code can cause significant load problems for people who can’t afford top of the line computers or high speed internet, many of whom come from the same geographic locations that are already slower simply because of their distance from the servers. This isn’t FUD, it’s reality. You wrote code that didn’t actually do what you seem to have thought it would do (i.e., prevent MV from loading in the first place), didn’t test it sufficiently to understand its impact, didn’t discuss it with others who had sufficient understanding of code to potentially debug it, and then posted the line of code on the talk page with insufficient explanation for a non-coding admin to understand the technical implications of adding the code.[6] In fairness, maybe you didn’t know them – but that’s exactly why there’s been such a strong move to ensuring that code doesn’t get into the system unless it’s properly tested, properly reviewed, and its actions are well-understood. Sometimes problem code still slips through, but failing to take those steps was not very responsible on your part. Risker (talk) 16:06, 7 August 2014 (UTC)[reply]

(un-indent) "you don't actually know how it would have affected people with JS disabled" ← You're pretty clearly displaying your ignorance here. You have no idea how MediaViewer is implemented, do you? (Hint: if you disable JavaScript in your Web browser, MediaViewer does not work at all.)

"plus the additional load time to reload without Media Viewer" ← Statements such as this make it explicit that you really have no idea what you're talking about. At all. Please stop. --MZMcBride (talk) 18:18, 7 August 2014 (UTC)[reply]

• MZM, I got both of these pieces of information from people who do know how it works, have had to fix problems caused by inept admin edits to common.js on other projects, and had to clean up after bad code like this many times before. I'm going to take their word over yours every day of the week and twice on Sunday. I did take the time and make the effort to learn instead of making assumptions, but you're making assumptions that you can't back up. You aren't offering an alternative explanation, you're just defending your poorly tested, unreviewed code. You either don't care about the quality of your work or you don't understand its potential impact. But since there's no sanction that Arbcom can place on you short of banning you from the project that will have any effect (you didn't insert the code yourself, you just dangled it in front of admins who understood it so poorly they didn't realise what it would do), it's all a moot point. I just hope that enough other admins understand that using your code is no longer a sensible thing to do. (Honestly, do you think that would ever have made it through bugzilla as a solution that that RFC?) Risker (talk) 22:52, 7 August 2014 (UTC)[reply]
  • So when pressed, you mumble something about "I heard it somewhere" and continue making personal attacks on both me and the code I write ("code" in this case being a single line of JavaScript scribbled out on a talk page one day)? This, of course, after your failed attempt to list me as a party to this case. Literally anyone with even a passing understanding of JavaScript would read your comments and immediately recognize that you have no idea what you're talking about. And I most certainly don't proclaim to be any kind of JavaScript expert, to be sure. The hack that I proposed never would have gone through code review as it was a hack and everybody knew that. But you're trying to deflect attention away from the fact that you're making very bold, technical statements on this talk page that have no basis in reality. (You're also making pretty bold statements about the state of Internet and computers in the Western world, but we'll leave that stupidity for a different day.)

    Look at the page source of any page on any Wikimedia wiki where MediaViewer is enabled. Read and understand the code (the HTML, JavaScript, and even the CSS that make up the page). Once you've done that, it might make sense to have a technical discussion. At this point, however, it probably makes the most sense for me to just walk away. Your comments will, in context, hopefully be discarded as the misinformed and under-educated rubbish that they are. --MZMcBride (talk) 00:42, 8 August 2014 (UTC)[reply]

I will say this, if Wikipedia were started in 2014 and not in 2001, then this option likely would never exist at all and even less likely would be the .js pages for users. They have taken up a huge amount of time in developer resources, because they introduce all sorts of unbounded complexity and are often badly maintained (en.wp, de.wp and commons are the exceptions). But considering how much stuff depends on this nowadays, I doubt it will be removed any time soon. Also, we have a set of 'global interface' editors who have rights to these files on all wiki's, which is to some degree issued on a skills basis. At most I can imagine that at some point, that right might 'supersede' the local sysop right, but I think it is highly unlikely. Also, it sounds too much Flagged Revisions-like, so it is doomed to fail ;) —TheDJ (talk • contribs) 19:52, 5 August 2014 (UTC)[reply]

Proposed principles

Principle 1

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

Comment by Arbitrators:

Something similar to this (but better phrased) has been proposed below. Carrite, the old way of viewing images is still available. It took me a while to find that out and adapt to using it. What failed here was 'selling' the extension to a community that at times is notorious for its resistance to change. There are plenty of things that could have been done better here. On the other comments below, the dynamics of interactions between all these communities (WMF staffers, volunteer developers, editors, and so on - some being more than one example at the same time) is fascinating. Even keeping up with a small part of what goes on across the Wikimedia movement can seem like a full-time occupation. Carcharoth (talk) 22:55, 2 August 2014 (UTC)[reply]

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

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

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

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

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

Principle 2

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:

I think the point being made here is that some volunteers see a bigger picture, while others are very focused on the specific task in front of them (which may just be editing a single page). It is a valid point, but not one that I think will help in this specific case. Thanks for taking the time to do the Venn diagram, Ariconte. You may need to work on the terminology ('User' has a specific meaning on Wikipedia). The various flavours of roles probably can't be boiled down to just the three classes you mention, either. There may be people out there who have studied this before, so possibly worth asking around. Carcharoth (talk) 23:09, 2 August 2014 (UTC)[reply]

I recognize this is much more complex than my example. I am just trying to get people to focus on the motivations - and to define the roles so they can be discussed. Almost out of volunteer hours on this :-) Regards, Ariconte (talk) 00:25, 3 August 2014 (UTC)[reply]

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

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

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

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

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

Principle 3

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:

Principle 4

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:

This is a valid comment (the increase in size of the WMF has driven a large number of recent changes over the last few years), but we aren't going to vote on a principle referring to hippie flowers. What is that anyway? Flower power? Carcharoth (talk) 23:13, 2 August 2014 (UTC)[reply]

I apologize for the hippie comment - it detracts from my main message. Regards, Ariconte (talk) 00:03, 3 August 2014 (UTC)[reply]

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

Principle 5

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

Comment by Arbitrators:

I disagree with this. Erik/Eloquence acknowledging his mistake doesn't undo the effects it had (these effects arose because of the position he holds), so some response is needed there. For Peteforsyth, acknowledging the haste and mistake in taking an action without fully understanding its effects is not the whole story. Both Erik and Pete (for different reasons) hold strong views on the issue that was being debated. Whether that influenced their subsequent actions needs further examination. Carcharoth (talk) 23:22, 2 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Well, I suppose it depends on whether or not you think those "effects" are bad. I for one think it is very good that administrators who don't understand code will now feel much more thoughtful about messing around with common.js (and probably common.css), and realise that this is something that could cost them not just access to those specific pages, but to all administrator permissions. It's good that the community can count on the WMF when local administrators (afraid of stepping on political pressure points) are unwilling to act in order to preserve the project. We all know how the jackboots would have sunk in to any enwiki administrator who dared to revert that edit, which wasn't made in order to improve the project but to prove a political point. That much is obvious from many of the other proposals made on this page. Risker (talk) 22:27, 3 August 2014 (UTC)[reply]

I don't understand why that clarification was needed thought. There are like five 'BE THE F*#K CAREFUL'-banners on both the page, the edit form and it's talk pages. If that is how effective those banners are for sysops, then why are we even bothering with edit banners for normal editors ? Also memory of the community tends to be short when you take a bit longer view in mind, so even if it was effective for the coming few months, it will quickly wane again. —TheDJ (talk • contribs) 20:06, 5 August 2014 (UTC)[reply]

Principle 6

6) Volunteers should be integrated into the foundations work.

Comment by Arbitrators:

Hmm. This is too Borg-like. I think I get what you are trying to say, but it needs to be expressed a bit better. Are you trying to say that communications could be improved and more could be done to match volunteers to work that needs to be done? Carcharoth (talk) 23:28, 2 August 2014 (UTC)[reply]

Well yes. If we had a chart that showed staff person X with say 3 staff software developers reporting to him/her and 2 volunteers working with them ---- then I would understand/feel/know 'we' were all working together. If you look over here you would think all software development is done by staff. Regards, 00:38, 3 August 2014 (UTC)

In one sense this is happening already, in that a large percentage of the WMF's hires into staff roles come from the volunteer community. In another sense the proposal is right that this is what needs to happen, per my comments elsewhere on this page. Carcharoth is correct that the wording needs to be changed, but that is something we can handle. Newyorkbrad (talk) 00:29, 4 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Principle 7

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

Comment by Arbitrators:

I think I get what you are saying here as well, but again it probably needs expanding to make the meaning clear. Are you saying that editors telling developers what they should do doesn't go down well, and vice-versa? I don't think trying to define boundaries will help there. You will always get people telling others what they think they should do - that is human nature. The other side of the coin is people learning to do new things, expanding outside their current roles, by asking others how to do things, and maybe developing into and fulfilling a different role. Carcharoth (talk) 23:33, 2 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Absolutely not. It is important that volunteers who wish to do so feel free to move between roles as much as they like. Certainly mutual respect between paid staff and volunteers is a good thing, perhaps that is what you mean? All the best: Rich Farmbrough, 03:56, 4 August 2014 (UTC).

Proposed findings of fact

Finding of fact 1

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

Comment by Arbitrators:

This is true for some aspects of the case, but not for others. For a finding along these lines to make sense, you would need to be more specific. The other point some people are missing is that individuals, organisations and committees still comment or issue opinions even in areas where they don't have jurisdiction. It may not be useful, but in some cases it is useful. I'm hopeful that in this case, some of the conclusions reached will be useful even where we don't have jurisdiction. Carcharoth (talk) 23:38, 2 August 2014 (UTC)[reply]

I agree with Carcharoth's comments on this point. Newyorkbrad (talk) 00:30, 4 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

This cannot be established without seeing the final findings. Certainly if the Arbitration Committee attempted something that was ultra vires they would be informed pretty quickly (they have been in the past), and would probably take notice (they haven't in the past). However in this case I suspect they will be a little careful. All the best: Rich Farmbrough, 03:59, 4 August 2014 (UTC).

Proposed remedies

Remedy 1

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.

Comment by Arbitrators:

Having said above that some opinions and suggestions may result from this case, it won't be anything like this sort of proposal which is (ironically) stepping on lots of toes. Although you said in evidence that there used to be a 'Manager of Volunteers', I don't believe this role ever went away. It is still being performed to a lesser or greater extent by a number of individuals, though not with that exact job title. Carcharoth (talk) 23:51, 2 August 2014 (UTC)[reply]

I hope you are correct. I think leadership and supervision of volunteers should be explicitly in the job description of foundation staff who have volunteers working in their teams. I think HR is the department to train staff to do this ... the references I have given and the ones here will help. Regards, Ariconte (talk) 00:19, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

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

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

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

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

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

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

Comment by others:

Remedy 2

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:

Again, I can see the argument you are making here, but this is too vague. Carcharoth (talk) 23:51, 2 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed principles

Principle 1

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

Comment by Arbitrators:

I'll copy here what I said above: "individuals, organisations and committees still comment or issue opinions even in areas where they don't have jurisdiction. It may not be useful, but in some cases it is useful. I'm hopeful that in this case, some of the conclusions reached will be useful even where we don't have jurisdiction". Carcharoth (talk) 00:04, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Principle 2

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:

Something similar to this has been proposed below in the draft principles I published as one of the drafting arbitrators for public comment. I'm not entirely happy with the principle as it stands. The thing that struck me most about this was the reference to 'the self-governing community of English Wikipedia' - is that really true? It is wording like that which makes me wonder if WP:CONEXCEPT is outdated and/or needs changing by the community to phrase things better. It is a bit strange to be 'self-governing' but to not have control over some things. Like, er, Scotland is self-governing, but its laws are made at Westminster (that may not have been the best example, but it was the best one I could come up with). Maybe someone can come up with a better analogy. Carcharoth (talk) 00:12, 3 August 2014 (UTC)[reply]

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

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

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

One of the issues in the penumbra is that the "very narrow legal case" is actually not so narrow and we have a poor process between the community and the foundation to deal with DMCA cases. Similarly we have a bad solution for subpeoena's for personal information. We also have no openness by the foundation of the service of legal documents that might affect the projects. All the best: Rich Farmbrough, 04:05, 4 August 2014 (UTC).

I've been asked to comment here, as I made an observation regarding [[WP:CONEXCEPT] in a recent RfA. The wording in WP:CONEXCEPT came about from this discussion: Wikipedia_talk:Consensus/Archive_14#Developers. The discussion didn't attract much attention (four people commented - none of them WMF staff or en.wp admins), but the wording apparently hasn't been challenged or questioned so is assumed to have been accepted. Given the flow of the discussion, the intention appears to have been to indicate that one Wikipedia community does not hold influence over another, so consensus on en.wp does not mean consensus on commons or mediawiki, so the community on en.wp cannot induce the mediawiki developers to do something that they don't wish to. However, I don't think from the discussion that it was ever intended to suggest that the mediawiki developers can ignore consensus on any project and enforce their will or preference against wide and legitimate disagreement. I think the point being made in the discussion was that no project can force another project to do something, unless it is an office action. Any notion that WP:CONEXCEPT allows developers to make radical changes to the user experience of en.wp against the consent of the en.wp community would be an erroneous reading of WP:CONEXCEPT, and certainly of its intention. That the developers may have such powers under some other agreement is open to debate. I understand that some developers feel they have these powers. However, such powers are not granted to them by the opaque paragraph introduced into WP:Consensus without sufficient consensus considering the implications of such a statement. SilkTork ^{✔Tea time} 17:22, 6 August 2014 (UTC)[reply]

If ST's observations are accurate, they point to a need for better linkage in the consensus building process in relation to decisions related to features of this level. I would think it obvious, as NYB has pointed out, that the objective is to foster collaboration, not incite competition between "the community" and WMF; to that end, maybe some rewording of various passages is in order, but it seems that the big picture is being somewhat obscured in focusing on the "self-governed" nature of the community. For all intents and purposes, the end use of Wikipedia is part of the community, and the editing community doesn't always seem to be able to keep the end users' interests in focus.--Ubikwit ^連絡 _{見学/迷惑} 17:41, 6 August 2014 (UTC)[reply]

Problems with Silk Tork's analysis include: 1) the use, only by him, of the term "radical changes", which is solely up to interpretation; 2) those discussing that wording to CONEXCEPT, actually noted it was a "fact of life" that developers affected changing appearance on en-wiki (and remember most policy is descriptive not prescriptive); and this is consistent with WP:VPR direction that software proposals go to bugzilla; 3) no one mentioned "office action" at all in that discussion, so it was not about office action; 4) 'office action' is treated specifically in section 2 of CONEXCEPT, not in section 4, where the change was made (and where the recognition of software changes was made to be separate from office action). 5) Section 1 of CONEXCEPT has another separate exception for decisions/acts of any designee of the WMF, itself, so that's not about office action, either (which again is covered only in section 2). So, in practicality, all the new language did was recognize the fact that volunteer developers, often working with staff, change en-wiki without and contrary to local consensus ("not subject to") -- Alanscottwalker (talk) 18:11, 6 August 2014 (UTC)[reply]

With respect to appearance/interface software, and to bring in a global perspective, if you go to any of the 100s of Wikimedia sites, they basically all look the same, edit the same, and act the same. This makes it an issue of brand management, trade dress, and transfer-ability of skills across projects. These can only be done by the WMF. Alanscottwalker (talk) 19:14, 6 August 2014 (UTC)[reply]

Proposed finding of fact

Finding of fact 1

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:

This I disagree with. I asked for evidence along these lines, and from what I can tell there was very little outreach to specifically generate discussion on the English Wikipedia among the active editorial community here. The release plan at the Media Viewer mediawiki.org page gave links to around 10 announcements made on the English Wikipedia. I'm discounting mentions on other Wikimedia sites because there is no guarantee that those sites would reach a broad cross-section of the English Wikipedia community. Of the ten mentions on the English Wikipedia, five of those were on a single day (2 May 2014), some at out-of-the-way locations that were to do with images but still not highly-trafficked locations. That is ten announcements on across nine months. The English Wikipedia is a very difficult environment to do publicity work in. It is a high-noise environment where many people are engrossed in what they are doing and ignore what is going on around them unless you shove it in their faces (by launching a new software feature, for example). If you look at the page that was created on the English Wikipedia specifically to discuss the new feature, the stats are damning. Only seven people edited the talk page in the month prior to the launch of the feature, and three of those were WMF staff. Where was the discussion about Media Viewer prior to its launch taking place? Was it taking place at mediawiki.org? If so, that is better than no discussion, but is it a substitute for discussion here? If the WMF were looking for a centralised discussion from people across the Wikimedia projects, held at mediawiki.org, that should have been made much clearer from the start, and much more work done to bring in people from the largest WMF wiki. Without that preparatory work, the results of the launch were predictable. Carcharoth (talk) 00:30, 3 August 2014 (UTC)[reply]

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

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

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

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

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

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

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

Yeah, it is my firm belief that this is a pipe dream. Editors are not here to build and consult on software features every single week (and your attention would probably be drawn at least once a week), they want to write an encyclopedia. Those who do want to be involved, probably already are involving themselves and follow the appropriate news source like tech news, signpost and blog. —TheDJ (talk • contribs) 20:16, 5 August 2014 (UTC)[reply]

Finding of fact 2

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:

There is a detailed finding about the central events here in the draft decision. I think we've just quoted what Pete said in his initial response at the arbitration request, but if Pete feels that another phrasing bests reflects what he knew at the time, that can be considered. Carcharoth (talk) 00:45, 3 August 2014 (UTC)[reply]

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

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

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

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

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

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

"administrator Eloquence acting in his role as Deputy Directory of the Wikimedia Foundation" is incorrect. User:Eloquence states explicitly, and has done for months, that Unless otherwise stated, any edit to Wikimedia projects by myself is an act of a regular member of the community and administrator, not a legal or official action. His edit [8] of 20:06, 10 July did not state that it was an official or legal action and therefore, by his own declaration, was made in his personal capacity as a member of the community. On the other hand, his edit [9] of 20:07, 10 July threatening to desysop Peter Forsyth, did state, following the threat, This is a WMF action. -- not was, but is. We conclude that the change to the site javascript was a personal action but the threat to desysop was a WMF action. Sorry to repeat myself but the issue appears more than once Deltahedron (talk) 20:31, 15 August 2014 (UTC)[reply]

Proposed remedies

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

Could you please use headers when proposing them? I've been adding headers to many of the current proposals on this workshop as it makes it easier to edit and comment on them individually. Thanks. Carcharoth (talk) 00:02, 3 August 2014 (UTC)[reply]

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:

Are you suggesting here that further discussion might have reached that conclusion? I agree that sometimes an initial RfC doesn't end discussion and that in cases like the one here, further discussion is obviously the next step (well, obvious to all except those who want to rush ahead, possibly influenced by their own strong opinions on the matter). I don't, however, like the reference to 'battle' here. While there appears to have been room for improvement on many aspects of this, a confrontational attitude isn't going to help. Carcharoth (talk) 01:04, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Carcharoth, actually, I believe the opposite: if a specific RFC had been held asking "Is WMF's refusal to cooperate with the RFC about MV worth a confrontation?", the answer would most likely have been "No, we need to choose our battles, and this isn't one of them." That's the reason that I believe that overriding the WMF needs to have a specific consensus on the specific issue of it being an override before someone does it. If there had been such an RFC and it had generated the (unlikely) result that most of us thought this was a battle worth fighting, someone would have provided a better patch than Pete did and the WMF wouldn't have been so prone to thumb their nose at him.—Kww(talk) 22:19, 3 August 2014 (UTC)[reply]

This is probably true, but begs the vexed questions, "Can the community override the WMF? Can the WMF override the community?"

All the best: Rich Farmbrough, 12:46, 20 August 2014 (UTC).

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

I'm more persuaded by the points put forward by TheDJ and others. You do have to defer to those who understand how the technical matters work. So while this point is true, it needs expanding. There is a draft principle below on something similar to this. Whether this page is wholly within the remit of the community is a moot point, really, if most of them don't understand how to edit it. Reading through the talk page archives helps to get a more rounded view on this. Carcharoth (talk) 01:09, 3 August 2014 (UTC)[reply]

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

True, TheDJ, but forcing unrequested and rejected tools to become user defaults doesn't come under any of those exceptions.—Kww(talk) 23:08, 2 August 2014 (UTC)[reply]

What rejected tools are you talking about? The one that 14,000 editors enabled before it was default and 64 said in an RFC should be disabled? That's the problem with this theory of consensus: RFCs aren't the only place for them to develop. Risker (talk) 09:40, 3 August 2014 (UTC)[reply]

As I've said in other places, I think that VE, Phillipe's overreach on Conventional PCI, and this are all aspects of one continuous problem. Please stop waving that 14,000 figure about: it includes the "enable all beta features" checkbox, so there are accounts in there that have never edited while MV was enabled or have never clicked an image during the interval to note that they are enabled. What I would like people to start thinking and talking about is precisely why my override of VE received such a positive reception while Pete's override of MV did not. They are different cases and probing the differences is the way to learn.—Kww(talk) 15:00, 3 August 2014 (UTC)[reply]

"Security trumps consensus" - say rather Those Who Sacrifice Liberty For Security Deserve Neither All the best: Rich Farmbrough, 12:55, 20 August 2014 (UTC).

These pages have never been the exclusive remit of the community; in particular, they've been almost completely the remit of those with the skill and sensibility to properly edit them, whether community member or WMF staff. These are developer pages, rather than editor or administrator pages, and were originally included in the admin toolkit back in the day when many admins were developers and those who weren't knew better than to mess around with them. Risker (talk) 09:40, 3 August 2014 (UTC)[reply]

It's a mistake to consider that simply because the majority of editors and administrators don't have the knowledge to make sophisticated changes to something, that lies without community remit. Community powers are often delegated, either explicitly or implicitly to groups of editors.

While there has been a long term trend towards more control and more rules, this does not change the fundamentals of community ownership of the project.

All the best: Rich Farmbrough, 12:55, 20 August 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:

True, but in this case there was sufficient doubt about the degree of participation in the RfC. If a further discussion had taken place, it is also quite possible that more people would have become aware of the discussion and raised valid objections. Carcharoth (talk) 01:13, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

It is important that WMF is not given "first mover advantage". BRD should apply here as everywhere else. All the best: Rich Farmbrough, 12:56, 20 August 2014 (UTC).

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

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

I agree with what Carrite says here. However, rather than strip community tools from administrators on the WMF payroll (confrontational), or even have people voluntarily (for their period of employment) gave up such tools as a condition of WMF employment (contractual obligations), a better option would be to require that people submitted a new RfA upon becoming employed by the WMF. That way the community can chose whether they are comfortable with the dual role. Neither approach is really something ArbCom can influence. The contractual approach is entirely at the discretion of the WMF. The new RfA approach is one that the community would have to propose and form consensus on (though individuals could do this voluntarily). Carcharoth (talk) 01:27, 3 August 2014 (UTC)[reply]

@Risker, the re-RFA suggestion was only that, a suggestion. It is vanishingly unlikely that anything like that would be proposed, or even be possible (I even pointed out that only the community could adopt this approach, not ArbCom, something you missed entirely in your response). The other point you make is valid - some people are only short-term contractors. But those with a long-term career at the WMF and high up the hierarchy are different, there is no getting away from that. Read again what Carrite said: "a $50 million a year company heading for 240 paid employees, with its specific own set of internal interests — executives with careers". There is a serious argument that those at high up levels (directors within the WMF and those at Board and Trustee level) should consider as a matter of ethics and principle giving up local permissions during that period to avoid even the appearance of COI. Certainly they should be separated between two accounts, not bundled together with global rights as many are now. It is a matter of drawing ethical lines as the WMF expands. Though you are right that this is veering out of the case scope. Carcharoth (talk) 12:44, 3 August 2014 (UTC)[reply]

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

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

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

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

• I am gobsmacked by Carcharoth's suggestion that people be forced into reconfirmation RFAs because they've accepted employment by the WMF. If that isn't an enormous slap in the face I don't know what is. Many, many people accept short-term and/or part-time contracts with the WMF: it's how the revision-deletion/suppression interface was built, it's probably how the checkuser interface is going to be rebuilt, it's how the vast majority of MediaWiki improvements have been made over the last 14 years. This is the equivalent of kicking someone out of the community because they've had the temerity to get a job - one that they likely got because of their work within the community. Forcing people to re-RFA *because* they are accepting WMF employment is far outside of the scope of Arbcom: you do not set the criteria for adminship, the community does. You only deal with admins who have failed to adhere to those standard. There are almost no successful re-RFAs, as you are fully aware, and they are almost invariably highly controversial and highly stressful. I get that Arbcom is really unhappy with the WMF right now, and I can make a pretty informed guess at some of the reasons. None of them have to do with the average developer or WMF staffer who works both as a volunteer and WMF staffer or contractor, and it is shocking that the committee would extract its vengeance on the people who have in many cases invested years into this community as volunteers as well as staff. Risker (talk) 12:15, 3 August 2014 (UTC)[reply]
  • I agree wholeheartedly with Risker, both on the redundancy of desysopping people who take a WMF job, and the stress that even contemplating a re-sysop occasions. However I am sure that she will think some people deserve that stress. All the best: Rich Farmbrough, 03:36, 4 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)[reply]

Yeah, this isn't really the best approach. Carcharoth (talk) 01:30, 3 August 2014 (UTC)[reply]

I also disagree. Newyorkbrad (talk) 00:24, 4 August 2014 (UTC)[reply]

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

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

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

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

This should be amended to "All administrative accounts owned by WMF members that are not designated as WMF accounts are should have any WMF assigned rights removed. They may not act in an official capacity. Rights gained in the normal community process remain subject to normal community process." All the best: Rich Farmbrough, 03:20, 4 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:

Kww, this case has nothing to do with WP:OFFICE. It is clear from what you have written above and below that you are trying to get part of the case to be about what happened with you and Philippe earlier this year over PC2 protection on an article. That is not what this case is about. It is about WP:CONEXCEPT and over-reach regarding desysopping. The latter is what the two have in common, but your proposal here does not address that. Carcharoth (talk) 01:36, 3 August 2014 (UTC)[reply]

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

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

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: [10]. Alanscottwalker (talk) 14:27, 1 August 2014 (UTC)[reply]

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

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

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

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

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

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

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

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

Carcharoth, Erik spontaneously made up the term WMF action. There is no policy regarding "WMF actions" aside from WP:OFFICE. Yes, I do see the Visual Editor debacle, Phillipe's overreach, and this case to all be one continuous problem, not a series of discrete events. As for what my proposal addresses, it's simple: Eloquence, not being an official WMF account and having an irreconcilable COI in relation to his administrator rights, has no right whatsoever to edit common.js in any fashion. If there's a legal issue, he can get someone with an official WMF account to do it. For anything else, he needs to seek sufficient community consensus that an administrator that is beholden only to the community will do it for him.—Kww(talk) 02:45, 3 August 2014 (UTC)[reply]

Kww is substantially correct. An action is either WP:OFFICE or it is not. Apparently grey areas such as "With my WMF hat on I would just like to say that looks like a bad idea." are not grey. They are advisory, and not mandatory. Similarly an action like an emergency de-sysop, or deletion of an account or any other deliberate change which either de-facto or de-jure cannot be reversed by the community, is in effect a WP:OFFICE action, until and unless a different structure is put in place. The fact that it is sometimes possible to negotiate a change of stance does not alter this one whit. All the best: Rich Farmbrough, 03:43, 4 August 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:

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:

This is an important point. I will try and make sure something like this gets added to the proposed decision. Please ping me if I forget. Carcharoth (talk) 02:03, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

I have some sympathy with this view. On the other hand I would not like to see "soft soap" because, however well-meaning and lovely our developers (both paid and volunteer) are, there are many issues (see WP:VPT) and some of them have been quite outrageous. Some of this can be addressed by reformulating the interface between the community (or maybe I should say communities) and the foundation, in the same breath enabling both volunteers and paid staff to be far more effective (which we all like). There is no doubt that considerable effort goes into the projects (again paid and unpaid) which is totally wasted. Without addressing this we continue to make poor use of our biggest donation (volunteer time) as well as the substantial cash donations made to the foundation. All the best: Rich Farmbrough, 03:29, 4 August 2014 (UTC).

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:

This is true, but may over-estimate the role played by RfCs. Many decisions get taken simply by discussions without the structure of an RfC. Sometimes a badly done RfC can impede further progress, while an RfC that is well planned with sound arguments put forward can help form genuine consensus. I'm not sure how what you say can best be put in a principle, but maybe it can be summed up as "consensus can be slow to form", or "a long-lasting consensus takes time to form"? Carcharoth (talk) 02:10, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Carcharoth, I've got an analogy here that I don't think I've seen anyone else bring up: motors. When a motor actually does something interesting, we don't call it a motor any more ... we call it a car, a refrigerator, etc. RfAs are a form of RfC ... one that we've got enough history with that we've taken the risk of allowing the decision to be made (almost always) by consensus. the voters. (I'm not arguing that RfA is issue-free, only that we take the voters seriously, and have been happy enough with the consequences to keep on doing it.) There are many other specialized forums where the process seems to work well enough that we generally go with consensus ... and because they're specialized, we don't call them "RfCs" any more. I completely agree that it's dangerous to make some kind of blanket statement that Wikipedians are invited to rule via RfC ... things go sideways repeatedly. OTOH, processes where we allow general discussion and voting can ... in some cases ... evolve into forums that are actually useful, that actually get the job done, if they're handled with care. Then we stop calling them RfCs and start calling them something else. The main point is: there are few alternatives. Wikipedians generally just aren't that interested in participating outside of processes where they anticipate that they're going to have a real say in what happens, and when they do, the results aren't reliably representative of future votes. - Dank (push to talk) 02:26, 3 August 2014 (UTC)[reply]

THis might be better worded in terms of consensus, with specific mention of RFCs at the end. All the best: Rich Farmbrough, 03:44, 4 August 2014 (UTC).

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:

This is an excellent observation. It rings very true, but whether it is possible to show that it is supported by evidence is another matter. Some of the drafted findings may point towards this, but demonstrating it conclusively would be very difficult. It would need a lot of examination of past instances of similar roll outs. As such, it may be outside the scope of this case, but certainly those interested in drawing up a 'history' of such things (for want of a better word) should do so. Having a clearer record of what happened is always helpful. As for whether it is cultural or communication, can it not be both? A cultural lack of awareness of the communication and publicity channels usually used to ensure participation in major English Wikipedia decisions? (Or maybe such channels have withered over the years?) Carcharoth (talk) 02:20, 3 August 2014 (UTC)[reply]

As per my comments on some of Carcharoth's proposals, the useful outcome for this case would be develop a mechanism/process/protocol to avoid this situation going forward. Newyorkbrad (talk) 00:25, 4 August 2014 (UTC)[reply]

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

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

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

DJ, I'm a geek too, so I feel your pain. I've done less than I could have to help, and I apologize for that. - Dank (push to talk) 02:36, 3 August 2014 (UTC)[reply]

Carcharoth, thanks for that reply, that's put me in a good mood. I hope something comes of it. - Dank (push to talk) 22:13, 3 August 2014 (UTC)[reply]

Two points:

1. However interested one is, often these changes sneak up out of the blue. Big changes should be trailed far more widely, and consensus built that they are needed.
2. In both the visual editor and the style redesign (and possibly the others) things that were raised by the community very early on as problems were shipped. Again this speaks to the "we are the experts, we are getting ticks in boxes by consulting" mindset.

All the best: Rich Farmbrough, 03:50, 4 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:

The important point here may be to have a minimum level of discussion and participation before major features are turned on. Similar to what is described at WP:PROPOSAL. This may stifle innovation, but isn't that better than turning something on and then having a discussion about whether to keep it on or not? The idea should be to 'sell' a new feature to the community, get them excited about it and buying in to the idea at an active discussion (not just through beta testing). However, as TheDJ says, it would be best to leave the actual software development to those who know how to do that. The other wrinkle is Wikimedia-wide consensus vs local project-by-project consensus. I agree that some mention of VisualEditor and Flow should be in the final decision, but realistically that won't matter a great deal. The important point is that the discussions about those features are had before they are (re-)turned on. It is ultimately up to the community of editors to do that - it is not something ArbCom can do (leading horses to water comes to mind). Carcharoth (talk) 02:32, 3 August 2014 (UTC)[reply]

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

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

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

You're saying we disagree ... but I think we probably agree. I'm not saying the community should dump an RfC on you when you're ready to deploy, I'm saying you should be getting high-quality feedback all along, and letting the broader community give you that feedback on their own "turf" and in their usual ways might be the only way you're going to get it. It's got to work better than what we've done so far. - Dank (push to talk) 02:41, 3 August 2014 (UTC)[reply]

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

I've added some headers to make it easier to edit individual proposals. Feel free to replace the headers with names. Carcharoth (talk) 10:46, 3 August 2014 (UTC)[reply]

Proposed principles

Principle 1

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:

I like this and may adapt the wording for use in a similar principle. It should probably say something about how such differences are resolved. Carcharoth (talk) 10:50, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Principle 2

2) The Wikipedia community expects major discussions decisions 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:

Do you mean major decisions rather than major discussions? (e.g. "major decisions to be taken by consensus discussions"?) I may incorporate some of this wording as well (though not the closing parenthetical). Carcharoth (talk) 10:54, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Yes, decisions. (This one had a few redraftings along the way and it was late at night...). Andrew Gray (talk) 10:56, 3 August 2014 (UTC)[reply]

Principle 3

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:

I'm not convinced that BRD does apply here. Do you mean to the deployment of a software feature (deploy, roll back, discuss) or to the edit to common.js? Due to the technical nature, the standard practice is to discuss edits to common.js before they are made. As for the deployment of software features, the deployment was not bold (it was announced long in advance and carefully prepared - whether it was adequately publicised on the English Wikipedia is another matter). I think part of the problem here is that some on the English Wikipedia see software features as something they can chose to accept or not (a binary decision), while the WMF Engineering and Product Development team come up with features for all WMF wikis and see on-wiki opinions at local wikis as only one part of the decision they take on deployment (with the metrics they measure and gather making up other elements of the decision they take), with the binary choice for individuals to enable something provided at the preferences level. It is this disconnect that has repeatedly caused problems, as some parts of the English Wikipedia are used to making decisions themselves as equal partners, not feeding in their input for others to make the final decisions. I think the way the WMF engaged with the RfC process sent mixed signals. It should have been stated far earlier on what options were off the table, rather than the "we are listening to you and have made these changes" message that was coming across. The non-negotiable aspects should have been communicated far earlier in the process. Carcharoth (talk) 11:16, 3 August 2014 (UTC)[reply]

I agree with many of Carcharoth's comments on this point. We can't really have a BRD cycle with respect to something like turning MediaViewer on and off, if that means that any individual editor can disable the feature after installation in order to bring about a discussion. Major software changes are not akin to edits to an article or even a policy page. Newyorkbrad (talk) 00:28, 4 August 2014 (UTC)[reply]

We really ought to be having Discussion before bold moves or reversion, in this case. I concur with Brad & Carcharoth. NativeForeigner ^Talk 03:48, 5 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed findings of fact

Finding of fact 1

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:

I had hoped to avoid bringing in other examples, but a short finding along these lines (with the examples you propose below) may be useful. Thanks for bringing these together. Carcharoth (talk) 11:20, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

I think it's probably important to see this case in context - without the idea that every deployment has pushback (on a continuum from "grumbling" to "shut down completely") and the history that it's usually worked out okay, the dispute here can seem more dramatic than it is. This probably merges easily with #2 below and I wasn't sure whether to split them. Andrew Gray (talk) 11:30, 3 August 2014 (UTC)[reply]

I think this could be improved by saying that there are frequent major and minor software deployments made, some of which have been the subject of extensive community discussions, either project-specific or in more global forums. The average week in 2014 sees dozens of deployments.[11] The vast majority of them go entirely unnoticed by the enwiki community, and even most of those that are noticed are barely commented upon, unless it causes some form of breakage without advance warning. Risker (talk) 22:01, 3 August 2014 (UTC)[reply]

Indeed - on that theme, you could also extend this to note that there's a lot of small-scale js/css fiddling by users on-wiki which can have similar effects (altered interface, etc) but is rarely documented in the same way. These are the big rocks but there's a lot of sand around them. Andrew Gray (talk) 22:49, 3 August 2014 (UTC)[reply]

Finding of fact 2

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:

Thanks for this. As I said above, I may use elements of this verbatim in the final decision (whether it will be voted through is another matter). I will try and remember to credit people when I do that. Carcharoth (talk) 11:24, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Just a note that pending changes (a.k.a. flagged revisions) is indeed deployed on this project, and there are thousands of pages to which it has been applied. Risker (talk) 12:01, 3 August 2014 (UTC)[reply]

Changing to "withdraw or curtailed" and "Pending Changes Level 2" would be accurate, I think. I'm not taking a position on whether we should say that, though. - Dank (push to talk) 12:23, 3 August 2014 (UTC)[reply]

Well, not really; it's technically enabled, and we voluntarily refrain from using it - at least in part because the community's instructions to the developers in the design of pending changes was so poorly considered that by building what we asked for, the WMF gave us a less than perfect tool. I'd say that PC is a good example of what goes *wrong* when the community's opinions (especially the opinions of a tiny minority of the community) dictate what technical developments should be made and how they should work. Risker (talk) 12:47, 3 August 2014 (UTC)[reply]

DJ and Risker, I'm not saying the community does a fantastic job with technical issues (though PC feels more like an outlier than a good example to me, Risker). I'm not saying you have to put up with some RfC process that isn't working, either; I'm saying the community will expect you to at least give some community process a chance, because many vote-and-discussion processes on WP do work after a while, better than anyone could have expected. One extra constraint here is that the coders also need to feel comfortable communicating through the process. DJ, are there discussion boards (such as WP:VPT and WP:BOTREQ) or other environments on enwiki where coders tend to feel more comfortable with the culture than they do with one-off RfCs? - Dank (push to talk) 13:27, 3 August 2014 (UTC)[reply]

It is deployed, but I think it's reasonable to say that compared to the original proposal way back when (or indeed the revised what-we-asked-for proposal), that what we've got is definitely a delayed and later reconsidered version. I think my intent here wasn't to say that the outcome is always the most effective solution - in fact, it reminds me a lot of Churchill's comments about democracy! - but to note that a) large-scale decisions are usually honoured, and b) "WMF wins" is very far from being the default outcome. A lot of people seem to assume they invariably end with software deployed anyway, which doesn't seem to be the case. Andrew Gray (talk) 12:59, 3 August 2014 (UTC)[reply]

Finding of fact 3

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:

Could you provide some evidence directly confirming what is stated here? Carcharoth (talk) 11:26, 3 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

I had a poke around but (unsurprisingly) it's hard to get a good single link on-wiki. The WMF blog post in May 2010 gives a quick precis of the deployment history (as does an earlier one in March, linked there); lots of raw data here. Andrew Gray (talk) 11:40, 3 August 2014 (UTC)[reply]

(I should add that I don't have any reason to assume the MV rollout was deliberately modelled on the Vector one - just that the with-beta method used was clearly very similar) Andrew Gray (talk) 11:52, 3 August 2014 (UTC)[reply]

Finding of fact 4

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:

This is an excellent finding. Thanks for putting this together (I had used the tool you have used [the one linked from the page history] out in drafting a finding on the participation level at the Media Viewer RfC, but hadn't got round to doing the same for similar RfCs). Again, it may not get voted through, but I will definitely be proposing this in the final draft. Carcharoth (talk) 11:29, 3 August 2014 (UTC)[reply]

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.

Remedy 1

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:

Something like this is already in the draft, I think. I'll look at incorporating elements of this wording. The inclusion of a precedent is useful, thanks. Carcharoth (talk) 11:32, 3 August 2014 (UTC)[reply]

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

I wouldn't say that re-opening the previous RFC would be appropriate due to the way that it has been characterized my members of the community as not being accurate in it's evaluation of consensus nor in it's percieved environment when dealing with the question. I would strongly suggest that both members of the community and interested WMF developers come together to frame the question of the RFC in a manner that both parties agree to and agree to be bound by the consensus reached by the RFC for some reasonable period. Hasteur (talk) 05:05, 4 August 2014 (UTC)[reply]

I think I envisaged "re-opening the discussion" to cover "let's start again" rather than "let's use exactly the same system" :-). I agree that re-running the previous questions word-for-word would not be the most effective approach. Andrew Gray (talk) 11:53, 4 August 2014 (UTC)[reply]

Proposed enforcement

For these proposals, enforcement would seem inappropriate.

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

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:

The second sentence is crucial. While one would certainly hope that cases where an "official action[] of the Wikimedia Foundation or its staff ... impacts or has the potential to impact adversely upon the English Wikipedia or its editors" are rare, the committee shouldn't hesitate to take notice and act accordingly when it happens. T. Canens (talk) 04:23, 5 August 2014 (UTC)[reply]

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:

@Alanscottwalker: But doesn't quoting their site verbatim instead shift the conflict-of-interest to the Foundation's self-stated point of view? LFaraone 02:27, 14 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

If you are going to say this, the committee should not rely on a principal that is tailored to benefit its own conflict-of-interest, you should actually quote the site you link to: "The Wikimedia Foundation, Inc. is a nonprofit charitable organization dedicated to encouraging the growth, development and distribution of free, multilingual, educational content, and to providing the full content of these wiki-based projects to the public free of charge. The Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia, a top-ten internet property." wikimediafoundation.org(emphasis added). "The Wikimedia Foundation or WMF (a.k.a. the Foundation)—based in San Francisco—is the organization that owns the domain en.wikipedia.org. It is an organization that raises money, distributes grants, develops software, deploys software, controls the servers, and does outreach to support Wikimedia projects, including the English Wikipedia." [12](emphasis added)-- Alanscottwalker (talk) 23:37, 3 August 2014 (UTC)[reply]

@LFaraone: No. First, I assume you mean the first quote and not the second, but the Foundation is not making the principle on which to base an arbitration decision of theirs, so they cannot have a conflict-of-interest in adopting the principle. (As an aside, that pinging of yours did not work, I just saw this, so I have no idea if my ping will work.) Alanscottwalker (talk) 17:12, 16 August 2014 (UTC) @LFaraone:: arg, sorry. Alanscottwalker (talk) 17:14, 16 August 2014 (UTC)[reply]

I am uncomfortable with the statement "the Wikimedia Foundation (WMF - wikimediafoundation.org) exists to support the Wikimedia projects," which appears neither in WMF's mission statement nor in its guiding principles. It does appear in the WMF FAQ but that it essentially a fundraising document (well over half of the FAQ entries have to do with donating to WMF). I support ASW's wording although without the conflict-of-interest implication, in part because I don't quite understand the point he's trying to make. Short Brigade Harvester Boris (talk) 21:50, 17 August 2014 (UTC)[reply]

Hi. The COI is not part of what I suggested adopting, it was the quotes. I can go deeper in explaining why the arbs may have COI, if you would like, but I am sure they, as local admins, already can/have contemplated that without further explanation. Alanscottwalker (talk) 23:00, 17 August 2014 (UTC)[reply]

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

I should have made clear here that this principle (as I hope the numbering makes clear) was an alternative to the other one. It was initially proposed by another arbitrator (I'll let them comment if they wish to), and I am not sure about the last sentence either. What I don't agree with is the argument about 14,000 editors. The decision-making processes of the English Wikipedia and the WMF engineering teams are qualitatively different - hence the clashes. The English Wikipedia has never made decisions based on beta testing, or opt-in rates, or survey monkey results, or dashboard metrics. If all that was better explained to the existing segments of the editorial community that is used to the way the English Wikipedia takes decisions (by rounds of discussion), and they were prepared each step of the way, launches would be a lot easier. There are signs the WMF are coming round to the view that they need to do things differently. Whether a principle on WMF engineering decision-making processes (to go with the RfC one relating to the English Wikpedia) would help, I'm not sure. Carcharoth (talk) 10:00, 3 August 2014 (UTC) Salvio, I changed your indentation below to make clearer you are responding to Risker, not to me. Carcharoth (talk) 11:04, 3 August 2014 (UTC)[reply]

Remember, 14,000 editors *chose* to enable the feature in question even before it was the default, which is an overwhelming consensus in support compared to 64 saying it should be disabled. It's not the first time you have said this. And, then again, this is a non sequitur. Who cares about how many editors opted in? It's not like disabling the tool by default would impact on their decision; also, many (how many?, this I don't know) of those are probably people who have ticked the "automatically enable all new beta features" box in their preferences and, so, made no decision as to whether they explicitly wanted this thing enabled. Also, let's take a look at the approval rate of Media Viewer: here 28% percent of the respondents find it useful; here it's a bit better, but it's still only 36.14% of the respondents who find it useful. Not exactly a success... Salvio ^{Let's talk about it!} 10:49, 3 August 2014 (UTC)[reply]

A goal should be to develop a collaborative mechanism under which the community is assured that the Foundation developers are taking community input into account in their development activities and that community-member beta-testing is built into the development and evaluation process; and conversely, that the Foundation developers can have assurance that community input is based upon a full and fair evaluation of a proposed new feature, preferably by a reasonable number of participants with varying levels of experience with the project. Newyorkbrad (talk) 00:15, 4 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

I've been waiting on the other parts to assess any of these but "shared power" is more of a slogan than anything that is going to help to decide anything when it comes to particulars. For example, I "share power" with the admins, and they are also here to "serve me" as an editor, but that does not mean I make their decisions. Also, "features developed by the foundation" are used to share "free" knowledge, which is broader than this. Alanscottwalker (talk) 22:27, 2 August 2014 (UTC)[reply]

The last phrase of this is not a principle based on anything in policy, it's an opinion, and doesn't belong in there, particularly in the clearcut absence of anything resembling a consensus. Remember, 14,000 editors *chose* to enable the feature in question even before it was the default, which is an overwhelming consensus in support compared to 64 saying it should be disabled. Not every decision on this project is made by obscure RFCs. Risker (talk) 09:26, 3 August 2014 (UTC)[reply]

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:

I'd like to see "...by MediaWiki developers and administrators, familiar with the coding language," the parenthetical commas showing that it is not random devs and specialist admins, but rather those form both tribes that feel they have sufficient expertise for the changes they wish to make. All the best: Rich Farmbrough, 02:49, 4 August 2014 (UTC).

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:

The WMF can override consensus of English Wikipedia editors (or those of another project), but only at the risk of significant ill-will and demoralization of contributors. The En-WP community can sometimes prevent implementation of what the WMF staff considers improvements, but only at the risk of confrontation and losing the benefit of what can be enormous investments of staff time and hence of Foundation (and ultimately community donors') funds. We can spend large amounts of time here honing the fine points of wiki-constitutional-law, and intellectually I'm as equipped for the exercise as anyone, but if there is to be real value arising from this case, that is a digression. What needs to be accomplished, with this decision as a starting point, is to develop an agreed-upon mechanism or protocol for assessing how the WMF staff and the En-WP community (or by extension other communities) can collaborate in the development, testing, and evaluation of new features and interfaces so that "WMF developer vs. community" disputes and confrontations will be replaced by a "WMF developer and community collaborative project improvement decision-making" model to the fullest possible extent. Newyorkbrad (talk) 00:09, 4 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Newyorkbrad you are certainly correct that it is not worth going into fine detail, however it is the case that there are areas where the community wants the foundation to "just get on with it" on a day-to-day basis, gradually fading onto areas where the community takes almost complete control, and which the foundation would much rather keep out of for other reasons (not least liability). It may well be worth establishing some broad areas of consensus to degrees of overlap. All the best: Rich Farmbrough, 02:55, 4 August 2014 (UTC).

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:

I believe the crux of the matter, if we want to see a positive forward-looking outcome to the case, is to better define the protocols for developing new software/interface features to maximize collaboration. Although all the information flows discussed above have their place, there should be one specific place where WMF staff and En-WP (and other project) editors can discuss proposed software improvements, be notified of the need to beta-test works-in-progress, and hopefully reach mutually agreeable decisions following well-publicized decisions as to which features are ready for prime time. Newyorkbrad (talk) 00:03, 4 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Let us be clear: the community (for all our many faults as individuals and collectively) consists largely of highly qualified, highly experienced, highly vocal professionals. Even if all else were equal (i.e. the community did not resent being apparently ignored, for example) the WikiMedia projects will benefit substantially from close cooperation between the community and the foundation, on as many matters as possible (not just software). Understandably this is a difficult culture to build, but essentially it is the type of listening culture that all organizations should strive for. Therefore the relationship between the two entities needs to be wider and deeper than just MediaWiki features. All the best: Rich Farmbrough, 03:04, 4 August 2014 (UTC).

• I have proposed the creation of the interndisciplinary, widely representative Technology Committee at the WMF Board noticeboard. --Pine^✉ 03:34, 4 August 2014 (UTC)[reply]

• And by strange synchronicity, this email came out today... definitely seems to be an idea with general support from all sides. There's very little to lose by trying it/endorsing its creation. Andrew Gray (talk) 11:30, 5 August 2014 (UTC)[reply]

I realise that there is this overwhelming prejudice on English Wikipedia against anything that happens anywhere in the wiki-universe if this project has not been consulted in depth and has not somehow or other authorized such actions to take place; the fact that we can't even get ourselves organized enough to clean up our own messes (such as RFA) is immaterial to this philosophy. I suppose I should not be surprised to see the arbitrators endorsing such enwiki-centric, provincial thinking. But it's time to get over it and become part of the actual Wikimedia world of hundreds of projects. There are dozens of ways that people can keep apprised of technical and software updates planned, to comment on them, to encourage awareness of them, to participate in testing - but it requires people to think globally and act locally. This tech ambassador program has been around for a couple of years, for example, and there are dozens of enwiki editors who participate to some degree or other. But unless community members bother to bookmark or otherwise keep up with forthcoming tech updates, to actually make some effort to inform themselves, we're just going to see constant repeats of the kind of actions that have ultimately led to this RFAR. The responsibility for communication doesn't simply lie with the WMF (which has, indeed, communicated quite a bit about this) - it also lies with the community in actually paying attention to information that is made available. Risker (talk) 12:53, 5 August 2014 (UTC)[reply]

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:

• I would not call RfCs advisory. They are used widely used to determine community consensus, which is binding in most cases with the exception of the situations listed in Wikipedia:CONEXCEPT. Even when an administrator disagrees with a close as determined by a non-administrator, the administrator is usually required to adhere to the closing decision unless a successful challenge is made. --Pine^✉ 03:49, 4 August 2014 (UTC)[reply]
• I have to agree with the previous comment: I see nothing in the RfC write-up that says it is only advisory, and more importantly, if RfCs are only advisory, then who does have the authority to set policy? Why do people even bother to close the RFC then, rather than saying "thanks for your comments. Now an administrator/ArbCom/some guy from the WMF will read them over and try to take them into account when delivering his decision." Discussion to consensus is supposed to mean something here. Wnt (talk) 05:02, 4 August 2014 (UTC)[reply]

* I would say RfCs are advisory in the same way that a parent "advises" his/her child how to behave. No matter what the parenting style used, the intent is that the advice will be followed; no matter how the RfC is closed, everyone expects its findings to be followed. -- llywrch (talk) 05:59, 4 August 2014 (UTC)[reply]

• I think am important distinction here is that the requests for comment\consensus-gathering process is (more or less) binding on the community. However, an individual RFC is only part of that process - there's plenty of precedent to be flexible in complicated cases, and we have the power to say "let's extend this discussion for some more time"; "this has got horribly snarled up, let's start again with a clearer question"; "let's look at this again in a year", or something along these lines. Andrew Gray (talk) 11:57, 4 August 2014 (UTC)[reply]

• This RfC was especially "advisory" because there was nothing of a Policy rationale involved in the choice closed upon. It was a pure and unadulterated Vote -- not a discussion, at all, in actuality. Alanscottwalker (talk) 13:12, 5 August 2014 (UTC)[reply]
• Most RFCs are advisory, particularly if they recommend an action following them. User RFCs are always advisory. Admin RFCs are always advisory. Any RFCs whose result does not respect core policy are advisory (i.e., they are unenforceable). If one wants to consider WP:CONSENSUS to be core policy, then its policy-documented exceptions are as well. Risker (talk) 13:26, 5 August 2014 (UTC)[reply]

Yes, and by definition a mere Vote of "I prefer"/I don't prefer" is not a consensus, it is only the participants personal preferences. Alanscottwalker (talk) 13:31, 5 August 2014 (UTC)[reply]

When people choose to start or change a policy on en.wikipedia, isn't that a vote? You can't say that votes are only in interpretation of policy when votes create it. I think there has been quite a bit of discussion of Media Viewer faults, though fortunately much of it is out of date due to improvements. Wnt (talk) 16:46, 5 August 2014 (UTC)[reply]

You mean a discussion like at WP:VPR for a brand new policy - yes consensus for brand new policy is hard to come by, especially when all the facts are in movement. And note the heading for VPR says, Proposed software changes should be filed at Bugzilla Alanscottwalker (talk) 20:21, 5 August 2014 (UTC)[reply]

• The word "advisory" appears nowhere on WP:CONSENSUS, WP:RFC, and WP:RFA. I see no grounds for anyone to discount a consensus with a theory that consensus is advisory. Also, if an editor wishes to challenge the close and determination of consensus that was made in this particular RFC, that editor should go through the proper procedure for challenging a close. --Pine^✉ 07:49, 14 August 2014 (UTC)[reply]

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:

Long-accepted principle, although I don't support removing anyone's adminship in this case. Newyorkbrad (talk) 00:19, 4 August 2014 (UTC)[reply]

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:

@Guerillero: The original authority of ArbCom may have come from Jimmy, but the annual elections and the strong endorsement given to the redrafted arbitration policy when it was ratified very much means that ArbCom now derives its mandate directly from the community. And the distinction between authority and power is important here. ArbCom doesn't technically have the power to remove any of the advanced permissions it oversees. We rely on bureaucrats to desysop, and on Stewards at the meta-wiki to remove and add the CU and OS rights. It is the authority that resides in the institution of ArbCom. In the case of the WMF, they have the power to do (as others have said) pretty much what they want. What they don't have is the authority that comes from local processes with a democratic mandate. The general principle of least interference should also apply, with the WMF and Stewards (to give two examples of groups with global rights) generally deferring to and not interfering with local processes where they exist. The exception being in cases of emergency. Carcharoth (talk) 01:55, 3 August 2014 (UTC) I think the founder flag does still give Jimmy the power to desysop, whether he still retains the authority to make that stick is another matter.[reply]

@Alanscottwalker, you are right that the WMF do have a different sort of authority that derives from their legal status as owners of the site. But how does that work in practice? Those with the power to carry out a desysop are (as far as I'm aware) those that hold the staff global rights (with the 'userrights' permission). But looking at the 43 accounts that hold that right, I'm presuming that not all have the actual authority within the WMF to actually do that (there are presumably internal polices that mean most of them would get into trouble if they did anything like that without authorisation). The WMF Legal account and WMFOffice account are group accounts. The others are employees with Engineering and LCA as far as I can see. There are checks and balances in place (some of this documented on the meta-wiki, though the documentation was never fully completed as far as I can see). There are probably only a few individuals that are far enough up the WMF hierarchy to actually have the authority to threaten a desysop. Fabrice technically has the power to carry out a desysop, but it was Erik, who leads the Engineering and Product Development team, that stepped in here. Whether that was warranted from the perspective of the English Wikipedia is the crux here. It is direct interference and shouldn't be presented as anything else. It is also extremely rare and should only be done when absolutely necessary. I've not seen anyone from the WMF make the case that it was necessary, and Erik himself has acknowledged that it was not necessary. Carcharoth (talk) 10:16, 3 August 2014 (UTC)[reply]

This is something I hope will be included in the final decision, but conexcept does not apply to on-wiki actions. Under conexcept, "the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, and the activities of Wikimedia Commons" are "in a separate domain". The clause also mentions "independent, co-equal communities". It's unreasonable to interpret it as covering anything happening on-wiki. The principle merely means that the en.wiki community may not exercise its authority over off-wiki actions, even when they may have an impact on en.wiki. So, we may not prevent Commons from deleting an image, for instance. This is the only reasonable interpretation.

Also, while it's true that the Foundation has the de facto power to do what they want, it's also true that they have chosen to give a policy detailing the cases when they may intervene and override the community. It's wp:office (and wp:conexcept in the part where it refers to board decisions). They may change it, of course, but until they do, their employees are bound to respect it. And, since nowhere in policy does it say that Foundation employee may desysop admins, unless the Foundation change the policy, employees may not de jure desysop admins. They may do so de facto, but it would be entirely arbitrary and ArbCom reserve the right to reverse such an action. Salvio ^{Let's talk about it!} 10:27, 3 August 2014 (UTC)[reply]

And no Salvio, Arbcom does not have jurisdiction over staff when they are on this site. We have no jurisdiction over "official actions"; an arbitrary action is, by definition, not a valid exercise of power and, therefore, cannot be deemed official. Ergo, we do have jurisdiction over it. Salvio ^{Let's talk about it!} 11:50, 3 August 2014 (UTC)[reply]

Salvio, "official action" just means by virtue of their position, so no you don't have jurisdiction. You're wrong. An "official actions" can only be that which is taken by a Foundation employee *in the exercise of his functions*. And to determine which these functions are, we need to examine the limits of his power: an action which exceeds these powers is ultra vires (see the concept of excès de pouvoir) and so cannot be considered official. Salvio ^{Let's talk about it!} 12:42, 3 August 2014 (UTC)[reply]

I'm simplifying the issue, so it's possible something may not be expressed in the most precise manner; that said, you maintain that [we] can't rule thier actions ultra vires, You are the one that is attempting to make arbitrary decisions. Again, you're wrong. The first clause of Wikipedia:ArbCom policy#Jurisdiction is very clear: The Committee has jurisdiction within the English Wikipedia, which means that we generally have jurisdiction over all actions performed on the English Wikipedia, except, of course, for the cases where we don't, which are the exception. Therefore, unless it is proven that an action falls within one of these exceptions, we have jurisdiction (and we also do have jurisdiction to determine the extent of our jurisdiction, see Kompetenz-kompetenz). Salvio ^{Let's talk about it!} 13:10, 3 August 2014 (UTC)[reply]

It is proved that he is employed by the WMF, acting as an employee of the WMF, yes which means that his action was that of a foundation employee, not that it was an *official* action of a foundation employee. Also, again, the fact that he has the technical ability of doing something does not mean that he has the authority to do it. I have the technical ability if blocking editors, but I can't go around blocking people on a whim. Salvio ^{Let's talk about it!} 13:46, 3 August 2014 (UTC)[reply]

I have no interest in exploring the desysopping of anyone in this case. Newyorkbrad (talk) 00:10, 4 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

^{[citation needed]} for two reasons. (1) ArbCom gets its powers from Jimmy and not from some sort of social contract between the community and arbcom. That means that at a bare minimum, Jimmy would also have the power to desysop. (2) Just because the WMF has never tried to desysop someone does not mean that they do not have the authority to do so. Unless they have explicitly given up that power, they maintain it. --Guerillero | My Talk 01:17, 3 August 2014 (UTC)[reply]

While they may not have the authority which comes from local democratic process, that does not mean they don't have the authority. Decisions and acts of the WMF are not subject to local democratic process according to CONEXCEPT. And no, you don't have the power to restrict or define their authority, according to Arbcom policy. As for the general principal of interference, what ever that comes from, that's either your recognition that they do have the authority to interfere, or some internal-to-them restriction they can decide to dispense with, entirely, and you also do not have the authority or power to decide that for them. As all userrights are within their authority and power, making it stick is just what they can decide to do. At most, you have a separate authority to request desysop. Alanscottwalker (talk) 08:09, 3 August 2014 (UTC)[reply]

Who the WMF has "designated" (in the words of CONEXECPT), that is authorized (in the words of authority), have the WMF's authority and power. Alanscottwalker (talk) 11:35, 3 August 2014 (UTC) And no Salvio, Arbcom does not have jurisdiction over staff when they are on this site. Alanscottwalker (talk) 11:41, 3 August 2014 (UTC)[reply]

Salvio, "official action" just means by virtue of their position, so no you don't have jurisdiction -- you can't declare their action is 'one that only you would make', so no you don't have jurisdiction. Alanscottwalker (talk) 12:23, 3 August 2014 (UTC)[reply]

Salvio, You're wrong, you can't rule their actions ultra vires, (with, moreover, potentially legal consequences). You are the one that is attempting to make arbitrary decisions. The WMF can decide if someone of their staff is acting ultra vires, a court of law can decide that, but you cannot. Alanscottwalker (talk) 12:50, 3 August 2014 (UTC)[reply]

Salvio, Again, you're wrong. It is proved that he is employed by the WMF, acting as an employee of the WMF. It is proved that the WMF has designated and assigned him the right to edit that code and the right to change user rights. You're being arbitrary, if you claim he is not and has not. -- Alanscottwalker (talk) 13:30, 3 August 2014 (UTC)[reply]

Salvio, He has the WMF's official permission (Staff permission), that's not just a "technical ability", that's designating him for making their decision in the instance. As for using their permission blocking on a "whim", which appears to be some parade of horribles argument, the "whim" part is up to the WMF, not you. Your whim as a local admin, on the other hand, is subject to the committee. Alanscottwalker (talk) 14:33, 3 August 2014 (UTC)[reply]

Carcharoth: It does not seem to be within the committees remit to be concerned about the WMF's relatively small number of official staff permission grantees, as there are at least 300 or so websites owned and controlled by the Foundation (if I am reading [13] correctly), so there are a fractional number of Staff. Alanscottwalker (talk) 00:22, 4 August 2014 (UTC)[reply]

However EN:WP is by far the largest, and the rights apply to all sites, so 43 staff (possibly including some who have never edited a wiki) seem to have a level of rights that would allow them to basically close down the wiki until someone else with bigger rights took them out. This does seem rather a lot of people being given the Big Red Button. All the best: Rich Farmbrough, 03:13, 4 August 2014 (UTC).

Well, even if you look at only en.wiki.org, it's still fractional compared to number of pages, or number of edits, or number of editors. As for the rest, it seems a little paranoid, except if you also consider the potential for massive and little understood hacking of this site that might also need to be combated by teams. Alanscottwalker (talk) 07:01, 4 August 2014 (UTC)[reply]

Newyorkbrad "I have no interest in exploring the desysopping of anyone in this case." I don't think that is the intent of this section.It is to establish the normal (and emergency) procedure, to give context to actions, and threatened actions, that brought about the case in the first place. All the best: Rich Farmbrough, 03:10, 4 August 2014 (UTC).

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

Kww, I don't understand what you mean by "such accounts." If your view is that staff members should not be permitted to edit at all in their individual capacity then I reject it. Newyorkbrad (talk) 00:18, 4 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

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

I think this principle misses that it is even more important for WMF staffers to indicate when they are not making an office action. If someone is just doing some casual editing out of interest or "in order to get the feel for how things work", we don't want the WMF to be exposed to potential liability issues every time he writes something that a lawyer could try to claim is actionable, based on the theory that "editors might have thought it was an official action." Also, I think it is worth evaluating whether, if every WMF member did all WMF actions under WMF accounts, could a single manager easily review all those edits daily in order to make sure that any problems are rapidly given a second look? Wnt (talk) 05:10, 4 August 2014 (UTC)[reply]

Newyorkbrad, I don't believe that any account held by a WMF member and not labeled as a WMF should have any administrative privileges. The whole issue of an account "taking actions" seems moot when applied to an account without administrative privileges, so I think this whole point is limited to administrative accounts.—Kww(talk) 04:03, 5 August 2014 (UTC)[reply]

I'm sorry, Kww, but that's downright insane. I've been around since 2003, admin since 2007 and checkuser since 2009 – all of this long before I ever contemplated working for the Foundation. I'm a valued (at least to some) member of the community in those functions and I can't think of a single good reason why my standing has somehow degraded to the point where I could no longer hold those bits because I have since started working for the Foundation.

And yes, I do have a staff account and it does have +staff (mostly for reasons of checking data leaks in replicas and tracking down errant bots). — Coren ^(talk) 12:57, 7 August 2014 (UTC)[reply]

Coren, I offered above to discuss whether there was a way to identify a group of roles where the conflict was too small to worry about. NYB didn't respond. There probably are roles that aren't hopelessly conflicted. Denying that the problem exists at all doesn't help identify them, and unfortunately looks like it will block action on the fact that whatever the set of unconflicted roles might be, Erik and Phillipe aren't included.—Kww(talk) 13:45, 7 August 2014 (UTC)[reply]

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) 01:37, 4 August 2014 (UTC)[reply]

Media Viewer roll-out and launch

Media Viewer roll-out

The release plan for Media Viewer (mediawiki.org) states that the extension was created "through a series of discussions held in 2013 on multiple channels". It was tested in beta deployment on the English Wikipedia from November 2013 to June 2014. It was rolled out of beta on a number of wikis prior to its launch on the English Wikipedia. The initial version of the English Wikipedia page on Media Viewer (Wikipedia:Media Viewer) was created on 25 April 2014‎ by Fabrice Florin (WMF) (talk · contribs) [Product Manager, Wikimedia Foundation] with the edit summary: "for ongoing discussions with English Wikipedia users."

Comment by Arbitrators:

Comment by parties:

Comment by others:

Publicising of Media Viewer

An early mention of Media Viewer was at the technical village pump in relation to Beta Features (8 November 2013). The extension was further publicised in a number of locations on the English Wikipedia in April and May 2014 prior to launch. There was an introductory post at the technical Village Pump (28 April 2014). There were five posts made on 2 May 2014 (miscellaneous Village Pump; Talk:Main Page; Wikipedia talk:Featured pictures; Wikipedia talk:Picture of the day; Wikipedia talk:Image use policy). Media Viewer was also featured in The Signpost edition of 14 May 2014. A series of posts at the technical Village Pump preceded the launch: 13 May 2014; 16 May 2014; 21 May 2014; 3 June 2014. The roll-out and launch of Media Viewer was also mentioned a number of times at Wikimedia locations outside the English Wikipedia.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Media Viewer discussions

Prior to the launch of Media Viewer on 3 June, a limited amount of discussion took place on the talk page. Between 25 April and 27 May, the talk page was edited 24 times by 7 users (including 3 WMF employees). After the launch, there was more extensive discussion at the technical Village Pump. Discussion at the Media Viewer talk page increased, but continued to be relatively limited (page history statistics - 127 edits by 32 users as of 31 July) compared to the input received at the request for comments (RfC) launched on 7 June.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Conclusions

Although Media Viewer was publicised in a number of locations over the months prior to its launch and underwent extensive beta testing, there was only limited participation at the talk page created for the purpose of discussing the extension with English Wikipedia users. There was no attempt made to start a widely publicised discussion at that talk page with English Wikipedia users regarding the upcoming launch. In the absence of such a discussion on the talk page, the most extensive discussion of Media Viewer took place at the request for comments (RfC) created four days after the launch.

Comment by Arbitrators:

Comment by parties:

Comment by others:

"There was no attempt made" is a masterfully ambiguous use of the passive voice! Not quite clear here what it's thought should have happened - if anything, the conclusion here is that these sorts of feature-specific discussion pages may sideline discussion and not always be the best approach. Andrew Gray (talk) 12:08, 4 August 2014 (UTC)[reply]

I totally disagree with this conclusion. Every attempt was made to invite people for a large discussion (although not for a vote, I'll give you that if that's what RFCs are these days). The only way this could have gotten more attention was putting site notice banners on the top of every page, like we (en.wp) did in the past (a practice deprecated by the community due to notification 'overload'). —TheDJ (talk • contribs) 20:31, 5 August 2014 (UTC)[reply]

Media Viewer RfC

Discussion at Media Viewer RfC

A request for comments (RfC) relating to the Media Viewer was created 7 June 2014‎ by User:Pine (initial layout). The RfC asked two questions about Media Viewer in relation to logged-in and non-logged-in users: whether Media Viewer should be enabled or disabled by default, and if disabled, under what conditions should it be re-enabled? The RfC ran from 7 June to 9 July, and prior to its closure was edited 383 times by 110 users (page history statistics).

Comment by Arbitrators:

Comment by parties:

Comment by others:

Publicising of the RfC

The RfC was publicised by the RfC bot on 7 June (this automated process added an entry for the RfC to two RfC subpages: [14], [15]). Also on 7 June, the RfC was mentioned at the technical village pump ([16]) and on the Media Viewer talk page ([17]). The RfC was also mentioned in The Signpost editions of 11 June and 25 June. An entry for the RfC was added to the Centralized discussion template on 23 June and removed on 13 July.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Closing of the RfC

On 9 July 2014, User:Pine requested closure of the RfC by leaving user talk page messages for User:Armbrust and another user ([18]; [19]). The close was performed by User:Armbrust on 9 July with a series of three edits over several hours ([20], [21], [22]), concluding: "There is a clear consensus that the Media Viewer should be disabled for both logged-in and non-logged-in users" (RfC page after closure). The wording of the close was modified by Armbrust three days later (12 July) to add the words 'by default' ([23]).

Comment by Arbitrators:

Comment by parties:

Comment by others:

The change in the close should be broken out separately as an "after the RFC" action, particularly as MZMcBride's code reflected the literal meaning of the original close (but not the revised closing statement). Risker (talk) 03:37, 14 August 2014 (UTC)[reply]

Conclusions

The Media Viewer request for comments (RfC) was started 4 days after the launch of the extension. Although started in good faith in response to similar discussions on other WMF wikis, the creation of the RfC was premature and should have been preceded by discussion and planning, including liaison with those at the WMF responsible for the roll-out. The RfC should have been publicised at 'Centralised discussions' from the start, not 16 days later, and a watchlist notice and a longer survey period than 30 days should have been considered. The request for closure of the RfC should have been made at a suitable noticeboard, or arranged in advance with an experienced closer (usually an administrator) or panel of closers. The error in the initial wording of the closure was an additional irregularity.

Comment by Arbitrators:

I'm not sure the initialization of the RfC itself was premature, though I do agree with the rest of the above statement. NativeForeigner ^Talk 03:53, 5 August 2014 (UTC)[reply]

I believe that the principal actors in this dispute all understood the close as meaning Media Viewer should be disabled by default rather than disabled outright, so I find the wording error to be a relatively minor problem. I agree that the RFC was insufficiently publicized in light of the totality of circumstances. T. Canens (talk) 04:32, 5 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

• Excuse me, but this conclusion is inappropriate.

• What policy or guideline supports conclusions like "the creation of the RfC was premature and should have been preceded by discussion and planning, including liaison with those at the WMF responsible for the roll-out"? As far as I can tell, none exists.
• Neither is there a guideline or policy obligating RfCs to be published at "'Centralised discussions' from the start".
• Neither is there a guideline or policy that requires a close to be made by filing a request at a noticeboard. See WP:CLOSING.
• That "The error in the initial wording of the closure was an... irregularity" is not in dispute, and could be a finding of fact instead of a conclusion.
• This conclusion would be better restated as a request from the Arbitration Committee to the community to develop more specific guidelines for certain types of RfCs, and I would support such a development. This development would not apply retroactively to any RfCs incuding the MediaViewer RfC which were proper under existing guidelines and policies at their time of creation. --Pine^✉ 03:58, 4 August 2014 (UTC)[reply]
• I agree with Pine again. The whole point of an RfC is to take a contentious issue and discuss it and try to find a consensus about it. With this and the comment about RfCs being advisory above, I feel like these conclusions are drawing very near to being a coup d'etat - but I don't even understand who the new overlords would be. It seems like the community is being expected to put a lot of belief into delusions of power, where they think that they have the choice whether to implement something until they make a decision and get overruled, they think they can discuss an issue at the RFC only to find out it is 'advisory' and beyond that, illegitimate. If the power of Wikipedia's community is a delusion, does this mean that community principles like NPOV are also a delusion that can be overridden whenever the NPOV we come up with conflicts with, say, what a reputation management firm has been hired to enforce? Wnt (talk) 05:22, 4 August 2014 (UTC)[reply]
• To be honest, I think this has gone a little sideways. The more I think about it, the more I become convinced that the advertising could have been better, but that ultimately this wasn't the problem. An RFC advertised this way could potentially have resulted in a very large turnout, and it's mostly bad luck it didn't. With the exception of the confusion around closing it, we should look at turnout rather than process before deciding whether the RFC was problematic. Andrew Gray (talk) 11:59, 4 August 2014 (UTC)[reply]
• This appears to be more opinion than fact, and much of the opinion is not supported by evidence. While there are actions on Wikipedia which are done so well they become exemplars, and while some actions are done so poorly they need criticism and adjustment, the majority of actions on Wikipedia simply fall within guidelines and common expectations: they are neither wonderful nor dreadful, but serve us well enough to make this project work on a day to day basis. The RfC was not an exemplar, but nor was it so far below normal standards that it needs ArbCom criticism. It was advertised, it met requirements, it attracted attention, including from WMF staff, and it ran for a reasonable length of time. If I had not taken part, and had been asked to close, I would have waited a while longer as comments were still coming in; however, that would have been my personal judgement. The closer assessed that there were enough comments and that the RfC had run long enough for consensus to be clear; that assessment falls within normal parameters. It is common for a close to be criticised by those not satisfied with the outcome.

WMF developers boldly changed the way images were handled by default for all users on en.wp. After reflection and discussion, the en.wp community reverted that change from a default for all users, to an opt-in, feeling that the changes were not encyclopedic, and were taking Wikipedia in an inappropriate direction. The floor is now open for more discussion to take place. What has happened so far is what happens daily on Wikipedia, and is part of the consensus model of the community.

The weakest and most questionable aspects of this incident are not the RfC itself, but the implementation of the "revert" and the response to it by WMF. SilkTork ^{✔Tea time} 01:32, 7 August 2014 (UTC)[reply]

SilkTork, the enwiki community did not in any way find that "the changes were not encyclopedic, and were taking Wikipedia in an inappropriate direction"; only your own "vote" uses the term "encyclopedic", and the complaints about the software were focused on its functionality or its general usefulness. More importantly, your saying "the en.wp community reverted that change from a default for all users, to an opt-in" indicates you completely misunderstand what actually happened here - the code inserted completely disabled the MediaViewer and actively prevented opted-in users from accessing it. It was a hack, bad code that did not reflect the supposed intention of the close of the RFC (although interestingly it does reflect the literal meaning of the original closing statement, the one everyone agrees was made in error). Risker (talk) 03:29, 14 August 2014 (UTC)[reply]

Discussions and actions following RfC

Discussion following RfC closure

After the Media Viewer request for comments (RfC) was closed at 10:23 on 9 July 2014, discussion started on the RfC talk page and continued for the next 10 days (RfC talk page as of 19 July). Around 31 hours after the RfC had closed, Fabrice Florin responded on behalf of the WMF at 17:45, 10 July 2014 with a statement that included: "After carefully reviewing this proposal, we recommend that Media Viewer remain enabled on the English Wikipedia". 90 minutes later (19:15), User:MZMcBride suggested code to add (with possible further modifications as needed) to MediaWiki:common.js (the page controlling sitewide javascript) to bring "the decision to enable or disable Media Viewer within the purview of local site administrators".

Comment by Arbitrators:

Comment by parties:

Comment by others:

Edits to MediaWiki:common.js

At 19:59 10 July 2014, 44 minutes after the suggestion on the RfC talk page, administrator User:Peteforsyth made the suggested edit with the edit summary: "disable Media Viewer by default per Wikipedia:Media Viewer/June 2014 RfC". In the description, Peteforsyth cited the RfC and stated his edit was "based on instructions from User:MZMcBride; consensus determined by User:Armbrust". Seven minutes later (20:06), User:Eloquence (Erik Moeller, acting in his official WMF role as Deputy Director and VP of Engineering and Product Development) reverted the edit with the edit summary 'Undid revision 616426492 by Peteforsyth (talk) - per Fabrice's explanation'. Subsequent discussion determined that the suggested code disabled Media Viewer for all users regardless of preferences, and would likely have been reverted by local administrators and volunteer developers without intervention from the WMF.

Comment by Arbitrators:

Nothing in the Common.js edit summary indicated that the edit was done in an official role; accordingly I would not characterize it as such. T. Canens (talk) 04:12, 5 August 2014 (UTC)[reply]

Erik Moeller subsequently identified the change as a "WMF action"; I don't think it's inappropriate to state the edit was made in his official role. GorillaWarfare (talk) 12:27, 8 August 2014 (UTC)[reply]

Per #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". Thus, in my view we should find the attempt to retrofit WMF status onto the edit (in edits to a completely different page, no less) ineffective as far as we are concerned: if an unlabeled account is used, the official nature of the action must be clearly indicated in the action itself. Otherwise, an editor who encounters one of Eloquence's edits would be forced to review all of his later edits before they can be sure that the edit was not done in an official capacity. T. Canens (talk) 13:47, 8 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

T Canens: So? Where does that lead? Then all you have is a user boldly single-reverting another user's boldly bad coding, which the first user says was bad and should be reverted. Alanscottwalker (talk) 15:38, 5 August 2014 (UTC) (I should add that I disagree with you, Fabrice spoke on behalf of the WMF and Pete has long known the WMF's Eric/Eloquence)-- Alanscottwalker (talk) 15:43, 5 August 2014 (UTC)).[reply]

Subsequent actions and discussions

Following his reversion of the edit to MediaWiki:common.js, Erik Moeller/Eloquence left the following message at User talk:Peteforsyth: "Per Fabrice's explanation, please refrain from further edits to the site JavaScript, or I will have to temporarily revoke your admin privileges. This is a WMF action." (20:07, 10 July 2014). The statement relating to WMF action and revoking of admin privileges was raised and discussed at the administrators noticeboard (AN archive of discussion, 10-11 July). Around 14 hours after the noticeboard discussion had been ended, a request for arbitration was filed by User:28bytes (14:38, 11 July). Discussion also took place on the wikimedia-l mailing list ([24]; [25]; [26]). During the AN discussion, Erik Moeller/Eloquence apologised for his heavy-handed approach and acknowledged that an explanation without a warning would have sufficed. He also stated he "wanted to be clear that we're not going to disable this feature". During the request for arbitration, Peteforsyth stated ...I was utterly ignorant that [the code] would have that sweeping effect. Perhaps I acted in haste.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Er, no, Erik did not apologize in a meaningful way: "I'm sorry if my message to Pete came across as heavy-handed...".I'm sorry you were offended "apologies" aren't. Real apologies consist of a) unequivocal admission of wrongdoing, b) sincere expressions of regret to the offended part(ies), and c) mitigation / undoing of action, if applicable. (Probably not in this case.) This WMF double speak apology / non-apology did little to quench the brewing tempest. NE Ent 01:07, 8 August 2014 (UTC)[reply]

We have enough trouble getting folks to close RFCs and getting admins to do admin scutwork without crucifying them because they inadvertently, in good faith, step on WMF's toes. Peteforsyth implemented the close of the RFC in good faith, was magnanimous when reverted, and has generally acted with class. There should be no findings come out of this that criticize him. NE Ent 01:07, 8 August 2014 (UTC)[reply]

Conclusions (A)

The wording used by Fabrice Florin in his response on behalf of the WMF to the RfC ("we recommend") has been acknowledged by Eloquence/Erik Moeller as "insufficiently clear". Fabrice Florin had earlier (18 June) stated that the ultimate decision on Media Viewer lay with the WMF's Executive Director, however the fact that local administrators disabling site features is not acceptable should have been stated when Media Viewer was launched, and certainly should have been stated when the RfC was created. Eloquence/Erik Moeller has subsequently stated that:

"an escalation like the one that occurred could have perhaps been avoided if we had stated principles more clearly upfront [...] We will work together to develop internal guidelines on how we respond to such RFCs, specifically with an eye to clear rules of engagement." 27 July 2014‎

Comment by Arbitrators:

Comment by parties:

Comment by others:

Insert "default" between "Viewer" and "lay". It is clear from the June 18 statement that disabling the feature was not up to local consensus or local admins. The response to the WMF cannot be, "I did not hear that", going 'I did not hear that, so I will do whatever', is itself escalation. Alanscottwalker (talk) 12:37, 6 August 2014 (UTC)[reply]

Conclusions (B)

Given the lack of clarity initially expressed, the suggestion of code to disable Media Viewer was valid but the implementation by Peteforsyth was hasty and unnecessarily escalated matters. The insertion of the code should not have taken place without further discussion (e.g. at the common.js talk page).

Comment by Arbitrators:

Comment by parties:

Comment by others:

• I believe that this is not in dispute. If I had been asked at the time of closure if the RfC implied that the MediaViewer should be disabled for everyone instead of being disabled by default, I would have said no but there should be a discussion about how to best enact the community's decision if there was not an easy way to do so. I believe that I may have accidentally contributed to Peteforsyth's errant decision by not asking Armbrust to clarify his closing statement. --Pine^✉ 04:21, 4 August 2014 (UTC)[reply]

@Pine:, you didn't do anything wrong. I had a misunderstanding about what the code would do, not about what the consensus was. To be honest, I hadn't even noticed at that point that the words "by default" were not included in the closure, because it seemed so obvious to me that the RfC had been only about default behavior. -Pete (talk) 17:41, 4 August 2014 (UTC)[reply]

• Thanks Pete. --Pine^✉ 19:08, 4 August 2014 (UTC)[reply]

Conclusions (C)

Peteforsyth, by inserting sitewide code that he did not understand, and by taking hasty actions to implement the result of an RfC where he had participated and expressed strong views ([27], [28], [29], [30]), fell short of the standards expected of administrators.

Comment by Arbitrators:

Comment by parties:

Comment by others:

I can't agree to this without clear demonstration that he should have reasonably been expected to be aware of some catastrophic consequence of his action. All the best: Rich Farmbrough, 04:09, 4 August 2014 (UTC).
04:09, 4 August 2014 (UTC)[reply]

I think this is too severe a determination. How often has the database been stuck in read-only mode for half an hour because an admin did something wrong? I think the usual slap attack with a wet fish, via informal channels, is sufficient to deal with this. Wnt (talk) 05:28, 4 August 2014 (UTC)[reply]

Unsubstantiated and harsh. The "he had participated in" is also loaded and weasel worded, implying that no admin may ever enact the outcome of an RFC he participated in but didn't close, which is patently false. Dennis Brown | 2¢ | WER 11:57, 23 August 2014 (UTC)[reply]

Not unsubstantiated. According to Pete, the edit to the software common was "ill-informed, and at worst negligent." And "he had participated in" has no loaded or weasel words, it is fact. Pete acted rashly in administration, and this rashness appears to accord with his prior involvement. Of course, whether any of this should be at arbcom to comment upon (it should not) is another matter. Alanscottwalker (talk) 13:52, 24 August 2014 (UTC)[reply]

Conclusions (D)

The revert by Eloquence/Erik Moeller was justified, but he failed to explicitly state in his edit summary whether he was acting in his community or WMF role (the edit could have been carried out using his local administrator rights). By subsequently stating that he had carried out the revert in his WMF role (using his 'editinterface' permission from his staff global rights) he asserted jurisdiction for the WMF over the editing of common.js. He also asserted his right to use his 'userrights' permission (again, from his staff global rights) to desysop if necessary, though this was not a situation requiring an emergency desysop. These assertions were an unnecessary and arbitrary use of staff power in a situation where local processes (with more authority) would have been sufficient.

Comment by Arbitrators:

Erik, thanks for asking for clarification (your comment at 18:49). What I am saying here (referring back to the wording of earlier proposed findings) is that the change would likely have been reverted by local administrators and volunteer developers (see here). As regards the mention of a desysop possibility, the local process here was linked above in the 'authority to desysop' principle. I have some follow-up questions that I will be asking later today that may help clarify things some more. It is worth noting that the exact wording here may get changed before being proposed for voting (that is the purpose of this workshop). Please do comment on any aspect of the proposals you have questions on. Carcharoth (talk) 06:45, 5 August 2014 (UTC)[reply]

Erik, I've not had time yet to follow up with those questions I mentioned in my reply above. Apologies for that (things were hectic for me this week and there is not much time this weekend either, and I'm aware you may not have much time available over the coming days either). I will ping you again when I put the questions up. Carcharoth (talk) 07:01, 7 August 2014 (UTC)[reply]

I would go further than this. The gratuitous desysop threat has a substantial and unjustifiable adverse impact on enwiki by causing significant unnecessary escalation. If administrators can be expected, on pain of desysop, to not engage in off-wiki conduct that would bring the project into disrepute, they can be similarly expected to not engage in conduct in their staff capacity that unjustifiably adversely impacts the project. T. Canens (talk) 19:40, 5 August 2014 (UTC)[reply]

@Eloquence: There are existing procedures for removal of administrator rights. In my opinion, these procedures would have been sufficient in this situation. GorillaWarfare (talk) 02:00, 15 August 2014 (UTC)[reply]

@Risker: We're actually a pretty technical bunch this term—at least three of us on the Committee right now are software developers. I think more than three of us are technical enough to see that Peteforsyth's edit was not causing any sort of critical damage to the wiki that might justify an out-of-process desysop. The timeliness issue is, I suppose, legitimate, given our recent track record. Regarding your statement that "The disruption to all users (editors and readers) because of this was significant; even a minute of the common.js failing to operate properly affects tens of thousands of users," can you be more specific? I'm not clear on how the edits to common.js caused the site to fail to operate properly, or caused such widespread disruption. I'm aware many projects lack Arbitration Committees, but this one does not, and neither, for that matter, does the German Wikipedia. GorillaWarfare (talk) 02:32, 16 August 2014 (UTC)[reply]

@Rschen7754: That may well be. I know relatively little about the German Wikipedia and their processes; I mostly mention the German Wikipedia's Arbitration Committee because this issue seems to have been most heated on the English and German Wikipedias. No threat of desysopping was made (to my knowledge) on the German Wikipedia, so I think discussion of their desysopping mechanisms would be rather academic here. GorillaWarfare (talk) 02:46, 16 August 2014 (UTC)[reply]

Comment by parties:

Carcharoth, could you clarify what you mean with "where local processes (with more authority) would have been sufficient"? Thanks, --Erik Moeller (on behalf of WMF) 18:49, 4 August 2014 (UTC)[reply]

Comment by others:

"This edit is justified" is a vague phrase. It is possible to make the same edit with several different motivations, some legitimate and some not. If an edit was made with one motivation, but would be justified given a different motivation, does that count as a justified edit or not? (There's a difference between "I'll revert the edit because the edit didn't work properly" and "I'll revert the edit because nobody is allowed to remove this feature at all".) Ken Arromdee (talk) 17:38, 5 August 2014 (UTC)[reply]

GorillaWarfare, the antipathy that the Arbitration Committee has shown toward the WMF over the last year or two is highly suggestive that it would refuse to take action against a user based on the request of a WMF staffer at all. More specifically, the Committee has never handled a matter relating to WP:CONEXCEPT, and it is clear from the comments of the arbitrators that there was (before this full-fledged, months-long case) insufficient technical expertise and understanding of WP:CONEXCEPT prior to the case for anyone to be assured that the committee would be able to respond in a timely and appropriate manner. The threat of an edit war on the common.js was removed by the bald statement that further similar actions would result in a temporary desysop until and unless the administrator agreed not to repeat the action or perform similar actions. Perhaps because of this case, no similar warning was given on dewiki in similar circumstances; that project had a full-scale edit war. The disruption to all users (editors and readers) because of this was significant; even a minute of the common.js failing to operate properly affects tens of thousands of users. The WMF always retains the right, under the terms of use, to remove access when it has reason to believe there is intentional disruption to the project, and it does not need to use Arbcom's processes to do so. Remember that only a tiny number of projects have arbitration committees. Risker (talk) 03:51, 15 August 2014 (UTC)[reply]

"he failed to explicitly state in his edit summary whether he was acting in his community or WMF role" is incorrect. His user page states explicitly, and has done for months, that Unless otherwise stated, any edit to Wikimedia projects by myself is an act of a regular member of the community and administrator, not a legal or official action. His edit [31] of 20:06, 10 July did not state that it was an official or legal action and therefore, by his own declaration, was made in his personal capacity as a member of the community. On the other hand, his edit [32] of 20:07, 10 July threatening to desysop Peter Forsyth, did state, following the threat, This is a WMF action. -- not was, but is. We conclude that the change to the site javascript was a personal action but the threat to desysop was a WMF action. Deltahedron (talk) 19:26, 15 August 2014 (UTC)[reply]

First, it is not incorrect as a matter of language. More to the point, the circumstances cannot be reasonably construed that way. First, Pete who was reverted knows Eric, and knew why it was him that showed up and it was not to make some personal edit.[33] Second, the edit summary specifically said that the revert was being made in accordance with the WMF representative's prior explanation. Third, Eric then posted to Pete's page for the WMF. Moreover, even if you want to, against the evidence out of spite or something, somehow say that Eric was not acting for the WMF, so what? Where does that lead with one revert? Alanscottwalker (talk) 21:08, 15 August 2014 (UTC) Word struck in deference to request below, although not the request's reasoning. Alanscottwalker (talk) 13:29, 16 August 2014 (UTC) [reply]

I'm going by the plain language of the user page and the edit summary in question. If you want to reinterpret those in some other way, you need a better argument than "against the evidence out of spite". Please strike your use of the word "spite". Deltahedron (talk) 21:15, 15 August 2014 (UTC)[reply]

That's not my argument. You'll need to reread. Alanscottwalker (talk) 21:18, 15 August 2014 (UTC)[reply]

That is your only argument for wanting to ignore the plain language and embark on an over-sophisticated interpretation of the context. Now, about that apology you owe me for imputing bad faith? Deltahedron (talk) 21:25, 15 August 2014 (UTC)[reply]

No it is not, and spite or something is not imputing anything. Alanscottwalker (talk) 21:31, 15 August 2014 (UTC)[reply]

I don't think I need to respond to that. After all, this is a workshop page, for reasoned argument. I've made my point, such as it is, and you've made yours. Others can decide. Deltahedron (talk) 21:37, 15 August 2014 (UTC)[reply]

Sure. But where your argument leads, which was the question phrasing you took issue with, would be helpful. Alanscottwalker (talk) 21:46, 15 August 2014 (UTC)[reply]

I have struck the word. I should add that I am not ignoring the plain meaning of Erik's page: it does not restrict him to a formula for "stating otherwise" and his summary referring to the WMF's prior statement fulfills it (and this is essentially undeniable in light of the rest). Alanscottwalker (talk) 16:18, 16 August 2014 (UTC)[reply]

Thank you for doing that. Deltahedron (talk) 16:22, 16 August 2014 (UTC)[reply]

@Risker:, @GorillaWarfare: I've never heard of dewiki ArbCom desysopping someone though; their desysop process is generally community-driven. en.wikipedia's arbcom is the exception rather than the rule in many ways, as most arbcoms do not handle desysops, and few handle CU/OS, and no other ones require identification or automatically grant CU/OS to members or handle private info in the same way. In fact, I think it was because of this that the edit warring on dewiki continued; on enwiki ArbCom would probably have desysopped on wheel warring alone. --Rschen7754 02:40, 16 August 2014 (UTC)[reply]

FYI Erik Möller/Eloquence was blocked on de.wiki for 1 month beginning on August 11. The other WMF employee-admin involved in the wheel war, Jan Eissfeldt has been recalled, and under the rules of de.wiki must start an RfA within 30 days, or gets desysopped by default. (Anytime he would start an RfA now, he would be nuked out of adminship, given the overwhelming majority against the MV at the local RfC, so I suppose he'll take the time-out.) de.wiki ArbCom has no role in this case there, so far. Kraxler (talk) 19:40, 16 August 2014 (UTC)[reply]

Conclusions (E)

The subsequent apology by Eloquence/Erik Moeller for his heavy-handedness failed to mitigate the effect of such assertions.

Comment by Arbitrators:

The apology didn't eliminate the effect of what was said but it certainly did mitigate it. Newyorkbrad (talk) 19:21, 4 August 2014 (UTC)[reply]

Per Brad. If Erik had stood by his original statement without clarifying that his communication was suboptimal, a statement along these lines would be more justified. NativeForeigner ^Talk 03:55, 5 August 2014 (UTC)[reply]

Contra NYB and NF, I find any mitigating effect of the apology to be quite de minimis. T. Canens (talk) 04:03, 5 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

I don't see this one either. If the issue lingered beyond the apology, that is due to underlying policy uncertainties of the type this case was supposed to settle. Moeller isn't responsible for the unclear bureaucratic status of Common.js or any other border dispute going on here. So I don't think he should be blamed for it the way this principle seems to suggest. Wnt (talk) 05:32, 4 August 2014 (UTC)[reply]

If his apology had been sufficient, we wouldn't be here discussing this. -- llywrch (talk) 06:21, 4 August 2014 (UTC)[reply]

If true, that would have been unfortunate, because as I went on about above, I think the biggest concern here is the potential for any of hundreds of admin accounts to be hacked and change Config.js to infect users with malware. At the end of the day, no newspaper (except maybe the Daily Dot) is going to care whether Moeller gets a tongue-lashing from ArbCom. But if people get infected by malware from browsing Wikipedia, believe me, that'll be in the papers. Wnt (talk) 19:40, 4 August 2014 (UTC)[reply]

I think even T. Canens's description as de minimus is giving it too much credit. It seemed more akin to an old bullying trick of intentionally causing harm and then apologizing so that the victim looks like an ass if he presses the point.—Kww(talk) 04:07, 5 August 2014 (UTC)[reply]

As per Kww. User:Eloquence is a bully, and this was self evidently the action of a bully. Pedro :  Chat  18:26, 7 August 2014 (UTC)[reply]

Seems to me that it was a brusque overreaction to what was clearly a breakdown situation in "the community" with respect to the consensus assessment process and the implementation of the consensus.

The apology obviously mitigates the effects of the somewhat draconian response, as Peter himself has basically stated.

The focus should therefore be on how to improve various aspects of process related texts and the like to prevent a breakdown situation and facilitate better coordination in advance. Perhaps a new class of RFC should be created for issues that impact the entire site.--Ubikwit ^連絡 _{見学/迷惑} 20:44, 7 August 2014 (UTC)[reply]

Per KWW and Pedro. The effect of Erik's actions, even after his apology, have a far reaching and chilling effect on the community, including admins on the whole. Glossing over his actions with a simple slap on the wrist simply endorses his heavy handed tactics. Dennis Brown | 2¢ | WER 15:58, 22 August 2014 (UTC)[reply]

Hmm. That may be a feature, not a bug. I certainly hope that administrators feel a "chill" about adding unvetted code without discussion in appropriate technical forums (e.g. the applicable talk page) to the Mediawiki:Common.js. From the larger perspective, this would very much be a positive outcome of the case: the vast majority of admiistrators are unqualified to do this, and should be discouraged from doing so. Risker (talk) 17:00, 22 August 2014 (UTC)[reply]

That doesn't justify the methods used, Risker, and you know this. If the vast majority of admin are not qualified, then I'm not sure that is an Arb issue, since that is a matter for policy making, which Arb doesn't do. We are here because of a hissy fit and the abusive threatening of an admin/editor by an admin/WMF employee. Had that not happened and he just reverted and discussed politely, we would not be discussing it here before Arb. Instead, it would be at VP, slowly getting hashed out. All this other talk is just a diversion. Dennis Brown | 2¢ | WER 23:26, 22 August 2014 (UTC)[reply]

Sure, per conexcept and arbitration policy, arbcom has no authority in this matter. But the only thing 'hysterical', that is "hissy fit" like, is local admins, such as yourself, calling this generally "abusive threatening" and making an Arbcom case out of it. First, the comment itself, even if one views it as overreaction, is not hysterically phrased: it is 'if this, than that.' Second, it occurred in a very limited and specialized context, edits to the software common that were "ill-informed, and at worst negligent", thus there is no "threat" to admins that can be generalized as you do. Third, it "was insignificant, and doesn't demand any kind of strong reaction," according to the person it was said to. So, the 'hysteria', if any, is in your part. Alanscottwalker (talk) 13:38, 24 August 2014 (UTC)[reply]

Wikimedia Foundation staff

Identifying WMF staff accounts on the English Wikipedia

Wikimedia Foundation staff and contractors with accounts on the English Wikipedia are usually identified in the following ways: (i) account with "(WMF)" in the name; (ii) user page stating that they work for the WMF and including a disclaimer (e.g. Template:User info); (iii) user page included in Category:Wikimedia Foundation staff. However, of the 43 accounts with 'staff' rights: sixteen (16) accounts do not have "WMF" in the account name; several accounts are not in Category:Wikimedia Foundation staff; and at least one account lacks a user page and associated disclaimer. It is possible that similar inconsistencies exist for other WMF staff accounts (those without the 'staff' permissions).

Comment by Arbitrators:

Comment by parties:

Comment by others:

Some thoughts: We do not require that any enwiki administrator, bureaucrat, checkuser, oversighter, template editor, reviewer, edit filter manager, or person with any user rights identify their rights on their userpage. As well, you do not clarify why such an expectation should be project-specific when you are talking about global user rights.

I'm the first to agree with the separation of accounts (despite the greater-than-usual difficulties in switching accounts, and the strong emotional attachment that most users have with respect to their username), but one needs to keep in mind that some of the applicable accounts are essentially impossible to SUL at this point, and thus are not eligible for global rename. Staff work on hundreds of wikis, not just enwiki. A global perspective is required here. Risker (talk) 10:22, 4 August 2014 (UTC)[reply]

Risker: so far as I know, SUL finalization is scheduled to occur as soon as a month from now. True, it's been put off for more than a year, and well it should have been because last I read the default forced usernames were truly awful - they even had tildes in them - and it would have made more sense to intensively push users to rename and SUL their accounts on their own first. But... as this is another feature the WMF supports, why shouldn't they lead by example and be the first to get their SUL ducks in a row and have every single account properly globalized? Wnt (talk) 19:45, 4 August 2014 (UTC)[reply]

That's when the software is due to be drafted, Wnt. However, the discussion of hierarchies of who gets the right to usernames, plus the discussion of what names to move accounts to, has yet to take place; all the stuff that was suggested before is not in place and is not enforceable. While some staff accounts may be fairly simple to unify and then rename to a "WMF" username, some are apparently quite complex and will require negotiation in a few different places. (I've not personally looked into it, but I'm aware some of the staff couldn't SUL before.) I'll just say it's not only appropriate but very important that a tool that will affect only registered users, and registered users potentially from every WMF project, should be the subject of extended and vigorous discussion; while I don't think there's much question as to the value, I think we can all recognise how personal usernames are, and that forcing someone to change usernames against their will (in deference to some other user who may never have edited their project or even projects in their language) is going to take some pretty significant diplomacy. Given recent history, I'm sure you'd agree it is not something that should be rushed, and that there should specifically be outreach to the people who will be most directly affected. Risker (talk) 22:53, 4 August 2014 (UTC)[reply]

Well, come to think of it.... the official accounts ought to end in '(WMF)'. Presumably any other account by anyone on any Wiki that ends '(WMF)' would be, at least, discouraged. This would seem to suggest that no matter how many unofficial names a person from WMF with no official role account may have, there will always be a vacant spot for old_username + ' (WMF)', and for their_real_name + ' (WMF)'. So SULing the official role accounts should not be a problem, and that gives two good reasons to start those accounts. Wnt (talk) 23:35, 4 August 2014 (UTC)[reply]

There are quite a few people who have staff accounts that don't follow the current naming pattern (some of whom have commented on this RFAR). Their accounts need to be SUL'd then renamed in order to properly keep their history intact. Risker (talk)`

Holders of WMF staff permissions

As of 23 July 2014, there are 43 accounts on the English Wikipedia with global staff permissions (list at meta; list at en-WP). These include Erik Moeller/Eloquence (part of the initial batch created on 5 September 2008), and Fabrice Florin (added on 13 March 2012 and transferred to the WMF account on 25 September 2012). No user page documentation or category system exists to identify the subset of WMF staff members that have global staff permissions.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Just a note if it was not seen (it doesn't look like it's currently linked from anywhere obvious) on Meta there is a page for all users who have staff permissions (or other rights given out by LCA). The global sysadmin right is given out by engineering as they need. Obviously you may be more specifically thinking about on enWiki so this may not be relevant to your point. Jalexander--WMF 06:14, 4 August 2014 (UTC)[reply]

Local rights (User:Eloquence)

The User:Eloquence account is used by Erik Moeller for both his WMF role and his actions and edits as a member of the English Wikipedia community. In the latter role, the account has local rights (en-WP rights log). These include local administrator rights, granted in January 2003 following correspondence on the wiki-en-l mailing list according to the standards operating at that time (request; response).

Comment by Arbitrators:

Comment by parties:

Comment by others:

User:Eloquence's administrator right was removed on user request 18 August 2014. –xeno^talk 20:33, 18 August 2014 (UTC)[reply]

Revert at MediaWiki:Common.js

The edit made by Erik Moeller/Eloquence at MediaWiki:Common.js failed to use the edit summary to identify whether he was acting in his WMF role. Although his subsequent user talk page edit did identify the revert as "a WMF action", this subsequent user talk page edit would not have been apparent to anyone looking at the common.js page history or reviewing the revert on a watchlist.

Comment by Arbitrators:

In light of the proposed principle that "It is not acceptable for those with unlabelled accounts to make edits elsewhere to retrospectively apply WMF status to an earlier action", I would simply say that to the extent the edit on Peteforsyth's talk page attempts to label the Common.js edit a "WMF action", such an attempt has no effect as far as arbcom is concerned. T. Canens (talk) 04:08, 5 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Sorry to repeat myself but the issue appears more than once User:Eloquence states explicitly, and has done for months, that Unless otherwise stated, any edit to Wikimedia projects by myself is an act of a regular member of the community and administrator, not a legal or official action. His edit [34] of 20:06, 10 July did not state that it was an official or legal action and therefore, by his own declaration, was made in his personal capacity as a member of the community. On the other hand, his edit [35] of 20:07, 10 July threatening to desysop Peter Forsyth, did state, following the threat, This is a WMF action. -- not was, but is. We conclude that the change to the site javascript was a personal action but the threat to desysop was a WMF action. Deltahedron (talk) 19:30, 15 August 2014 (UTC)[reply]

Your parsing of "is" is absurd, and see my response and questions when you first said this. Alanscottwalker (talk) 21:11, 15 August 2014 (UTC)[reply]

Documentation relating to WMF staff rights

On the English Wikipedia, the global Wikimedia Foundation staff rights are documented at the Wikipedia:Global rights policy, which refers to global checkuser, global adminship and global oversight rights, as well as office actions related to defamation, privacy violations or copyright infringement (these are dealt with by the WMF's Legal and Community Advocacy team). There is no reference to the use of staff rights by WMF developers or members of the Engineering team.

At the meta-wiki, pages documenting the WMF staff rights include Special global permissions and User groups. The former page (Special global permissions) refers to employees of the Foundation with both the need for rights beyond those of normal users on a global scale and the technical ability to use them. The latter page (User groups) details the checks and balances built into the system. These include evaluation and review of actions, and internal recording of the rationale and responsibility for these advanced permissions, with an incomplete chart listing the permissions available to staff and why they are needed.

Comment by Arbitrators:

Comment by parties:

Comment by others:

• I believe that it needs to be made explicit whether the Wikimedia Foundation staff, in situation which does not pertain to a legal, privacy, security, or stability threat, has the authority to override the community's determination of what should be in common.js. This may need to be a matter of discussion between the Arbitration Committee and the WMF Board of Trustees. I think it is very important to include the community's and Arbitration Committee's position on jurisdiction over commons.js and other non-critical site features such as VisualEditor and Flow in the conclusions to this case. Without such clarification we may have further constitutional conflicts in the future. --Pine^✉ 04:07, 4 August 2014 (UTC)[reply]

Absolutely they do. Bad code is bad code, and has no place on a major website. You've neglected to include performance issues, adverse effects to readers (as opposed to the editors and admins who seem to think they own the site), and code that has been inserted without proper review and discussion. Whether or not the RFC close was appropriate does not mean that the code itself was appropriate. Risker (talk) 10:11, 4 August 2014 (UTC)[reply]

@Risker:

• I believe that the community would have reverted Pete's action if Eloquence had not done so. I think everyone agrees that the insertion was improper.
• I think the community would swiftly revert a community-originated change that had a significant negative impact on performance.
• The community has no interest in alienating our readers, and many of us would like to convert readers into editors. I do not believe that we would intentionally introduce a change that had a major negative effect on our readers, and if we did we would revert it.
• "Code that has been inserted without proper review and discussion" could arguably include WMF code. In general the approach of the community is that we permit WMF to be bold in making feature changes but we reserve the right to revert them. If the community inserted code "without proper review and discussion" and there was dispute within the community about the new code I expect we would revert the change quickly if there were major negative impacts.
• In general, I have faith that community consensus, when it is established, should be followed. Wikipedia's nature supports "the wisdom of the crowds" which includes decision-making through consensus. --Pine^✉ 19:27, 4 August 2014 (UTC)[reply]

I'm sorry, Pine, but I do not actually care if someone from the community eventually got around to undoing what was clearly an improper edit. And I genuinely believe that any admin who did so ran a very serious risk of getting himself or herself involved in an edit war. It had every earmark of being a 'true believer' issue rather than a practical one. I also disagree with you about alienating readers; there is a significant segment of the community (unfortunately one that includes a lot of administrators and longtime editors) who place "community rights" over and above benefit for readers. Whether or not that group want to admit it, Media Viewer is a lot closer to what readers want than being taken to a weird page that is full of all kinds of information that's irrelevant to 99.8% of readers (just like the history page of an article is). And there's a problem with your theory of community consensus, in that it seems you believe it only occurs in RFCs. That's patently wrong, and always has been. RFCs are only one method of determining consensus. The fact that somewhere between 9000 and 14,000 editors *chose* to enable Media Viewer before it became default is also a consensus, one that far, far outweighed the number of editors who participated in the RFC, let alone the even tinier number who supported removing the default. (At the time of the switch, there were approximately 5000 users who had selected "all beta testing" - even if all of them are discounted, that still leaves 9000 editors who chose to enable MV.) Risker (talk) 23:10, 4 August 2014 (UTC)[reply]

• I do care "if someone from the community eventually got around to undoing what was clearly an improper edit" and I believe that we would have done so quickly. WMF intervention was neither necessary or prudent, and certainly escalated a nuisance into a constitutional crisis. If WMF had not involved itself so forcefully I doubt we would all be spending our time in this arbitration case. In response to your other point that "RFCs are only one method of determining consensus", I agree, but readers who are not registered editors do not make policy. The policy on consensus is here which says that "Consensus refers to the primary way decisions are made on Wikipedia, and it is accepted as the best method to achieve our goals..." and that consensus may be determined several ways, none of which involve looking at the number of editors who have enabled or disabled particular features. Even if non-RfC statistics provided were used for determining consensus, the validity of at least some information provided by WMF is in dispute 1 2 3. Not that it matters to this arbitration case, but from a management standpoint WMF would have conserved a lot of resources by respecting the RfC, disabling MediaViewer by default while problems pointed out in the RfC were addressed, and then asking the community for permission to re-enable MediaViewer by default. Why WMF chose to be confrontational, I wish I knew. Sigh. --Pine^✉ 06:47, 6 August 2014 (UTC)[reply]

The escalation was the insertion of bad code, after the WMF on June 18 expressly said that the default was its decision. Alanscottwalker (talk) 13:15, 6 August 2014 (UTC)[reply]

• A decision that could, and should, have been reversed when the RfC was over and the results of WMF's own poll were known, where a majority of users considered that MV was not useful. I fully agree with Pine that the situation of confrontation was created by WMF. I said it before and say it again: the present heavy clouds in the sky would disappear as if by magic if the thing were disabled as a default. As a sign of good faith. Only then could we start a fruitful conversation which seems impossible right now. The reason for WMF's stuborness is hard to understand and to accept. Alvesgaspar (talk) 18:04, 6 August 2014 (UTC)[reply]

No, it's not. They make decisions about software, all the time, and made changes here to this software based on the feedback. Your refusing to even try to understand or accept, is what's stubborn and unfruitful. Alanscottwalker (talk) 12:15, 7 August 2014 (UTC)[reply]

• I'm an unimportant piece in this conflict. My incapacity of understanding WMF's reasons is irrelevant and doesn't deserve a comment. What is important is the colective feeling of the editor's community. So far, I see no positive response to the attempts of WMF to resume discussion. That is a disturbing sign that this committe should take into consideration. Repeating a falsity ad nauseum (e.g. your "based on the feedback") doesn't make it true. Alvesgaspar (talk) 17:31, 7 August 2014 (UTC)[reply]

The evidence on the evidence page, already shows there is nothing false about it. So, making your claims without evidence can only demonstrate baseless "feeling" and baseless feeling is not going to lead to anything fruitful. Alanscottwalker (talk) 17:43, 7 August 2014 (UTC)[reply]

I believe that there are multiple other pages that refer to the use of staff rights, but they are workplace policies that are not public. (This is appropriate - very few organizations publish their workplace policies, particularly if they refer to the potential for disciplinary action.) I note that nobody has actually asked that question, so there is no reasonable way for the committee to comment on this, nor does the committee have a place in determining workplace policy for the WMF. Risker (talk) 10:15, 4 August 2014 (UTC)[reply]

• The last I heard is that the WMF Employee Handbook is being prepared for publication. If there were problems with staff misusing permissions that WMF says that they have I expect that the community or the WMF Board would notice and do something about it. In general it is in WMF's interest to get along with the community, and in my experience they generally make good faith efforts to do so. --Pine^✉ 19:27, 4 August 2014 (UTC)[reply]

The Board has absolutely nothing to do with the hiring, firing, discipline or policies applied to staff with the exception of the Executive Director. It is up to the WMF management team to address these issues. I'm rather shocked that you don't seem to be aware of this. Risker (talk) 23:10, 4 August 2014 (UTC)[reply]

• First, I was not suggesting that there has been frequent misuse of unpublicized staff rights. Second, in the US the trustees of every foundation in every state that I know about have final authority in all matters except as limited by law; in other words, the Executive Director has only the authority that the Board decides to delegate to him or her, and all other authority is retained by the board. The board can take any lawful action regarding employees, and certainly can take action without the consent of the Executive Director. In practice boards usually limit themselves to fundraising and high-level strategy while delegating the rest of the responsibilities to the Executive Director or equivalent, but the board can get more involved as it sees fit. Also, boards routinely create personnel policies that apply to groups or all of an organization's employees such as WMF's Delegations of Financial and Spending Authority policy. Returning to the original point, I hope that the Employee Handbook helps with transparency of these matters. --Pine^✉ 06:47, 6 August 2014 (UTC)[reply]

The executive authority (ie., the authority to execute) is delegated by the board to executive staff and operational policy (its creation and maintenance) is included in that delegation. Alanscottwalker (talk) 13:07, 6 August 2014 (UTC)[reply]

Conclusions

A number of methods are used to identify accounts held by WMF staff members on the English Wikipedia. However, these methods are inconsistent, particularly with regard to the use of "(WMF)" in the account name. A dynamic log exists to identify that subset of WMF staff members that hold the global staff rights permissions, and the rights history is documented in the logs at the meta-wiki, but there is no corresponding user page documentation, category system, or history on the English Wikipedia of who held or holds these rights. Some of the accounts held by WMF staff members are also their local community accounts, and some of these accounts have local rights. This bundling of local and WMF roles into one account can potentially cause confusion. This applies particularly to those bundled accounts likely to take formal actions on behalf of the WMF. The documentation on the English Wikipedia and at the meta-wiki relating to staff global rights appears to need updating.

Comment by Arbitrators:

Comment by parties:

Comment by others:

• Draft being finalised. Carcharoth (talk) 16:51, 2 August 2014 (UTC)[reply]
• 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:

Note: These proposals are offered for consideration and comment by the drafting arbitrators and others. They do not address all the issues in the case or all the issues that might be included in the decision.

Proposed principles

Role of the Wikimedia Foundation and the community

1) (A) Wikimedia projects, including the English Wikipedia, are supported by both the Wikimedia Foundation (WMF) and their user communities.

(B) In general terms, the WMF through its professional staff provides the physical infrastructure, financial backing, technical platform, and administrative support necessary for English Wikipedia and other projects to exist, to grow, and to meet the needs of their contributors and readers.

(C) In general terms, the English Wikipedia user community creates the substantive content of the encyclopedia and is also responsible for creating and enforcing most policies governing the encyclopedia and the community, and for making most decisions governing the website.

(D) Over the years, both the WMF and the community have generally supported an allocation of responsibility under which most decision-making, apart from financial and legal matters, is handled by the user community rather than the WMF unless there is a specific reason that a given decision should be made at the WMF level.

(E) The demarkation of responsibilities and decision-making between the WMF and the community has been clear for most practical purposes, but there have been exceptions. One exceptional area in which the WMF's and the community's roles have come into tension has concerned decision-making concerning proposed new software changes, with the WMF and at least some community members asserting conflicting claims of decision-making authority.

(F) The WMF is physically able to override community decision-making regarding software changes, but by doing so it runs the risk of creating significant ill-will and demoralizing contributors. Conversely, the community can sometimes block implementation of what the WMF staff considers improvements, but only at the risk of confrontation and losing the benefit of what can be enormous investments of staff time and hence of Foundation (and ultimately community donors') funds.

(G) The WMF and the community must, as a priority, collaborate and work together with respect to software changes in a fashion that defines common goals and objectives and promotes shared decision-making concerning the development, testing, adoption, and implementation of software changes, thereby minimizing any instances in which the views of the WMF Office/developers and the community consensus come into conflict.

Comment by Arbitrators:

Basic thoughts for the drafters' consideration. Not as well-honed as something I post on this page might ordinarily be, but I want to get some things on the screen after thinking through this case for the past couple of weeks. This wording can surely be improved upon at multiple levels. There are lots of nuances not (yet) addressed here, such as (1) whether certain specific, extreme user-conduct issues should be dealt with by the Office; (2) the fact the community consensus may itself not be clear, even before the WMF takes a view; and (3) whether the allocation of responsibility between the WMF and English Wikipedia must parallel the allocation between the WMF and smaller projects with smaller project communities. In other words, this is very much a work in progress, but here it is for what it's worth. Newyorkbrad (talk) 23:49, 7 August 2014 (UTC)[reply]

Thanks for this. I think more emphasis needs to be given to the way in which software/engineering matters are handled (there has always been a huge amount of that taking place within the separate domain of Wikimedia developers that the vast majority of the editing community has been unaware of and not noticed precisely because it works so well). There also need to be much more attention paid to the global perspective. It is incredibly easy on a single local project to lose sight of the bigger picture. Those who work on Wikimedia-wide matters (and this is a Wikimedia-wide matter) take that global perspective (it is easier to say that after attending an opening ceremony where people were present from 68 countries). Those on the English Wikipedia need to recognise that. You say 'shared decision-making' - that is a noble objective, but how do you implement shared decision-making across hundreds of Wikimedia projects and different languages? Alanscottwalker made the point above about maintaining a consistent look and brand across the Wikimedia sites. How do you do that when local decision making risks seeing the software and features fragment across the userbases? It is possible there are no easy answers here. The closest thing to a shared decision-making process was the (extensive) discussions over at the Mediawiki talk page on Media Viewer. Possibly the mistake was creating a local discussion page here without making clear that the real discussions were taking place over at the Mediawiki wiki, but how do you get people to comment there ahead of the launch of such a feature (which wasn't launched at the same time on all projects)? A local site-wide or watchlist notice urging people to join the discussion at Mediawiki? Or a local RfC as occurred here? Carcharoth (talk) 08:27, 8 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

A good start, but it really shouldn't be that complicated:

• WMF controls the software.
• Community controls context, including certain customizations of that software.
• There is an ambiguous gray area between "customizing" and "breaking" WMF software.
• When misunderstandings occur, folks (WMF and en-WP) really ought to act like grownups and calmly discuss / resolve the misunderstanding.

What's actually important is that a) Erik wasn't trying to act like an ass, he reacted / responded too quickly. b) Pete wasn't trying to be "uppity" and defy WMF or anything. NE Ent 01:18, 8 August 2014 (UTC)[reply]

Template

2) {text of Proposed principle}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed findings of fact

The WMF, the community, and software changes

1) There has been a series of instances in recent years in which the desirability of software and feature changes— including the introduction of new or substantially modified features or changes to the "look and feel" of Wikipedia pages and features—has been the subject of strong disagreement between the WMF-employed or WMF-contracted developers and the (actual or arguable) consensus of English Wikipedia community members expressing a view on the subject. These disagreements have been resolved through ad hoc methods that have engendered bitterness among both groups and have not necessarily resulted in optimal decision-making for the benefit of the project's contributors and readers.

Comment by Arbitrators:

Proposed. Again, this needs work, but the point is made. Newyorkbrad (talk) 23:54, 7 August 2014 (UTC)[reply]

Thanks for this, NYB. This is similar to the point I made recently here, and one of my intentions had been to add a finding similar to this. One of the things that needs work is the vagueness. You don't actually name any of the instances, and this vagueness has the unfortunate effect of casting aspersions on all the software and feature changes carried out by the WMF, some of which have not caused disagreement. Maybe add an "examples include..." clause? Others (higher up this workshop) have specifically named instances already, see here for one example. Might it be best to merge these efforts in some way? Carcharoth (talk) 07:52, 8 August 2014 (UTC)[reply]

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.

Protocol regarding high-impact software and technical changes

1) The WMF (including senior staff and developers) and the English Wikipedia community (and, as interested, other project communities) are strongly urged, as a matter of priority, to develop a protocol for collaboration and cooperative decision-making concerning high-impact software and technical changes and new or modified features (collectively referred to below as "Software Changes") that may substantially affect the Wikipedia experience for editors and readers, including the following:

(placeholder: see below). Newyorkbrad (talk) 00:19, 8 August 2014 (UTC)[reply]

Comment by Arbitrators:

This for me is the absolute crux of the case. I am still honing the words of "the following," which I'll post tomorrow; comments on what it should include are welcome. Newyorkbrad (talk) 00:19, 8 August 2014 (UTC)[reply]

Comment by parties:

Comment by others:

Even unfinished, these are incredibly smart and thoughtful posts (all three). Thank you for taking the time to write them. --MZMcBride (talk) 00:53, 8 August 2014 (UTC)[reply]

Template

2) {text of proposed remedy}

Comment by Arbitrators:

Comment by parties:

Comment by others:

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:

Preamble: To demonstrate to certain users that ArbCom can take an affirmative action as the penultimate stand in for the voice of the community I reserve the right to add principles/findings of fact/remedies that clearly have a "Go forth and improve the encyclopedia and our relationship with the foundation" type bend. Hasteur (talk) 18:30, 25 August 2014 (UTC)[reply]

Proposed Principles

Proposed Findings of Fact

Proposed Remedies

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:

Comment by Arbitrators:

Noting here that I've started a discussion section here on the workshop talk page. That is intended for brief statements. Full drafts and discussion should still take place on the workshop page as normal. Carcharoth (talk) 06:49, 7 August 2014 (UTC)[reply]

Comment by parties:

Comment by others: