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 Conflict of interest reports
Audit Talk Statistics Talk Reports (pre-2016)
Track related changes

Behaviour on this page: Arbitration case pages exist to assist the Arbitration Committee in arriving at a fair, well-informed decision. 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 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. Personal attacks against other users, including arbitrators or clerks, will be met with sanctions. Behavior during a case may also be considered by the committee in arriving at a final decision.

Arbcom: Thanks for stepping up and getting this started. These conflicts with lopsided RfCs on one side and Foundation staff on the other side are happening often enough that we clearly need some combination of effective mediation and cluesticks, and that's clearly in your remit. When I'm closing future RfCs, I'll be looking to your rulings for guidance. I hope I'm wrong, but I see a real possibility of similar issues resurfacing in or after some future RfC on Pending Changes Level 2, for instance. - Dank (push to talk) 13:30, 19 July 2014 (UTC)[reply]

P.S. ... and sooner than I thought. I'm back in as a closer for the upcoming RfC on COI and paid editing (discussion at WT:COI#RFC), mostly because I'm counting on this case to handle questions involving the Foundation and RfCs that would have been above my paygrade to tackle. - Dank (push to talk) 15:20, 19 July 2014 (UTC)[reply]

Thanks for your note. I'll draw it to the attention of the rest of the committee. My view is that at the core of this particular dispute is the issue of communication (both ways) between WMF staff and/or developers and the (somewhat changing) portion of the en-Wikipedia community that comment on any particular issue (plus how consensus is generated in an environment like en-Wikipedia). It will be difficult for ArbCom to address this directly. At most we can issue guidance, but any impetus for improved dialogue will have to come from community and WMF processes. I'm assuming that the RfC you point to at the COI policy talk page is intended to end with a result to communicate to someone - who would it be communicated to? And having now read the discussion so far over there, I see that the proposal there is to have an RfC 'to determine alternative disclosure policies [regarding COI]' and that some are saying that this was encouraged by the Foundation. My advice would be to proceed with an RfC as normal, providing agreement can be reached on what should be asked, and at what level to publicise it at. The key is to make the existence of the RfC known to those it will affect so they can participate in the discussion if they wish to do so. Several years ago I started the page Wikipedia:Publicising discussions. I'm not sure how widely the existence of that page is known, but the advice there may be useful. Carcharoth (talk) 18:41, 19 July 2014 (UTC)[reply]

People have talked about a site notice for logged-in users, and mentioned advertising it widely. Your page is helpful, thanks. The RfC is intended as a response to the terms of use provision that says that projects can adopt an alternative policy if it gains consensus, so I guess it would be addressed to whoever at the Foundation deals with that. - Dank (push to talk) 19:10, 19 July 2014 (UTC)[reply]

Carcharoth wrote: The following notice is to be included on the case pages:

"When submitting evidence, please bear in mind that the locus of the dispute is the Media Viewer request for comments (RfC), and the actions that followed the RfC. If your evidence is outside this scope, please include supporting statements or background context to explain the relevance to the case. If an extension of evidence lengths is needed, please ask one of the drafting arbitrators."

Well, that doesn't appear to have been included in the case pages. And that's terribly nonspecific, since I don't think that anything that was presented in the case request didn't more or less fall into the inclusions stated. In order to look at actions, one must look at policies and practices that informed said actions. So what do you want to talk about, and what are you trying to exclude here? Possible examples:

• The development, posting and advertising of the RFC
• The manner in which the RFC was conducted (including any relevant user behaviours)
• The assessment of consensus and closing of the RFC
• How binding an RFC close is
• Balancing RFC consensus against factors that cannot be accommodated in the RFC format (e.g., user preferences, effects on readers)
• The general principles, policies and practices of managing RFCs that have broad effect
• The creation and description of a specific code to modify the mediawiki.common.js
• The application of the specific code to modify the mediawiki.common.js
• The general principles of modifying the mediawiki.common.js
• Outdated practices, policies and user rights
• The principles behind WP:CONEXCEPT
• The use of WP:CONEXCEPT
• The principles behind WP:OFFICE
• The principle of least restriction in preventing harm to the project
• The application of the consensus policy, including the principle that consensus can change
• The actions and activities of specific users (by name or as a group):
  • RFC initiator
  • RFC participants (one or more specific participants)
  • RFC closer
  • Developer/code writer
  • Administrator applying code
  • WMF Director reversing code
  • Other participants
    • Registered and unregistered users involved in the RFC
    • WMF staff
    • Administrators
    • Volunteer developers
  • Editors and administrators participating in the case request
• WMF staff permissions
• Global vs local user rights/permissions

Okay, so that's the list I came up with in about 4 minutes. Which ones are you interested in and not interested in hearing about? Risker (talk) 03:06, 20 July 2014 (UTC)[reply]

Thanks for this, Risker. We (mainly the drafters, but some other arbs as well) have been discussing some aspects of this over the past few days. I had intended to get some notes up here in public to help guide those presenting evidence, but hadn't quite got to that stage yet. I am going to copy over some of my notes (some of which cover similar points to the ones you raised). I do also want to ask direct questions of some of those who took actions, but am holding off on that until it is clear what the most relevant questions would be (also, some of the questions might get answered as the evidence is presented). Some of these notes I am about to put up would also be more relevant to the workshop page, so I may copy some of them over there (that is the best place to discuss principles, for example). I also have a rudimentary timeline developed, so it is clear what happened when (with diffs). If I copy that over as well, it would be simple for that to be added to as needed so the core facts are agreed on. About the statement from me that you quote above, as far as I can tell it has been included in the preamble to the evidence and workshop pages. Not terribly visible, but it is there. The main reason for that scope statement was to (in the absence of good reasons given) exclude observations regarding the rollout of other features, which could lead quite quickly to a very sprawling case. Carcharoth (talk) 09:38, 20 July 2014 (UTC)[reply]

Following up with some specifics here: I personally would consider all the above to be admissible if presented with supporting statements that made clear how they related to this RfC and the actions taken around it. I would be particularly interested in what you have to say about volunteer developers (how do you identify these - by following Bugzilla or wikitech-l?). How to identify accounts with WMF staff permissions would be useful. Looking on meta for global rights (is that similar to stewards?) was mentioned. Is there a difference between global rights and WMF staff permissions? Outdated practices, policies and user rights sounds like something better discussed on the workshop page in the context of principles. And a close-up look at the behaviour of those who participated in the RfC would be admissible. On the subject of the advertising of the RfC, I pointed Dank above to the page Wikipedia:Publicising discussions. How to get adequate participation on en-Wikipedia to gather consensus for various issues and to demonstrate that there has been adequate participation has been a perennial issue. That might be usefully discussed on the workshop page in the context of evidence about how it was handled here. Carcharoth (talk) 11:07, 20 July 2014 (UTC)[reply]

My opinion is that the true focus of this case is a two-edit edit war at MediaWiki:Common.js. It resulted from the RfC and so is part of the broader defined focus, yes, but in the end resolving this is what matters. And resolving it is hindered by the fact that in these two edits so far no one has actually filed or even proposed the precise version we want, i.e. one which leaves Media Viewer off by default but makes it simple to turn it on. But reaching a 'right version' of this page well supported by community consensus is how we define victory here. Note that imposing sanctions, real or imagined, on either party is not useful toward achieving victory. Wnt (talk) 18:33, 20 July 2014 (UTC)[reply]

• I wouldn't say that the focus of this case is the two-edit edit war at MediaWiki:Common.js. Those are only symptons of a much bigger issue, which is the behaviour of WMF and its relationship with the community. -- Alvesgaspar (talk) 19:07, 20 July 2014 (UTC)[reply]

• It is not a symptom of anything. That issue is a result of an administrator adding code to a global javascript page without knowing what it does and as a result, broke a feature of the whole wiki and forced a choice on the community. How the Foundation acted with that edit is beyond reasonable. John F. Lewis (talk) 19:09, 20 July 2014 (UTC)[reply]

Well, the first step is to figure out what edit would accomplish the community's desires correctly. There are two entirely separate issues being raised here - one is whether the admin should have been expected to know that his edit wouldn't work quite right, and the other being whether we are going to have a problem getting through the correct edit to Common.js to make the Media Viewer disabled by default. We should try our best to very strictly separate these two issues so that they can be resolved more easily. However, to me the first issue doesn't seem like much of an issue - he made a good faith error, was reverted, was beaten half to death with a wet fish, and we can move on. Wnt (talk) 19:40, 20 July 2014 (UTC)[reply]

There is no correct edit to common.js. The change in question should be made in the configuration files not on wiki. John F. Lewis (talk) 19:42, 20 July 2014 (UTC)[reply]

Are you talking about something in mw:Manual:Configuration settings or something else? I don't see precisely what is desired in mw:Extension:MultimediaViewer, though I would hazard a guess setting $wgMediaViewerIsInBeta to true should be useful. Nonetheless ... whatever tools are available on wiki should be used on wiki to the best possible effect for the encyclopedia, i.e. if there were some problem getting the configuration setting the way we want, it is not inappropriate for us to change any file we have access to to get a working substitute. Wnt (talk) 19:53, 20 July 2014 (UTC)[reply]

I am talking about $wgDefaultUserOptions really. And yes, there is a problem with the community making javascript hacks to get around a technical decision made by the Wikimedia Foundation. In theory, allowing administrators to edit MediaWiki:common.js and MediaWiki:common.css is a privilege not a right. If they community wishes to abuse such editing privileges, as we do with block users - it can be revoked until a time when communities accept technical changes need to be technical changes not a javascript hack. John F. Lewis (talk) 19:59, 20 July 2014 (UTC)[reply]

Well, here we're getting into the core ideology, so I think this is a very productive conversation. The problem is that as I see it, this is the English Wikipedia. The community, as a whole, is the only reason why there's anything here - any images, any text, any Common.js settings. Now you're telling me that editing these two pages is a "privilege not a right", and I'm really scratching my head. Is editing the Main Page a privilege not a right? How about the settings for page notices? I was under the impression that, as a community, it was our task to use this software as we see fit to accomplish our end.

If the people making MediaWiki felt it was so integral to their software to have MediaViewer that nobody should ever be able to disable it, they'd not have made it an extension but part of their core software, and there wouldn't be any option there. But they didn't because they know people want the option, and we're opting. Wnt (talk) 20:06, 20 July 2014 (UTC)[reply]

Yes; editing both those pages is a privilege as it provides control over some interesting aspects of the core. The Main Page is a page like any other, the interface messages a page like any other, the common js and css pages are a page like no other as they control settings for all users and make a user's opt-out of a js/css feature complex. This extension is provided by the multimedia engineering team at the Wikimedia Foundation, not the core-engineering team or the volunteer. The multimedia engineering team developed this feature to improve user readability/interactions and so it did and they implemented an opt-out feature as they know not everyone will like it. We have an opt-in feature with an opt-out feature built in. We've opted-in because of no opposition when it was opt-in, but the minute it becomes opt-out, all hells breaks loose. Why? Because the community just like picking fights with no real outcome or reason to. In the time it has taken us to decide on an RfC and finish an ArbCom case will be what, around 2 months? When it takes 5 seconds to press opt-out. The community needs to learn, the process-route is not always the simple route. Press opt-out instead of arguing. It works. John F. Lewis (talk) 20:13, 20 July 2014 (UTC)[reply]

We're not going to avoid "process" if we don't know who has the right to do what and how disagreements are settled. You're laying claim to two pages on behalf of a multimedia engineering team. I assume they're also claiming some (all?) of the $wg variables. Now I should admit I see some argument there because Common.js could be badly abused in unique ways; nonetheless we should make sure that if we decide to hand over this Crimea that the argument doesn't continue to spill out onto additional pages. We have to know what pages the community is tasked with controlling and what they're not, so we don't find somebody from the multimedia team claiming a general trump over us and coming in and telling us how to decide on the Muhammad images or something. Furthermore at least I don't feel like we know enough about the multimedia team, who they are, what they do, and who gives them their orders when it comes to decisions like this; I don't think I was picturing any middlemen between us and MediaWiki. Wikipedia is full, alas, of little private fiefdoms, and while nobody much likes that it is easier for us to tolerate when we know they won't be coming to invade other things we're interested in. Wnt (talk) 20:45, 20 July 2014 (UTC)[reply]

• @John F. Lewis: Because English is not my mother language I always try to be synthetic and precise in my statements. And when I wrote that the focus of this case is not the two-edit edit war between an administrator of en:WP and the WMF deputy director, I was convinced that such a statement was no more than a tautology. If that were not the case, and considering the fact that both editors involved acknowledged that they did wrong, the Arbcom members would never have accepted this case. It should be obvious by now (except maybe for you) that a serious conflict now exists between the community of editors and the MV team (not to say WMF). How do we solve the present problem, how to we learn from the mistakes made by both parts and how should we avoid similar conflicts in the future are the evident concerns for Arbcom. That I understood from the very beginning, despite my poor English and lack of verbosity. -- Alvesgaspar (talk) 21:39, 20 July 2014 (UTC)[reply]

Alvesgaspar, Arbcom took this case to shut down the discussion on their case request page. It will take them several months, but at the end of the day, there will be no change from the status quo ante except maybe Eloquence will be told to be nicer and Peteforsyth will be told to stay away from the common.js and common.css pages. Maybe. There will be no other useful result, because there is nothing else within Arbcom's scope. This case wasn't taken to produce a result, it was taken to quiet people down. It is quite possible that there is some quixotic belief amongst some arbitrators that something will actually come of it, but they're wildly mistaken. Risker (talk) 22:13, 20 July 2014 (UTC)[reply]

Ack, I hope that's not true, I don't think anyone (especially not me) wants to see me winging it if I have to deal with these issues during or after future RfCs. - Dank (push to talk) 22:20, 20 July 2014 (UTC)[reply]

• It's no use to try guessing what Arbcom will do. After all, they are just around the corner and we will know soon enough. But I will be very surprised if the only outcome will be an admoestation to Eloquence and Pete. That won't certainly add to the reputation of the committee. -- Alvesgaspar (talk) 23:10, 20 July 2014 (UTC)[reply]

There is no RFC policy, and Arbcom can't create one by fiat. The dispute resolution policy doesn't directly address the issues here, because the dispute at the core of the RFC is not about content or user behaviour; it's about political control of the project (whether some subset of the community or the WMF has control of common.js and common.css pages). And the DR policy cautions editors to [r]emember that dispute resolution mechanisms are ultimately there to enable editors to collaboratively write an encyclopedia – not to win personal or political battles. Risker (talk) 22:56, 20 July 2014 (UTC)[reply]

Dank, the principles related to RfCs that get proposed in the final decision may end up addressing your concerns. Risker, let's wait until the case is actually concluded before predicting the value of any final decision. It is rather hard to work on a case when someone (you) who didn't want a case accepted, looks set to comment throughout in the same vein and to be so cynical about the outcome. Carcharoth (talk) 23:13, 20 July 2014 (UTC)[reply]

Core issues:

• The locus of the dispute was a request for comments (RfC) held on en-Wikipedia on the Media Viewer extension coded and rolled out by a team of Mediawiki developers and managers at the Wikimedia Foundation (WMF).
• Underlying issues are of communication (both ways) between segments of the en-Wikipedia community and the WMF regarding various features provided by WMF developers (including the design, implementation and feedback mechanisms).

Outside case scope:

• The reception of Media Viewer on other WMF projects has been mentioned. This provides some context, but is ultimately outside the scope of an en-Wikipedia arbitration case.
• The history of the roll-out and reception of other Mediawiki features on en-Wikipedia has also been mentioned (e.g. Visual Editor, the Notifications system, Pending Changes, and the proposed Flow extension). Again, this would be outside the case scope, as the focus should be on the Media Viewer RfC.

Evidence that would be useful includes any that would help answer the following questions:

• What is the history of WP:CONEXCEPT?
• What is the history of having separate '(WMF)' accounts?
• What is the status of the common.js (and similar Mediawiki pages) and who should edit them and who can edit them?
• How do the WMF Engineering teams communicate with the projects they provide features for?
• How do the communities on en-Wikipedia gather consensus on issues and communicate with the WMF and its developers?
• If WMF staff members (using their global rights) carry out temporary desysops of administrators, do they pass them to a local ArbCom (if it exists) for review?
• How does the WMF handle complaints about the actions of those holding staff accounts?
• Was the RfC adequately advertised and planned? Was it a representative summary of the community's views?
• Was the close properly prepared and executed, and should the closure of such RfCs be performed by experienced administrators rather than non-administrators?
• Should the code proposed for use have been discussed further and warning given ahead of time as was done with the earlier situation involving Visual Editor?
• Is it acceptable for an administrator to add such code to the sitewide js without understanding what the code does?
• Does the WMF have a documented history of changes made to the Media Viewer extension?

Some aspects of this I've already been able to read up on and answer myself. The Mediawiki wiki pages here are useful: About Media Viewer, Media Viewer, and Release Plan. The release plan in particular links to 10 announcements made on en-Wikipedia. I presume there was some sitewide notice as well (how would this be confirmed?). Also useful for background context is Wikipedia:Media Viewer and Wikipedia talk:Media Viewer for a flavour of the discussions and changes that occurred before the June-July RfC. Focusing on the RfC itself, one thing I noticed on looking through the discussions was the presence of three other 'WMF' accounts as well as User:Fabrice Florin (WMF) (Product Manager, Wikimedia Foundation). In more recent discussions, these have been joined by User:Rdicerb (WMF), who is Rachel diCerbo (Director of Community Engagement (Product), Wikimedia Foundation). Clarification of the exact roles of various people here would be good (one of my colleagues has pointed me to the staff and contractors page on the WMF wiki, which was helpful). On the history of the common.js page, I've looked through that and have no idea how to identify who is a Mediawiki developer on that list. Anyway, I'll stop there for now and go back up to the section above and indicate what would be useful there. Carcharoth (talk) 10:41, 20 July 2014 (UTC)[reply]

• You seem to have mysteriously forgotten "Is it legitimate for WMF staff members to threaten administrators with temporary desysops, and if so, when, where and how?"  — Scott • talk 13:15, 20 July 2014 (UTC)[reply]

  Quite. This, to me (a powerless editor), seems to be one of the more important points of the case. Intothatdarkness 19:37, 21 July 2014 (UTC)[reply]

Carcharoth, answering those questions will take in the range of 150-250 words per question, and the vast majority of them are factual questions. It will also take a LOT of hours to answer those questions. Unless you are willing to (a) extend the word limit for those responding AND (b) extend the evidence phase to at least 3 weeks, you will not even come close to getting this information. What you implied was going to be an extremely narrowly focused case is actually an enormous case ranging through a very large number of topic areas - and Arbcom has no ability to control or manage most of those areas. Almost none of the points mentioned in this shopping list are within the realm of control of Arbcom, and some of them are so far away from your control that I'm almost wondering if this list is "stuff I'd like to know because I'm curious". ("Does the WMF have a documented history of changes made to the Media Viewer extension?" - what do you mean? The newsletters? The announcements? The technical data? The Mediawiki page? The changelogs? Media Viewer is constantly being changed, and has been for months, and those changes are all documented in some manner or other.) Risker (talk) 14:56, 20 July 2014 (UTC)[reply]

The evidence limits can be extended, but I would need to see an initial presentation of evidence first, followed by a request for an extension. As you say Media Viewer has been constantly changed for months, there is no point getting into the survey numbers or the exact details of the changes, so forget about that. The core area where evidence is needed is conduct during the RfC and afterwards (by editors, admins, developers and WMF staff). The rest is mainly getting answers to factual questions. We should be able to do that in the timescale given. Carcharoth (talk) 16:17, 20 July 2014 (UTC)[reply]

Carcharoth, I have responded to many of your questions and, as predicted, it was impossible to keep under the word limit. There is almost nothing in my evidence that is repeated elsewhere, and almost nothing that not a factual response to your questions. I've been dealing with power failures and storms all day, and will be traveling in the near future, so will have a hard time cutting it down; in fairness, since this is fresh evidence, I don't think it should be cut down. I hope you will accept the evidence as provided. I will try to get to the workshop if my power remains on. Risker (talk) 00:38, 28 July 2014 (UTC)[reply]

Thanks, Risker. There is no need to cut down what you have submitted. I'll let the clerks know that and I will also ask the clerks to extend the workshop page to the weekend, as there is a fair amount to discuss. Carcharoth (talk) 22:44, 28 July 2014 (UTC)[reply]

I have contributed a bit of evidence regarding the technical implementation of Media Viewer, staff conduct, validity etc. :) John F. Lewis (talk) 15:11, 20 July 2014 (UTC)[reply]

Thank-you. That is a useful start. Carcharoth (talk) 16:17, 20 July 2014 (UTC)[reply]

Thanks to those who have submitted evidence so far. This section is to provide an update and some additional links that may be useful, some links relating directly to the dispute, others more tangential to provide background information.

• List of those with staff rights as listed on meta (around 43) (these are the 'staff rights' sometimes referred to). The staff permissions are listed here. Is there a policy anywhere governing use of those staff rights?
• List of WMF staff and contractors (this helps get a handle on who is who at the WMF, plus official job titles).
• en-Wikipedia category of WMF staff accounts (131 as of today, though the main conclusion I came to from looking through that category is that it is not very useful and not that well maintained).
• John F. Lewis, there are additional links in the statement by Pine about where the RfC was advertised. It would be simplest to ask Pine where they advertised it, and where the RfC bot would have advertised it. Dates for when the centralised discussion notice was added and removed would add precision to the evidence.
• Additional evidence about what on-wiki processes were used to publicise and communicate about Media Viewer to the en-Wikpedia community before and after launch would be appreciated (bearing in mind that the launch itself publicised the existence of the extension). Was a site notice ever used or not, and how was the en-Wikipedia community alerted to ongoing changes to Media Viewer after the launch?

Later in the week, I'll be coming back to this page to review the evidence submitted. I also hope to have some drafts up over on the workshop and to comment on some of the proposals over there, as well as ask some specific questions to some of the case parties and others. Carcharoth (talk) 23:22, 21 July 2014 (UTC)[reply]

I am not liking the nasty tone of the evidence here. I didn't like John F. Lewis harping on that much about complete incompetence because of one mistake, when what I know really bugs him is that it was intended as an end run around the sysadmins' control of the configuration settings. And I definitely don't like Dennis Brown and Pedro calling for Eloquence's head over something that might plausibly be interpreted as defending the server from bad hacks. The fact is, we're dealing with top level people here who have all put in a lot to this project and I don't want any heads to roll here, not one. That's not what this is about. I know it may seem strange to ArbCom and watchers to suggest this ritual can go on without a blood sacrifice, but really, our faith is enough.

The sum of my fears here is that sysadmins or other devs might be getting the impression that they have a supervote over the community to decide what Wikipedia looks like. That is a minor issue with the Media Viewer, but it is very close to a Pandora's box of explosive issues that we do not want to let out. I don't want a situation where they feel they have the right to settle something like whether we display images of Muhammad, simply by writing up some "tool" that has the ability to hide them and decreeing that they have control over whether we use it, and threaten to desysop anyone who files a hack to disable it, then to block anyone who re-uploads the images with a different name, etc... We must keep power well dispersed because power over how a site like this is displayed is an asset with substantial monetary and propaganda value, and the more we concentrate it the more likely it is to be stolen. We've already heard of the incident of the French admin being forced to delete a page after a session with his country's spy agency, but being defeated by Wikipedia process. If ISIS threatens some random editors over Muhammad images they will get nothing but abuse and CC-licensed Koran burning videos for their trouble. But if there's one WMF employee in charge of that decision, we will never even know the decision to ban them was the result of them sending an image of somebody's spouse in cross-hairs. Really, democracy correlates with freedom. Honest.

The ideal outcome here should be a clearer assertion of community control over en.wp, but not heads rolling (or failing to roll due to WMF intervention, for that matter). We are only doing the devs a favor by demanding that their free software, like any other, actually be desirable in its marketplace. We are only doing them a favor by keeping contentious political decisions out of their hands. We mean them no ill will, and we hope that a clearer division of power will prevent any further discord. Wnt (talk) 17:12, 22 July 2014 (UTC)[reply]

Well, the fence is well demarcated. This case is about lines of code showing things in different format, and not about publishing or not publishing editorial content; the later, the WMF does not involve itself - except in legal cases, per DMCA, etc -- the former, the technical coding, it does. Alanscottwalker (talk) 18:19, 22 July 2014 (UTC)[reply]

The tone was set by Eloquence. We are where he brought us.--Cube lurker (talk) 18:39, 22 July 2014 (UTC)[reply]

I don't think anyone is suggesting that the foundation is about to start trying to control actual content. Aside from five or so office actions out of four million pages they don't really do that and my strong impression is that they don't want that to change. The core issues here as I see them are not about content but rather the software, the user rights of staff, and the division (or lack thereof) between staff member's personal accounts and official accounts. Beeblebrox (talk) 19:09, 22 July 2014 (UTC)[reply]

You're free to not like my "calling for his head" Wnt (note - elsewhere I have specifically said I don't want anyone losing a job - be careful with the implications of your rhetoric please). I'm also free to take issue with your absurd "might plausibly". Not, it wasn't plausible. The site wide ability of admins to edit bits of .js /css etc. might not be desirable - but that's not the conversation here. Eloquence stepped right over the line with his threats.

Eloquence has already and always made it clear his threat to desysop was a member of the community - see [1] and "Unless otherwise stated, any edit to Wikimedia projects by myself is an act of a regular member of the community and administrator". So basically you're flat out wrong. Pedro :  Chat  19:43, 22 July 2014 (UTC)[reply]

Your second paragraph is factually incorrect. [2] Alanscottwalker (talk) 20:46, 22 July 2014 (UTC)[reply]

Thank you Alan - I've clearly gone word blind. I was convinced there was no statement it was a WMF action. I should learn to recheck my diffs. I fully retract that part, and have struck it as above. Pedro :  Chat  21:11, 22 July 2014 (UTC)[reply]

@Pedro: You're right that I should have been less rhetorical; I don't think he should "lose his bit", and I have this sense that it's difficult to be a sysadmin yet not have something functionally equivalent to a bit, but I don't know, I don't have that kind of access. Where "might plausibly" is concerned, I'll admit it's a stretch, but avoiding sufficiently bad code is a sysadmin responsibility. If something about that edit were actually putting too much burden on the servers and degrading performance or corrupting the database, or if it somehow violated the TOS (for example, if it allowed a third-party site access to personal information) a sysadmin could threaten or indeed carry out his threat in order to defend the project, and I don't see that as something that can practically change. So we're really dancing on the head of a pin here looking for just the right division of power, and I imagine that after all sides make their cases we might see boundaries we didn't before. I just want them to be good ones. I hope there are more interchanges like the one above that smooth down the rough edges. Wnt (talk) 22:16, 22 July 2014 (UTC)[reply]

I agree we are really dancing on the head of a pin, and I respect your knowledge around the technical pieces here. I think this case is poor, because actually there should be two. 1) around the whole Media Viewer RFC and 2) To examine how a Steward thinks it's correct to threaten to use emergency global powers to desysop an WP:AGF action. To my mind (but apparently not to others) they are considerably different things. Pedro :  Chat  22:21, 22 July 2014 (UTC)[reply]

This is why I've limited my argument to an admin (with extra powers) making an actionable threat within the community. The harm that is done to morale isn't undone so easily. The damage wasn't just to Pete, it was to the whole community. From my perspective, the community just wants to be an equal partner, but all too often it is made clear that we are just a necessary evil, merely tolerated as a means to an end. Dennis Brown | 2¢ | WER 23:24, 22 July 2014 (UTC)[reply]

Disagree. It appears you have not even considered, and refuse to consider, that Eloquence was acting in good faith (or what if he was mistaken). Indeed, it seems you think the WMF incapable of good faith. Such a damaging assumption, you have fixed for this Project. Alanscottwalker (talk) 23:41, 22 July 2014 (UTC)[reply]

Erik knew Pete. Threatening to desysop him was a good faith act? Then why did he later apologize? No one is even arguing that it wasn't a bad faith act and mistake, except you. Not all WMF employees are the problem. I think highly of Maggie, for example. That doesn't change the fact that many believe there is an institutional problem. Dennis Brown | 2¢ | WER 23:49, 22 July 2014 (UTC)[reply]

Pete was not offended because they knew each other. As for how many are arguing, that's not a logical argument, nor is it responsive. As for the apology, that does not show the original statement/actions were not in good faith. Alanscottwalker (talk) 00:02, 23 July 2014 (UTC)[reply]

Did you even read Pete's statement? ArbCom should admonish staff who misuse staff accounts, even if it carries no actionable consequence. WMF should be accountable to Wikimedia communities; a clear statement when a line is crossed is helpful in itself. I'm sorry, but you are batting 0 for 2 here. Dennis Brown | 2¢ | WER 00:09, 23 July 2014 (UTC)[reply]

Yes. I read it and you have taken it out of context. You decidedly miss the "If". And you have ignored: "Erik and I have known each other for several years, and while I think it's safe to say we have an abiding mutual respect, it's not unusual for our communications to get a bit heated; a bit of strong language from him toward me is totally normal, and not something that worries me. Finally, I strongly adhere to the belief that admin tools are "no big deal," and if I lost them for any reason for a short time, I don't really see what would harm would result. So if considered as an isolated incident, I feel Erik's threat was insignificant, and doesn't demand any kind of strong reaction." As for your snide side comments, they are noted. -- Alanscottwalker (talk) 00:18, 23 July 2014 (UTC)[reply]

Alan, you should just present your evidence at the case. As for noting my "snide" remarks, that is kind of funny considering your first comment to me here. Anyway, think what you want, place your evidence like anyone else, let Arb do their job. Obviously we aren't going to agree so it is pointless to ping pong comments here. Dennis Brown | 2¢ | WER 00:23, 23 July 2014 (UTC)[reply]

Fine. I will note, however, there was nothing snide in my first comment to you. Alanscottwalker (talk) 00:26, 23 July 2014 (UTC)[reply]

• Let's get back to presenting evidence lease guys. Thanks, Callanecc (talk • contribs • logs) 01:00, 23 July 2014 (UTC)[reply]

Please forgive me if this was the wrong spot to include something like this, I figured this talk page would be a safe spot to put it that it would get noticed.

The RFC was a complex RFC, and I don't particularly like that in Wnt's evidence my response on it was considered a disable and not an enable. While I was listed under the disable section, I actually suggested that we disable it for current users and enable it for all newly registered users going forwards. I'd like to request that Wnt either change his tally to include my response under enable, which is honestly probably where it belonged despite my putting it under disable (which was done because the immediate effect would be disable even if long term it would mean enable), or to exclude my response entirely.

This would make that piece of evidence read:

Included under Enable: "RfC: Wikipedia:Media Viewer/June 2014 RfC was closed with 63 editors calling for it to be disabled by default versus 6 calling for it to be enabled."

Excluded: "RfC: Wikipedia:Media Viewer/June 2014 RfC was closed with 63 editors calling for it to be disabled by default versus 5 calling for it to be enabled."

There are likely other responses that are similar to mine in being more complex than a simple binary choice could give. I suggest that those looking over the evidence keep such things in mind. Zell Faze (talk) 04:26, 27 July 2014 (UTC)[reply]

I may be missing something, but it seems there's a more straightforward approach available here than is being proposed by either side ... just start working on the next few difficult RfCs (MV again, VirtualEditor, Flow, whatever else is in the pipeline) that may or may not change the default user interface. Out of thousands of RfCs, the Foundation has objected strongly to the way a handful of them turned out. How do those few exceptions constitute support for some grand new statement in either direction, that the community (or the Foundation) can't be trusted and the Foundation (or the community) is now "The Decider"? Is either side contemplating a future of endless divisiveness over proposed changes? I have to admit I haven't been following, but I thought there were just a few new features proposed ... why not focus on the actual areas where conflicts are anticipated?

I don't know how much of this should go into a workshop proposal, but my unsolicited advice for these RfCs is:

• Encourage everyone to say more than they would say in a typical RfC. People tend to talk in terms of solutions ... but if you prompt them for more, they'll tell you something about what they see as the problems, and that's the information we need to negotiate something that has a chance of working for everyone.
• Instead of letting a few people determine what everyone is going to vote on, allow votes on whatever questions gain traction, either through a pre-RfC to decide the questions, or at the end of an RfC, when the closer(s) can lead a short discussion among the voters to set up the next RfC.
• Allow lots of time. Tough issues take multiple RfCs, because many voters will keep focusing on the question they're most interested in and won't be responsive to other questions until it's clear that they've either lost or won, from their perspective, on what concerns them most, and some time has passed.
• Line up lots of closers, ahead of time. I know that's not the right way, or the usual way, to handle most RfCs, but unfortunately, we've had few people willing to close the tougher RfCs over the last few years, and less-than-stellar behavior from those who do close them, and our failures have lowered participation and increased anxiety among voters. That's so unnecessary ... we have plenty of good closers, they just need to step up early so they can get up to speed and increase voter confidence, and be willing to respond to any concerns people have about their track record as closers, and step down if necessary to avoid drama. Picking the closers ahead of time is even more important if some of the stakeholders and voters are Foundation people and volunteer coders, since some of those guys have a lot of skepticism that our discussion processes are going to adequately deal with their concerns. - Dank (push to talk) 15:17, 28 July 2014 (UTC)[reply]
• Serious attempts were made to get community feedback on MV all along. For whatever reason, the feedback didn't work ... the Foundation representatives seemed to have been genuinely surprised at the results of the RfC ... so it's time to try a process that the community is more familiar with, one that's more likely to generate a lot of honest feedback, and that probably means RfCs.
• I get that voters in the VE and MV RfCs were reacting mostly to things they considered bugs, but even when all bugs have been dealt with, there's a chance that different people will want different interfaces. I don't want to take a position here, I just want to note that the coders have been working hard to get the old and new interfaces to work together, so maybe everyone will get what they want, or something close to it, in the end. - Dank (push to talk) 20:33, 28 July 2014 (UTC)[reply]

Endorse this suggestion entirely; let's move on', restart the discussion, and try to engage as many people as possible from all sides. There is a great potential for going down rabbit-holes here and producing a ruling that does more harm than good in terms of the effect on future community relations, regardless of what it says about mediaviewer. Sometimes the simplest solutions are best...

[Relatedly, I've been trying to put together my thoughts on "how to make an RFC productive", and these are better and simpler than most of what I've come up with so far :-).] Andrew Gray (talk) 22:17, 29 July 2014 (UTC)[reply]

Thanks kindly Andrew, and thanks for offering to turn this into a proposal (on my talk page). There might be a shade difference in what you're saying, if "move on" means "don't make any rulings on what people did or should do" ... I didn't address those questions, they're above my pay grade. - Dank (push to talk) 09:58, 30 July 2014 (UTC)[reply]

Erik Möller, who is a financially-interested party in seeing the "success" of this and other WMF software initiatives, has chutzpah: "Indeed, the main principle on which we cannot compromise is that WMF maintains final authority over software deployment and configuration."

My questions: Where is Mr. Möller's conflict of interest declaration in accordance with site terms of use regulations? He doesn't even show a (WMF) behind his user name, nor was his administrator status ever approved by the community — and he now he seemingly thinks Conflict of Interest is for other people, I wonder? Which of the hundreds of WMF employees have the uncompromisable "right" to unilaterally determine software deployment and configuration on En-WP? Where did this so-called "right" come from?

It is time for ArbCom to make this much clear to Mr. Möller and those who think like him in San Francisco, quoting Lila Tretikov at the July Metrics meeting: You work for the users. Carrite (talk) 17:05, 28 July 2014 (UTC)[reply]

Carrite, to be fair to Erik Möller, his Meta-Wiki page does it make it pretty clear that he is a paid editor; it says that "I am the current Deputy Director and VP of Engineering and Product Development of the Wikimedia Foundation in San Francisco...", which to me seems a straightforward declaration, in line with the site terms of use regulations (NB: but I'm not a lawyer!). An abbreviated version of that, with a link to the Meta-Wiki, is on his English Wikipedia page as well. Hchc2009 (talk) 17:17, 28 July 2014 (UTC)[reply]

I've already gone on record with my strong bellief that staff accounts should always be marked as such, especially when invoking their WMF-derived authority. I also don't believe that staff who have local admin or crat permissions (Erik isn't the only one) and yet only use their permissions for their work with the foundation as opposed to regular admin work to keep the community functioning should not retain those local permissions.

We can't really make the first thing happen, all we can do is ask the foundation to change their policy. We can do the second one. In Erik's case he asked for temporary admin permisssions to do a single task in 2006. As I've mentioned there are other cases like this and I am hopeful somehting will come either form this case or form the community to clean a little house and get rid of local permissions for staff that don't need or use them.

Both of these things shoul make it more clear when one is representing themselves a s amember of the community and when they are representing the foundation. Beeblebrox (talk) 20:51, 30 July 2014 (UTC)[reply]

No objection to the general principle of seperating accounts, but note that in this specific case Erik (as "Eloquence") has had admin permissions since 2003 (back when it was an almost hilariously lightweight process, as you can see on the link). I'm not sure where the 2006 part or the temporary request comes in. Andrew Gray (talk) 21:24, 30 July 2014 (UTC)[reply]

2006 was me mis-remebering the year, my bad. The temporary bit is from his own request. He said he needed to be an temporarily be an admin to move some pages. Presumably they've been moved by now, but his temporary admin status is still in effect despite not actually doing any admin work for this project for the last several years. This is really just a matter of housekeeping. Erik and a few others who moved on to positions at the WMF retain local permissions that they do not really use or even need. Beeblebrox (talk) 00:18, 31 July 2014 (UTC)[reply]

I have to say I find it hard to get worried :-) This was 2003, after all! People asking for adminship for a specific reason is not unusual (I asked for adminship in 2005 because I wanted to correct main-page errors...); saying "temporary" is unusual but, well, 2003! Since then we've more or less established a practice that once adminship is given it remains, regardless of reason for asking. Secondly, if you're going to remove sysop status from people who don't use it much, it seems only fair to be more systematic than just doing it to WMF people... and that's a whole different can of worms to open. Andrew Gray (talk) 21:07, 31 July 2014 (UTC)[reply]

I've no problem with the idea of having staff permissions on a separate, clearly marked account, although I suspect it will probably lead to some new variations of staff/contractor permissions (for example, one for developers to have access to MediaWiki pages but not including the ability to take certain other actions included in the general staff permission). I agree that it's confusing for a single account to be able to take the same actions under two separate and very different types of permission. But remember, Erik's staff permission gave him access to revert edits on a MediaWiki page; he did not rely on enwiki permissions in any way to do that. He can do that on every Wikimedia project because of his staff permissions. His messages make it pretty clear he was acting as someone using WMF staff permissions, not as an enwiki administrator. So, aside from separating the staff permissions by having two different accounts (which I agree the Arbitration Committee can and probably should encourage), there's no actual complaint about the use of enwiki administrator tools. The complaint is about the use of staff permissions. I would hope that Arbcom is not seriously considering an enwiki desysop because of the revert of an edit that even the originator admits was made in error. If you're going to go after sysop permissions that were given under very different circumstances, more than 10 years ago, when the community was radically different, then you're further ahead to advocate for review of *all* administrator permissions on a regular basis. There is nothing in the original announcement of Eloquence being granted adminship that suggested even slightly that it was a temporary granting of permission: it was full-on adminship, whether or not he suggested temporary permissions - which weren't usually granted anyway on this project, ever. (Go ahead - find a single example of someone ever being granted adminship on a temporary basis on enwiki. I've looked and never found one.) Risker (talk) 22:06, 31 July 2014 (UTC)[reply]

Re: temporary adminship: how about (among others) the 2007 Timichal entries (948-950) on Wikipedia:Database reports/Meta-Wiki rights changes ("Temp sysop for permission queue only")? --NE2 10:05, 12 August 2014 (UTC)[reply]

Thanks to all who submitted evidence. We are currently reviewing the submissions and may follow up with questions over the coming week. I've asked the clerks to extend the workshop closing date to the end of this coming weekend (3 August) so there is more time for proposals to be made and discussed there (I will add a similar note over there). The current plan is to have at least some parts of a draft proposed decision up on the workshop for public comments by Friday, and then make any changes needed and move to voting after the weekend. I'll post another update if things slip from that schedule. Carcharoth (talk) 23:03, 28 July 2014 (UTC)[reply]

Per IAR and BLP policies, I've added 4 words which eliminate a probably unintended and anyway unrelated/irrelevant for the context, but severe misrepresentation of a third party, that is m:Tech/News and its editor(s).[3] For more information and discussion please refer to m:Tech/News#contribute and respective talk page, I'm not following this page. Thanks, Nemo 09:49, 29 July 2014 (UTC)[reply]

Adding a couple of notes here on the evidence submissions. These are my views alone, not those of the committee as a whole. The notes are partly to help explain what was useful and may be used in the proposed decision and what will likely not be used (or should be put forward elsewhere).

• Wnt, the survey responses are a subject that is difficult to analyse, partly because the Media Viewer itself changes over time. Hopefully the WMF have some way to measure how the metrics are affected by the changes made to Media Viewer, but analysis of survey results is far outside the scope of this case.
• John F. Lewis, the draft findings of fact (to be published soon) includes some of these links about where Media Viewer and the RfC were publicised, as well as others I tracked down. Thanks for these. I didn't go looking for links outside the English Wikipedia (such as the Tech News release you mentioned). The Code of Conduct and the Wikimedia Gerrit links have not yet been used, but if someone proposes a finding or remedy based on them, that could be considered.
• Dank, your thoughts on RfCs are interesting. It is probably best to address them in the workshop as I see you have since done. Even if nothing concrete comes out of the case, you may want to work with others on possible improvements to the RfC process.
• Ariconte, as part of my research into the case I came across a number of past instances of disagreements between WMF staff and volunteers. It may be useful to have these incidents documented somewhere. I will try and copy over the examples I found. Whether that will rise to the level of a background finding or not is less certain. Ditto for the other quotes from mailing lists. Side-note: the correct spellings of the names you mention are Cary Bass and Sue Gardner.
• Dennis Brown, while agreeing with parts of what you say (though not necessarily your conclusions), your first section is more suited to the workshop than the evidence page. On a point of order, the admin bit in question is a local right. The global staff rights Erik/Eloquence has includes 'editinterface'. Both rights allow editing of the MediaWiki namespace. The core question appears to be this distinction between local and global rights and what standards staff have to keep to (I believe there are internal WMF policies on this), similar to the standards Stewards are expected to maintain. The general rule of thumb seems to be for global rights holders to not interfere where local processes exist to deal with something. Whether that does or should apply to WMF staff is not yet fully clear. There is a current RfC on meta on a policy in relation to the global rights for the 'editinterface' permission (see [4] and [5]). The links you found in the second section were useful, but I'm unwilling to use material from so long ago. You may want to work with Ariconte (see above) to list some of these historical examples somewhere.
• Alanscottwalker, your links were most useful. Thank you for those. Of particular use were the links to the page on meta about user groups. It seems that page is outdated or incorrect. One of the draft findings and the associated remedy will be attempting to address this. The jurisdiction question (I'm aware you have strong views on this) is an important one. Hopefully this can be discussed in more detail at the workshop.
• Wbm1058, thank you for your point about items about Media Viewer in Bugzilla. I am not sure how this can be incorporated into a useful finding. From looking at past software roll-outs and changes, I do know that the WMF do step in and change things if something does go very wrong (the example I saw was related to image widths).
• Eloquence (Erik Möller), thank you for the section titled 'Our original response to the RFC was insufficiently clear'. I will aim to incorporate that into one of the findings. Thank you also for the pointer to the Beta Features roll-out. The link you provide regarding Media Viewer being introduced as a beta feature seems to go to Commons - did you mean to point to somewhere on en-WP? While looking into this, I found this announcement on one of the village pumps back in November that mentioned both Beta Features and Media Viewer. You mention Keegan Peterzell in your evidence - another name I saw coming up frequently was Tgr (WMF) - having 'WMF' in the name is helpful when trying to spot who is who in such discussions. With regard to your point about the Media Viewer extension changing during the RfC, how is this taken into account when analysing the metrics collected by the WMF during surveys? Do you have periods where the product is stable to allow meaningful data to be collected?
• NE Ent, thank-you for the pointer to Erik's secondary response to Pete at Pete's talk page. That diff hasn't been incorporated into the draft findings but could be if needed.
• Risker, my original statement was that the locus of the dispute was the RfC and the actions resulting from that RfC. That was meant to cover the actions taken relating to the MediaWiki:common.js page. I've incorporated your RfC wording into one of the draft principles. The 'WMF Staff rights' section is entirely without links, which isn't that useful. I've gathered a number of links (including to the meta RfC in 2007) while reading up on this, but it is entirely possible that much of the history is undocumented or poorly documented. One thing that could be useful is trying to document things much better than at they are at present. I've included a principle on desysoppings in the draft principles on the workshop - that is probably better discussed there. Thanks for the 'History of WP:CONEXCEPT', I haven't yet come up with a finding on the history here, but if one was proposed at the workshop it may be possible to use it. Similarly, a principle explaining serverside changes and wiki configurations would be useful, but I'm reaching the limits of my technical knowledge here. The links to the logs and quotes from #wikimedia-dev IRC channel are particularly useful. Would you know of a particularly experienced volunteer developer willing to comment at the workshop in this case? (I think some commenting are volunteer developers, but am not sure about that.)
• Peteforsyth, what you have presented here and at the request stage goes far beyond the scope of this case. It is not ArbCom's role to respond to what you are saying here. What you are saying would be better addressed to the Multimedia Team or to those discussing this at mediawiki.org. Having said that, one of the issues I noticed here seems to be the way discussions gravitate to other Wikimedia sites. The notices left by Fabrice Florin linked to the Media Viewer talk page on en-WP, to the discussion page at mediawiki.org, and to a survey. What was remarkable was how little discussion (apart from the RfC) there seems to have been about Media Viewer on the English Wikipedia. Most of the discussion prior to launch seems to have gravitated to other sites. Unless I'm mistaken, the RfC was the place where Media Viewer was discussed the most on the English Wikipedia - was there another place on the English Wikipedia where it was discussed extensively that I'm missing?
• JMP EAX, thank-you (I think) for that link.

I've said enough here for now, and need to go look at the workshop proposals. Many thanks to all who submitted evidence in this case. Please do comment at the workshop on the proposals there. If anyone wants to respond to what I said above, it may be best to do so below, rather than inline above. Carcharoth (talk) 19:23, 2 August 2014 (UTC)[reply]

You're welcome. Thanks for your consideration, and especially the above comments - I hope you Arbs do such comments in all cases. Alanscottwalker (talk) 20:05, 2 August 2014 (UTC)[reply]

@Carcharoth: I have introduced a specific bug report and extended my comments. WMF have taken the position that a small subset of editors participating in the RfC is not representative of the community including readers, and that they have done surveys of the readers which found significant support for the MV. Yet here I see opinion-based discussions among the developers (an even smaller subset of the community) over product design, which is not based on any survey of readers, as far as I can tell. If they aren't properly surveying readers, then at the least they could survey the editors. Wbm1058 (talk) 19:55, 17 August 2014 (UTC)[reply]

Noting that evidence period has closed, I hope that the Committee will take notice of the following: Recent events have raised the question of WMF account naming. Historically, some WMF employees have used a separate account for “work” and “non-work” purposes. Still others have used a single consolidated account for both work and non-work purposes. We’ve known for some time that this could create confusion, and have been gradually moving toward a “two accounts” system. Based on community input, we're now finalizing that process. Here’s the important bit: All employees maintaining a “consolidated” account will need to separate work and non-work editing into separate accounts, and all employees must have a work account that clearly identifies their affiliation with the WMF, using the “(WMF)” suffix (or, in certain circumstances, the “-WMF” suffix). There will be a period of transition as we complete account renames and migrations for this, but our target is to be complete by 9/15. As of that date, work-related edits will be made from specifically designated (WMF) accounts, and there will be no more comingled accounts. Note that this policy applies to production wikis only, and does not impact things such as Phabricator, Bugzilla, or private wikis. Philippe Beaudette, Wikimedia Foundation (talk) 17:41, 21 August 2014 (UTC)[reply]

I don't think "gradually moving toward" is the right phrase. One of the more famous recently created staff accounts, which surely drew some careful consideration before the name was chosen, is User:LilaTretikov. It would be more accurate (and less self-serving of the WMF) to simply say something like, "there have always been competing views on this matter, but now we have made a decision."

While notification of the decision here is helpful, misrepresentation of the relevant history is not. -Pete (talk) 18:13, 21 August 2014 (UTC)[reply]

Really? None of that is necessary. "Gradually moving toward" is not so different from "there have always been competing views on this matter", that you have any basis for claiming "misrepresentation." Would you be interested in an interaction ban with the WMF? It seems you can't deal with them. Alanscottwalker (talk) 18:59, 21 August 2014 (UTC)[reply]

RE Alanscottwalker "Would you be interested in an interaction ban with the WMF?" - I suggest you refrain from making threats during discussions, and keep debating the relevant issues instead. Kraxler (talk) 15:00, 22 August 2014 (UTC)[reply]

What? It's a question in a forum for discussing remedy for behavior. There is little that is more relevant than that: evidence, other-evidence, evidentiary questions, conclusions from evidence. -- Alanscottwalker (talk) 16:05, 22 August 2014 (UTC)[reply]

Update

This is a follow-up to my previous note. We committed to move all staff to defined and marked "staff accounts" and to transfer any work-related user rights to those accounts by September 15th. As of today, I believe that all accounts with the exception of employees traveling or on vacation throughout the entire period have been migrated. The remaining accounts will be migrated as soon as the traveling employees return.

We are doing the final review of the accounts over the course of the next few days, but I'm pleased to say that the rename process is now substantially complete. While all WMF employees adjust to these new policies, if you notice a staff member posting from the wrong account, a gentle comment would be greatly appreciated. Philippe Beaudette, Wikimedia Foundation (talk) 04:09, 16 September 2014 (UTC)[reply]