User:Risker/sandbox2


 * MediaWiki:Common.js page has user instructions at the top of the page and in the edit window that explicitly state "This is JavaScript for all users. Any changes to this page should first be proposed on its talk page or the Village pump. Please note that changes are visible within minutes. Errors you make here can disrupt the entire encyclopedia, so make sure you know what you are doing."
 * This was Peteforsyth's first edit to MediaWiki:Common.js, and only his second edit to the MediaWiki space since he became an administrator in 2008. He has not written or submitted any code to the site in the past.
 * Administrators have a wide range of permissions automatically granted to them, whether or not they have the knowledge or experience to utilize them all. It has been a longtime expectation that administrators not carry out tasks that are outside of their personal abilities or understanding.
 * The earliest administrators on Wikipedia were mostly experienced in developing MediaWiki code. At a time when there was fewer than 5 Wiki(p)(m)edia employees, the vast majority of software development was carried out by volunteers, and many of those volunteers were granted adminship in order to implement code more effectively. This is the key historical reason that access to the Mediawiki space was granted to administrators.
 * Over the course of many years, a significant amount of "technical debt" has accumulated. Once the WMF was in a financial position to hire more staff, the Engineering Department expanded, with both direct and indirect focuses on reducing this technical debt. All projects have benefitted significantly from this concerted effort: there is reduced downtime, most software upgrades are phased in across smaller projects before being applied to the largest projects (thus identifying and fixing bugs before deployment here), software updates are carried out on a scheduled basis, the oversight "hack" was deprecated and revision deletion/suppression developed, language support and translation has expanded, and support for mobile/tablet editing has become a major focus. Because the pace of improvement and change has increased exponentially in the past few years, the frequency of concerns and complaints about change expressed by the community has also increased. There have also been some errors in judgment, at least in part because of a clash between the "old" culture of muddling through imperfect software changes and the newer expectations that software be operational at a near-equivalent level; this may be because Wikipedia communities expect higher standards from paid employees as compared to unpaid volunteer developers (who are often viewed as being "of the community"). The best known example of this is the introduction of VisualEditor as the default editing tool in July 2013, despite significant concerns from many community members, leading to a rebellion of the community that resulted in the WMF making changes to the English Wikipedia core configuration after a "hack" edit to the MediaWiki:common.js.
 * The "VisualEditor" hack made to the Mediawiki.common.js had, at least, been reviewed by other coders and had been widely discussed on multiple noticeboards and brought to the attention of WMF staff for an extended period prior to its introduction into the MediaWiki:common.js. After the hack had been added, it became apparent that the WMF was writing and testing the code that would have a similar effect in the core configuration; once that code was verified and uploaded, a WMF staffer removed the MediaWiki:common.js hack.


 * I made some inquiries on the #wikimedia-dev IRC channel (a logged channel) on 24 July 2014 around 0340 hours. My question was "Could someone please help me understand why requesting a site configuration change is better than modification of a site's mediawiki:common.js?" Some key points from that discussion, coming from experienced MediaWiki developers (both volunteer and volunteer/staff developers):
 * with just that info, probably for performance
 * also Common.js doesn't run for users with JS disabled...
 * if it is a $wg config option, any JS is probably a hack
 * It is discouraged to do that by principle. $wg are server configurations. They control whether code is executed and whether modules are loaded in the web browsers. [The] common.js executes inside your browser. if you disable a feauture there you basically first wait for the server to compute the feature, and for the web browser to load it all (and maybe even make part of it appear visually) only to then distroy it soon as it loads. Plus, the server configuration can also influence things you can't control in javascript. E.g. destroying LiquidThreads via common.js on a wiki where that is enabled would leave you with an empty page and no way to edit the talk page because it's controlled server side.
 * The entire server configuration is open source and editable in a wiki-page like fashion (see https://github.com/wikimedia/operations-mediawiki-config/tree/master/wmf-config). The only difference is that (a bit like FlaggedRevs) we obviously do review changes before they go live. So the community could even write the so-called "patch" themselves and propose the edit via Gerrit (like :D)

Evidence presented by Risker
My evidence is in response to the questions asked by arbitrator Carcharoth on the evidence talk page.

Locus of the dispute
I disagree with Carcharoth's identification of the locus of the dispute as being the RFC. The locus of dispute is the MediaWiki:common.js page.

Requests for comment
Requests for comment are advisory, not regulatory; they suggest a course of action but do not require such action. As well, RFCs may come to a conclusion that is not enforceable or actionable, because it would violate an existing policy (e.g., an RFC that "approves" the use of an unreliable source for contentious information, or one that "requires" blocking or banning an editor), does not adequately take into consideration other related issues, may cause harm to the project, or has inadequate participation. Many RFCs, particularly on article talk pages, are never formally closed. As a more similar example, the RFC to remove VisualEditor as the default editor on this project showed a consensus to make that change, but the solution for implementing that change was discussed in multiple other forums prior to its application.

WMF Staff rights

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

History of WP:CONEXCEPT

 * First appears in the consensus policy in 2005, at the time that the community was deciding whether or not consensus was indeed a policy and not just a guideline or commonly used process.
 * At that time the WMF had three employees, and the overwhelming majority of those handling the technical maintenance, development and improvement of the WMF sites were volunteers; thus, the first entries relating to the CONEXCEPT concept refer to "developers"; I understand that volunteer developers sometimes rolled back site-specific edits, although I do not have any links for this. Over time, as the WMF has expanded its professional staff, the section has been reworded to recognize that WMF engineering staff and contractors have the same authority to invoked CONEXCEPT that volunteer developers do.
 * The exact history is very tangled and seems to involve several pages whose histories may have been merged.

MediaWiki:Common.js

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

Proposed principles English Wikipedia and its relationships within the Wikimedia movement

1) English Wikipedia and its editing community do not exist in isolation. It is the largest of hundreds of projects supported by the Wikimedia Foundation, it is part of the Wikimedia movement, the software has been developed over many years by both volunteer and WMF staff and contracted developers, and it is read by millions of visitors every week.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Responsibilities and authority

2) The lines of responsibility and authority between the English Wikipedia community, the Wikimedia Foundation, the Wikimedia movement, and the MediaWiki developers intersect and, at times, can appear to conflict.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Expectations for administrators

3) Administrators are expected to act with caution and to respect warnings and edit notices, particularly those that warn about the potential to cause harm to the entire project if errors are made. Administrators are expected to recognize their personal limitations and not act without specialist assistance or consultation outside those limits in high-risk areas.

Requests for comment

4) Requests for comment (RFC) are one of several dispute resolution mechanisms in use on English Wikipedia. They are advisory rather than regulatory: any closing statements are recommendations, and actions taken as basis of such recommendations for many types of RFC will require a further discussion or decision in another venue prior to their enactment.

Proposed findings of fact

Editing in the MediaWiki namespace

1) Any administrator has the technical capability to edit any page within the MediaWiki namespace. Several of these pages, including MediaWiki:Common.js and MediaWiki:Common.css, require editing using specific software coding skills to prevent harm to the project. Such high-risk pages generally have notices and/or warnings outlining required skills or steps to be taken prior to editing.

Comment by Arbitrators:

Comment by parties:

Comment by others:

PeteForsyth's edit to the MediaWiki:Common.js page

2) PeteForsyth added code to the MediaWiki:Common.js page. This was only his second edit to the MediaWiki space since he became an administrator in 2008.

Comment by Arbitrators:

Comment by parties:

Comment by others:


 * This can be combined with other related proposed findings. The committee may also want to make note that the code was written by MZMcBride just to complete the factual background.

WP:CONEXCEPT

3) Exceptions to the consensus policy have been incorporated into the policy since its conversion from guideline to policy in 2007. Prior to that, similar exceptions were described in the policy on policies and guidelines from late 2005, and processes for the community to request system changes were described in the same policy from January 2006.

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

1) {text of proposed remedy}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

2) {text of proposed remedy}

Comment by Arbitrators:

Comment by parties:

Comment by others: