Requests for comment/Global Interface editors group policy

The following request for comments is closed.

Reading the comments of this RFC I see that there's community consensus to adopt interface editors as official global policy. It is not really much of a change as the provisions of the page have been followed by stewards and requestors somewhat as common law abstent a formal regulation, loophole that it is not covered by this. In summary, we are just officializing what we all have been doing for years.

Having said that, most of community members commenting on here do agree with Vogone's first comment on that we must not require just that the user gets consensus for approval, but that absolutely all requirements set in the scope are met.

As for changes in this policy, be it to expand or reduce the scope and remit, I think that a specific RFC should be made.

I also consider that this RFC has been opened for long enough to consider the consensus generated on it a true reflection on the community feelings, as pointed at the bottom.

As such BE IT ENACTED as global policy the page Interface editors at this version with the requirements set by Vogone, that is: 1) the request must match with the scope of the policy and 2) the requesting user must get consensus at SRGP. Stewards will be in charge of the appointment and removal of global edit interface editors. As a personal note, and taking into count the objections regarding the missuse of this right, while respecting the general principle of assuming good faith, I recommend that the use of this right be monitored so a level of oversight and confidence is created and the risk of bad use of this right is reduced.

-- M\A 15:04, 10 January 2015 (UTC)[reply]

Hello. This is a proposal to make Interface editors into an official policy or guideline. It is already followed de facto by stewards. PiRSquared17 (talk) 16:28, 10 March 2014 (UTC)[reply]

Comments

I agree with this proposed policy except for the point that consensus on SRGP could possibly cause a user to get this user right although not all points mentioned under "Scope" are fulfilled by the candidate. Since this is a right which has impact to all WMF wikis I don't think we are in the position to give the meta community alone the power to "approve" global editinterface tasks without asking all the local communities first and should rather decline any request for global editinterface permission in case the request doesn't cover the scope to 100% regardless of consensus on metawiki. Vogone talk 16:47, 10 March 2014 (UTC)[reply]
It is already de facto policy so might as well make it de jure as well. I do sympathize with Vogone, though; the broad access provided by GEI should almost always retain a similar scope as defined on the page already. Ajraddatz (Talk) 17:55, 10 March 2014 (UTC)[reply]
Support but as with any global right, the holders are advised to tread carefully. --Rs chen 7754 18:00, 10 March 2014 (UTC)[reply]
Support, although it may need some copy-editing. Ruslik (talk) 19:26, 10 March 2014 (UTC)[reply]
Support This should have been set as policy before granting interface editor right to anyone but better late than never. --Meno25 (talk) 19:49, 10 March 2014 (UTC)[reply]
support as per above, esp. Vogone, Ajr, Meno. —DerHexer (Talk) 21:49, 10 March 2014 (UTC)[reply]
Support per Ajraddatz and Meno25. --AmaryllisGardener (talk) 22:31, 10 March 2014 (UTC)[reply]
As is quite often the case with wiki content adminship vs wiki technology editing, it's hard for the people who give out rights to assess a user's developer capabilities. Though stewards tend to be more tech-savvy than an average bureaucrat or sysop, they're still not required to know javascript or css very well or at all (which is fine). I'd feel more comfortable if we raise the bar for global interface editors a bit. It's quite hard to track activities by these users and even if we'd create a dashboard to track those changes, they aren't reviewed before saving (and even a small mistake or misuse can have a devastating impact on projects in a very short amount of time). So basically we need to be able to blindly trust these users to be experienced in javascript/css, and to be up to date with announcements around MediaWiki when something changes in the software (maybe add an non-normative recommendation that they be subscribed to wikitech-ambassadors). Also, perhaps some kind of process where we'd require at least one vote from someone in this global group? Just a few ideas :) –Krinkle^talk 23:24, 10 March 2014 (UTC)[reply]
I think we'd have a hard time getting a vote from another GEI on every request; most do not participate in meta discussions on a regular basis. Nor do I think that would provide good review itself. Overall I'm happy with how the appointment process works now - there have been 0 incidents that I know of where a global interface editor broke wiki css/js (not to say that it's never happened though).

I would like to see a better review of a candidate's experience with css/js, so one potential solution I can think of is to add something like: "votes which express concern with a candidate's competence to complete the task they are requesting GEI for will be given heavy weight when considering the outcome of the request, and if unresolved, could prevent it from passing" to the appointment section. This would hopefully give more weight to any concerns with the candidate's experience and ability should those come up. Ajraddatz (Talk) 23:57, 10 March 2014 (UTC)[reply]
I'm fine with the way it is, but maybe we should extend the 'no less than five days' duration for request discussions. Also, is it a good idea to add the abusefilter-* permissions to this group? --Glaisher [talk] 13:16, 13 March 2014 (UTC)[reply]
I have no idea how abusefilters could help the users in this group to modify JS/CSS and also this right probably shouldn't be given out to a user group which affects all wikis, including big wikis like enwiki without any global discussion. Vogone talk 17:11, 13 March 2014 (UTC)[reply]
There's actually a separate group for that; Hoo had it before he became a steward. --Rs chen 7754 17:18, 13 March 2014 (UTC)[reply]
Nobody said anything to the contrary and this is other group is not subject of our discussion (and IIRC he had assigned it in his capability as a main developer of the mw:Extension:AbuseFilter). Vogone talk 17:38, 13 March 2014 (UTC)[reply]

I didn't know that Abuse filter helpers/editors existed. Since this is the case, no need to add the abusfilter permissions to this group. --Glaisher [talk] 06:06, 15 March 2014 (UTC)[reply]
Support Per Vogone, Ajraddatz, Meno25 etc. Trijnstel_talk 20:15, 18 March 2014 (UTC)[reply]
Support per all above. This de facto policy should have been made official years ago. LlamaAl (talk) 03:29, 27 March 2014 (UTC)[reply]
Support obvious. Alan ^(talk) 20:11, 21 April 2014 (UTC)[reply]
Support, why now? why not since back then?--AldNon^Ucallin?☎ 20:17, 21 April 2014 (UTC)[reply]
Support,excellent--MohandesWiki (talk) 14:54, 28 June 2014 (UTC)[reply]
Comment Please can we make the language inclusive of sidebar translation before we enact this as policy? Unfortunately Mediawiki bundles these few translation tasks in with the ability to edit in Mediawiki space, so we cannot separate the roles. I've been doing this translation job into English for 2 years now ([1] [2] [3]). I agree it's non-central to the GIE role, but I don't think policy should prevent a useful job being done. It's pretty hard to imagine local admins taking it up without a lot of prodding, because they're usually focused on their local language. And I think it would be a distraction to bother real js/css editors with this job. --99of9 (talk) 11:10, 14 July 2014 (UTC)[reply]
Support –Krinkle^talk 18:05, 15 July 2014 (UTC)[reply]
Oppose in the current state. In general, I would support, but I consider as a nonsense that groups with less rights (GEI in this case) must be appointed only temporarily, while groups with much larger rights and thus much bigger potential destructive power (global sysop, stewards) are granted indefinitely by default. There should be either same grant period for all groups or the period should match the amount and scope of assigned rights. Currently it's upside down.
— Danny B. 09:46, 3 August 2014 (UTC)[reply]
Firstly, I don't believe global sysops have "much bigger potential destructive power", especially since that group is WikiSet-limited. Secondly, it requires way more community review before a GS is appointed (at least 14 days + consensus). As for stewards, they yearly undergo some kind of confirmation process and on top require 1 month of community review before approval. That a right like GEI which is granted without close review by the community is granted only temporarily seems just logical to me. Vogone (talk) 17:20, 3 August 2014 (UTC)[reply]
Noting that I made a minor change to the proposal to reflect the changes in how staff rights are handled. --Rs chen 7754 19:24, 30 August 2014 (UTC)[reply]
For the reference: [4] Vogone (talk) 08:43, 1 September 2014 (UTC)[reply]
@99of9, Vogone, Aldnonymous, Rschen7754, DerHexer, Ajraddatz, Ruslik0, AmaryllisGardener, Krinkle, Glaisher, LlamaAl, Alan, Trijnstel, and MohandesWiki: to answer the concern raised by 99of9 above, I propose this modification. Does anyone object? PiRSquared17 (talk) 05:19, 1 September 2014 (UTC)[reply]
- I thought that was already allowed... anyway, that's fine. --Rs chen 7754 05:22, 1 September 2014 (UTC)[reply]
  - In all honesty, it probably already was, but it might be better to explicitly state it in the lead. PiRSquared17 (talk) 05:30, 1 September 2014 (UTC)[reply]
Yes, I don't believe we as meta community can decide this. The current points are already borderline, but any addendum would require global approval, like also the global sysop group. Regards, Vogone (talk) 08:37, 1 September 2014 (UTC)[reply]
Why can we decide the rest of this group policy but not that aspect? I support the change. --99of9 (talk) 11:14, 1 September 2014 (UTC)[reply]
As I've mentioned above, we cannot. But the scope is currently limited to "fixes" and group members were ultimatively developers. If we want to extend the scope, I'm not per se against that, but would welcome a global RFC like it was done with previous global groups with a wide impact. Regards, Vogone (talk) 11:24, 1 September 2014 (UTC)[reply]

In other words, the communities should decide what global interface editors are allowed to do on their wiki under which conditions, not us. Vogone (talk) 11:26, 1 September 2014 (UTC)[reply]
This RfC has been open since March, and anyone could have seen it on RFC and commented. The global renaming policy has already been accepted in far less time, along with its violation of Meta:Snowball, and I didn't even know there was an RfC (to be fair, I haven't been that active lately). We could send out a massmessage asking communities whether they would accept this policy or not, if you want. PiRSquared17 (talk) 14:09, 1 September 2014 (UTC)[reply]
Not anyone, only very few editors monitor metawiki, not even speaking of editors who monitor RFC. The global rename case is a special case as the Foundation is going to remove the ability for local users to rename accounts. In this case, there are local users who can edit the interface. Vogone (talk) 14:39, 1 September 2014 (UTC)[reply]
Then please stop complaining about the lack of global voting and make one! Obviously enough people feel that the discussion here is sufficient; if you want to get more input from other projects, then be proactive and help set one up. I would be glad to send mass messages or whatever is needed to advertise it. Ajraddatz (talk) 14:45, 1 September 2014 (UTC)[reply]
I said a global vote is needed if we extend the scope. No such thing happened yet. Vogone (talk) 14:51, 1 September 2014 (UTC)[reply]

Summation

There is a general agreement among the above participants that the GEI should be an accepted policy among the respondents.
There is a case made that this general acceptance is not sufficient without a broader (official?) announcement to communities, and following that then a decision can be made.
There is a long-standing operational process and convention for the accepting of nominations, and processing by stewards
There are no communities having expressed opposition, nor concerns about the practice
The policy proposal has been in place for 2½ years, and apparently reflected the practice at the time

There is no formalised practice for RFC acceptance, though more lately there has become a more common practice for notifications.

This proposal has reached at a standstill as no one accepts that we wish to disturb all the communities, and no one can be bothered to do the leg work as it is easier to do nothing and maintain the status quo, especially with a more technical type permission.

Proposal to accept and to close

As a means to move this forward I propose that in this case that the accept the general proposal and formalise this policy due to its age, that it is operational process, and that something needs to be in place for the decision-making that needs to occur.

Indicator of work that should flow from this to stop policy and procedure paralysis would be …

Outside of this RFC, I propose that we need to RFC RFCing of policies, and identify the practice for getting WMF-wide policies and practices accepted, and the means for notification, and a standardised process for this. It is time that this gap was closed and provides certainty for those who are needing to make decisions.

I also propose that we have an ongoing means to have policies open for discussion, and set a general review date or life or point of update for a version that formalises (makes easier) an update. Requisite languages, etc. At a bare minimum a shared agreement on a framework. — billinghurst sDrewth 01:38, 1 October 2014 (UTC)[reply]

Let's move this forward. It's been open long enough. PiRSquared17 (talk) 03:20, 25 October 2014 (UTC)[reply]