Wikipedia talk:Interface administrators

Interface administrators

I have started a discussion about the new interface administrator user group at WP:VPM#RFC: Interface administrators and transition. Please take a moment to review and/or comment. --Izno (talk) 14:45, 30 July 2018 (UTC)

Proposed access requirements

My suggestion here is to make it an RfA/RfBAG type process, but that's only my thoughts as someone who cares about how user rights are implemented. I'm assuming this would be easier than a list of technical requirements, since people who are interested and care about it will follow the page. Thoughts would be welcome. TonyBallioni (talk) 15:23, 30 July 2018 (UTC)

• I agree on not having a particular fixed requirement. I think we should make sure it isn't too bureaucratic/and or too time consuming. Something closer to how EFM/EFMs are given to non-admins seems reasonable to me, where the right is given after 7 days of discussion assuming a demonstrated need and expertise and no significant opposition. Most cases should be uncontroversial so I don't see the need for something as large or bureaucratic as an RfA. Galobtter (pingó mió) 15:33, 30 July 2018 (UTC)
  • I was thinking more like WP:RFBAG honestly. TonyBallioni (talk) 15:39, 30 July 2018 (UTC)
    • I personally hope there's a whole lot more scrutiny than a BAG application, but yes, some wide community scrutiny should be required. -- zzuuzz ^(talk) 15:40, 30 July 2018 (UTC)

      IMO that scrutiny already happened in the RfA - admins are already trusted a lot not to deliberately harm the website (with, even without JS/CSS access, they have significant power to do so), and since the main "bigdeal" of techadmin is deliberate misuse, there should be very little need for any sort of large scrutiny, beyond making sure they have a need and a minimum of ability. Galobtter (pingó mió) 15:48, 30 July 2018 (UTC)

• I'm a fan of the RFBAG process for granting access to these rights. Do we want to have different standards for sysops/non-sysops? On Meta we're considering allowing existing admins to pass a request in two days without objection, and everyone else in a week (or an admin in a week if there are objections). -- Ajraddatz (talk) 15:47, 30 July 2018 (UTC)
  • I think what I was getting at would be a public vetting is needed. I generally think meta has a good process for according these sorts of things, and it might be good to mirror their requirements. TonyBallioni (talk) 15:53, 30 July 2018 (UTC)

  Having say a 3 day process if there are no objections seems reasonable to me for sysops. Non-admins should definitely have a different process (if consensus is even there for allowing non-admins to become techadmins..) Galobtter (pingó mió) 15:54, 30 July 2018 (UTC)

• I also said upfront that I viewed this as more of an EFM-like thing. Both EFMs and techadmins can basically break an entire wiki so it makes sense for both user-right requests to be reviewed by existing right holders and experienced in the chosen area. As long as both are gated behind "must already be admin" I don't see how a second RFA-like process is helpful. Ben · Salvidrim! ✉ 15:56, 30 July 2018 (UTC)
  • Is the assumption here that everyone will have to be a sysop? If so, I'd generally agree with you. TonyBallioni (talk) 15:59, 30 July 2018 (UTC)
    • I think that would be quite likely to be something the community can agree on. I can't think of a reason not to... Ben · Salvidrim! ✉ 16:02, 30 July 2018 (UTC)
      • Let's test that below :-) -- Ajraddatz (talk) 16:06, 30 July 2018 (UTC)
  • This is my preference as well. SQL^{Query me!} 21:16, 30 July 2018 (UTC)
• One of the big problems with introducing a new user right like this is that whether new rights holders are needed or not, people will clamber for it. They always do. Perhaps put a cap on the numbers like they do at CU and OS. I would say a simple request at WP:BN with at least two 'crats agreeing. There's no need to make this a big public RfA-style thing or even like PERM which is also too public.. This kind of editing is not an activity that is often required and the 6 or 7 competent people doing this already can be grandfathered. Otherwise, admins only. Kudpung กุดผึ้ง (talk) 22:07, 30 July 2018 (UTC)
• I concur with Kudpung and Salvidrim. Please, we do not need another RfA process. This is a strictly technical user group. The broader community is not going to be able to vet someone's competence in this area. They community does, however, need to be convinced the user can be trusted, and that can be satisfied by the sysop as a requirement. A discussion right here on this page I think is fine, or WP:BN if you think that's better. It should be similar to what we do for WP:EFM at WP:EFN, only with a longer discussion period and stricter requirements. Overall, I stand by my belief that if this "interface admin" user group is a success, there will be very, very few requests for it. Editing MediaWiki JS/CSS is rare. The fewer interface admins, the better (but enough to fulfill protected edit requests, obviously). That's the intent, anyway. — MusikAnimal ^talk 00:57, 31 July 2018 (UTC)

  To put in perspective, in the past year, there have been 485 edits made by 27 users (some are global-interface-editors who are making WMF staff edits). I don't think we need many more interface admins than that. That query does include edits to MediaWiki:Gadget-geonotice-list.js, which are done by some non-techy admins. For the time being they'll have to request changes from interface admins, but at some point we will be able to grab data from JSON pages behind ResourceLoader (phab:T198758), so they will be able to manage central notices on their own. At any rate, I think the volume of edits can be satisfied with maybe 20 or so interface admins, roughly the same number of admins who edit site JS/CSS currently. — MusikAnimal ^talk 02:04, 31 July 2018 (UTC)

• Agree with MusikAnimal. Very few folks need or would even make use of the ability to edit site-wide JS or CSS, so this doesn't need to be onerous. I think we can manage a smooth process with few but important roadblocks; the process for WP:EFM is a good model. A little statement to demonstrate need and ability, I wouldn't say no to two of the three CUOS appointment questions (i.e., Please describe any relevant on-Wiki experience you have for this role. and Please outline, without breaching your personal privacy, what off-Wiki experience or technical expertise you have for this role.). Basically, anything that requires the handful of usuals to wait is a bad process. ~ Amory (u • t • c) 01:43, 31 July 2018 (UTC)
• Crats - I'm unsure what my non-admin desired process would be, but I think that Kudpung's suggestion of 2 'Crats agreeing is sufficient for any Admins. Probably a 3 day waiting period, rather than just immediately after 2 agree. Nosebagbear (talk)
• Expert Opinions - after the initial wave is through, it would probably be logical to ask the interface admins, formally, what their judgement was on new applicants for the rights, since while the 'Crats/Community might determine trustworthiness, we are probably less apt to determine capability. Nosebagbear (talk) 17:04, 3 August 2018 (UTC)
• Not sure what to think on this precise issue, but we absolutely must have a local policy saying that you may lose your rights immediately if you revert someone who's enforcing community consensus (barring misclicks, good-faith misunderstandings, etc.), and that if you make such a reversion and lose your rights, someone else may restore your edit without discussion. Given past history, I question whether this is really a matter of good-faith site security: obviously most people here are handling it that way, and that's fine, but we need to have a policy-based reason for removing your rights immediately, like the German Wikipedia did, if you're complicit in another superprotect situation. Nyttend (talk) 11:36, 6 August 2018 (UTC)
  • FYI, the superprotect conspiracy theory thread already exists below at #WMF raises connection between this user right and Superprotect. It might be best to keep discussion in one place.

    Are you really targeting de:Special:Diff/132931713 here? That's the only edit I see there that would really be affected by the policy you propose here. WMF staff could have done their changes in other ways, if they had needed to.

    BTW, I can't seem to find anyone who actually lost rights over the superprotect mess, despite discussion in a few places such as de:Wikipedia:Administratoren/Probleme/Jan eissfeldt. One WMF person was blocked for a few days, but that's all I can find. Do you have log links? Anomie⚔ 13:32, 6 August 2018 (UTC)

Sysop as requirement

There is some disagreement above, so let's ask the question: Should this right be restricted to admins? Some possible models:

1. Only admins are allowed to be granted the right, either through a selection process or a request to bureaucrats.
2. Admins and non-admins can be granted the right, but admins go through a reduced selection process because they have already been evaluated on the "trust" angle.
3. The right is completely separated from admin, and all users must undergo a selection process specific to the right.

I think option 2 makes the most sense myself. We have the potential to open these rights up to non-admins, as with EFM, and I think we should take that opportunity. At the same time, existing admins can be trusted with access to the right, but their technical competence in the area hasn't necessarily been evaluated. -- Ajraddatz (talk) 16:06, 30 July 2018 (UTC)

Thinking more about option 2: it's worth noting that at least three non-admins have contributed to .css and .js pages through membership in the global interface editors group. It was originally my thought that there may be some local users who could help out in this area, but who aren't admins and wouldn't want to be added to the global group. However, there still remains very little ongoing need to modify the css.js files, and with an RfA-like selection process there may be limited interest in non-admins applying for a permission that they would only use once or twice a year on average. Demonstrating a "need" for the permission would likewise be difficult. For simplicity's sake, I could support option 1 with a request to bureaucrats and a small holding period (48 - 74 hours), and maybe expanding to option 2 with later consensus if there are interested non-admins. -- Ajraddatz (talk) 15:43, 31 July 2018 (UTC)

• Sort of the point I made elsewhere, but I there's a difference between "are there non-sysop users who could be helpful with interfaceadmin?" and "should this right be restricted to admins?" The former is certainly true, but it's orthogonal to the second question. I'm sure there will be many users who can be trusted and have the knowledge to be techadmins, but won't. That's okay! As long as we've got enough active editors to maintain the pages and respond reasonably quickly to edit requests, there's no harm. The more people who have this, the greater the security risk. ~ Amory (u • t • c) 16:24, 31 July 2018 (UTC)

• Fair point; non-admins can always request changes on relevant talk pages, and given how few of these requests there are it shouldn't be a burden on either the requestee or the actioner. I am thinking of this in terms of engaging volunteers, but the security argument is probably a better one to be using here. -- Ajraddatz (talk) 17:03, 31 July 2018 (UTC)

• No opinion on non-admins, but for admins, I think a request at BN subject to a 72 hour (or other reasonable period) hold for comments makes sense. TonyBallioni (talk) 16:08, 30 July 2018 (UTC)
  • Per Kudpung above, I’d say support option 1 and like I said above, a simple post at BN with a waiting period to comment should do. I’ll also add this has a huge practical benefit: there seems to be agreement that this should be fairly simple for competent admins who work in this area to get. Having this as the initial requirement would likely get easy consensus without having to create a standard for non-admins. Once this becomes a local policy, we can change it as needed, but getting a policy together before this is implemented is ideal. TonyBallioni (talk) 23:24, 30 July 2018 (UTC)
• Support Option 1 for now because I can't think of a situation where a non-admin would ever be granted this, but I'm not necessarily opposed to Option 2 as analoguous to EFM -- not strictly forbidden by policy, but "highly-restricted" (to quote WP:EFM). Ben · Salvidrim! ✉ 16:42, 30 July 2018 (UTC)
• Support 3 because the two permissions exist for different reasons and have different purposes. Admin is essentially a social function and a sound understanding of policy and practice are essential. Interface admin prioritizes technical skill and security, a fair difference to admin. Jo-Jo Eumerus (talk, contributions) 20:23, 30 July 2018 (UTC)
• Support 2, altho I'm not sure it (or option 3) are technically possible. I could see some technically saavy non-admins wanting to help with things like the spam blacklist. SQL^{Query me!} 21:16, 30 July 2018 (UTC)

  Both are technically possible, as the relevant rights will be completely removed from the sysop group come the end of August. We are able to decide who is in the new group and how they are selected. -- Ajraddatz (talk) 21:54, 30 July 2018 (UTC)

  Not what I meant at all. I figured out what I was talking about in any case. SQL^{Query me!} 22:21, 30 July 2018 (UTC)

  @SQL: This only affects the JavaScript and CSS content types. The spam blacklist is wikitext — MusikAnimal ^talk 01:09, 31 July 2018 (UTC)

  Actually "interface admin" let's you edit anywhere in the MediaWiki namespace, so never mind! Now I understand why they changed it from "tech admin" to "interface admin" — MusikAnimal ^talk 20:28, 31 July 2018 (UTC)

  Note however, interface admins can not edit through protection, so if there is a mediawiki page that admins don't want non-admin techadmins to edit they can apply admin protection on top of the namesapce protection. — xaosflux ^Talk 21:36, 31 July 2018 (UTC)

• Support 1 because the number of users who have edited these pages is is very small, most of them are admins, and one of the non admins has retired anyway. Grandfather the rest. And there is no hurry.Kudpung กุดผึ้ง (talk) 21:57, 30 July 2018 (UTC)
• Support 1 This is the only one that in my opinion makes any sense. Editing site-wide JS/CSS is the most sensitive thing you can do here. All users who are able to do this should also be able (and strongly encouraged) to have two-factor authentication turned on. Allowing non-admins to edit JS/CSS this code, regardless of their experience and trust, is a security risk. — MusikAnimal ^talk 01:03, 31 July 2018 (UTC)

• @MusikAnimal:--Umm....Non-admins can easily request for 2FA at Steward's Noticeboard over Meta:) So, that's hardly a reason to debar competent non-admins from a technical task.∯WBG^converse 05:14, 31 July 2018 (UTC)
• Yeah and actually, interface editors themselves will surely be able to enable 2FA. It doesn't make sense to allow people to edit site JS/CSS and not secure their account like sysops can (which, in this case, is the less sensitive user group). I still !vote for option 1 because that would reduce bureaucracy -- first having the users be evaluated by the community through a separate process (RfA), which then means the only barrier is demonstrating need and competency, which other interface admins will be able to do. If there were more people who actually edited site JS/CSS, then it would be different. If we have 20-25 interface admins, I suspect we'd be getting by just fine and satisfying the intent here, which is reducing the number of accounts that have this ability. I don't think making protected edit requests is that much of a pain, especially when they will be rare (based on the volume of edits we see now) — MusikAnimal ^talk 20:39, 31 July 2018 (UTC)

• Option 1 No other option is reasonable. RfA is, for better or for worse, our mechanism for establishing a general baseline community-wide trustworthiness. For anyone to justify having techadmin they'd need to meet those requirements. They should. ~ Amory (u • t • c) 01:46, 31 July 2018 (UTC)
• Support 1 Anyone who edits sidewide javascript could use it to hijack admin accounts and perform admin actions on their behalf (including accessing sensitive deleted content). Any community vetting process would have to be at least as strict as RfA, so at that point it makes more sense to just have them go through RfA. --Ahecht (TALK
  PAGE) 01:47, 31 July 2018 (UTC)
• Support 3 I don't think sysop needs to be a requirement, but there does need to be a strong consensus process for granting the permission. I don't see much need at first glance for a "reduced" process for people who pass RfA after the changeover; while they've already gotten a position of trust, it doesn't seem worth having a special process instead of just allowing the discussion to naturally take trust as assumed (or not). OTOH, we probably should have some sort of grandfathering for existing admins who've already used the ability to edit JS and CSS to bootstrap things. Anomie⚔ 02:01, 31 July 2018 (UTC)
• Option 1 to start with. There may be exceptional circumstances in the future where a non-admin might find this useful, without additionally having to go through an unnecessary RfA. I can't easily imagine such a situation, but I hope we can revisit this topic and implement option 2 through an RfA-style process if it ever happens. -- zzuuzz ^(talk) 06:26, 31 July 2018 (UTC)
• Support 1 with crats empowered to grant the bit upon request. Anyone who already went through RFA can be considered trustworthy enough not to do anything bad when they get the right. Current experience shows that this is the case (cf. EFM right). Regards SoWhy 07:56, 31 July 2018 (UTC)
• Support 2 - With 2 'Crats sufficient to authorise admins. Non-admins need consideration as strenuous as actual admins, but in an extremely narrow field (i.e. more than BAG). WOSlinker makes the correct note that 'Crats obviously shouldn't self-grant.Nosebagbear (talk) 18:23, 31 July 2018 (UTC)
• Option 1. Also, bureaucrats should not grant the option to themselves and should go through the process and well and get another bureaucrat to grant them the right if they need it. -- WOSlinker (talk) 21:44, 31 July 2018 (UTC)
• Option 3 per Principle of least privilege and Anomie. My concern is not so much malicious admins as it is compromised accounts, we have many admins who by virtue of making one edit a year keep the bit and represent a massive security vulnerability if any of them get compromised due to weak/reused passwords or phishing. Even slightly more active admins could be compromised and request the right before they even know. It seems from the above discussion that css and javascript changes are incredibly rare and so I don't think there's any need to hand this out readily or on an expidited basis to anyone, especially given the harm it could cause (see, for example, Anomie's cryptocurrency mining example below). The fewer people able to access or easily access this bit the better. I like some suggestions above about capping the number of users with the bit, and I think there may be some value in giving a default expiry time for anyone with the bit. I am very wary of this right. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 22:31, 31 July 2018 (UTC)
• Note, if we allow non-admins access it will allow these users to also update mediawiki pages such as the MediaWiki:Titleblacklist, MediaWiki:Spam-blacklist etc - this access can be overridden by admins by apply admin-only protection on top of the namespace protection. General editing guidelines for non-admins in these spaces may need some consideration. — xaosflux ^Talk 03:24, 2 August 2018 (UTC)
  • Xaosflux Um, really? I thought that this userright was to contain simply the right to edit JS/CSS pages, not also including the entire MediaWiki namespace. Jo-Jo Eumerus (talk, contributions) 09:13, 3 August 2018 (UTC)
    • @Jo-Jo Eumerus: Yes, interface admins have editinterface ~ Amory (u • t • c) 12:10, 3 August 2018 (UTC)
      • Yeah, that sounds off to me. A more reasonable design would be to make the permission to edit the MediaWiki.css and MediaWiki.js pages a wholly separate permission than the general MediaWiki namespace editing permission. Jo-Jo Eumerus (talk, contributions) 12:15, 3 August 2018 (UTC)
• Option 1 is the safe way to proceed. If non-admins would like to do this, they need the trust of the community, and so should undergo RFA prior. There should be some more criteria, other than just a request though. Graeme Bartlett (talk) 08:48, 3 August 2018 (UTC)

  Graeme Bartlett, I responded to the line of reasoning that RfA demonstrates the community's trust in an editor below; you might be interested in that. Enterprisey (talk!) 03:55, 9 August 2018 (UTC)

• Option 1 and/or 3. I think everyone should have to be vetted before they're given this role, even if they're admin. Given the importance of the privileges this role bestows, a community consensus would be better than a few 'crats being unable to find fault (not to say I don't trust them, of course). Cheers, Anarchyte (work | talk) 08:56, 3 August 2018 (UTC)
• Option 1 though I wouldn't be opposed to option 2 at a later date. --Rschen7754 19:28, 4 August 2018 (UTC)
• Option 1 for two reasons. The first is that RfA gives a baseline indication of the trust the community has in an editor, to have non-admins able to granted this right, they should IMHO go through an RFA-like process to establish that community trust. As people have said above, we don't need another process like RFA. Secondly, given that an interface admin would be able to edit any MediaWiki page (spam and title blacklists, block reasons) the expectation that they be an admin and have been vetted by the community to make these decisions is important and necessary. Callanecc (talk • contribs • logs) 00:03, 5 August 2018 (UTC)
• Support 2 or 3. Interface administrators need to have two qualities: Trust and technical ability. RFA deals with the first of these but not the second, but also includes a lot of focus on things that are irrelevant this role. Thryduulf (talk) 08:17, 5 August 2018 (UTC)
• Support option 1, granted upon request, removed fairly quickly if not used? I don't think a process more complicated than "post to WP:BN" (like our resysop process) is necessary for a right that used to be part of "sysop". —Kusma (t·c) 14:22, 5 August 2018 (UTC)

  Possibly also immediately grant to all sysops that have ever edited any of the pages affected by the new group, or anything similar. —Kusma (t·c) 14:30, 5 August 2018 (UTC)

• 2 or 3 - I can think of a plausible set of circumstances where I'd support someone for technical admin, but oppose them for vanilla sysop. There are a number of criteria (civility, Knowledge of protection, knowledge about blocking) that all admins need to There are two criteria for interface adin - trustworthiness and competence. RFA proves the first, and is irrelevant to the second. — Preceding unsigned comment added by Tazerdadog (talk • contribs) 20:17, 5 August 2018 (UTC)

• 1 as per the section below without admin access: interface admins would not be able to delete pages they make; and non-interface editor admins would not be able to delete them either. Same goes for cleaning / repairing of user css/user js pages. — xaosflux ^Talk 21:24, 5 August 2018 (UTC)

  2 or 3 Perhaps relax in the future if phab:T200176 gets done (allowing "delete" of these pages without edit). — xaosflux ^Talk 21:45, 5 August 2018 (UTC)

• Option 2 Admins should be expected to establish need, non admins should undergo a very thorough review, and I would expect very few non-admins to get approved. Monty₈₄₅ 03:00, 6 August 2018 (UTC)
• Support 2 or 3 per Tazerdadog. I don't really think the criteria for admin and interface administrator should be the same. They are significantly different roles. Kaldari (talk) 18:11, 7 August 2018 (UTC)
• Oppose 1, support 2 or 3 I don't think that we should make this work contingent upon agreeing to undergo RFA or hold sysop rights. There are competent, trustworthy technical editors whom I'd be happy to see in this role, and who might be willing to do this work (or at least to do it for a specified project), but who have no interest in delete or block buttons. If some editors with both sysop and iadmin rights decided not to bother with sysop stuff any longer, then I'd be sorry to automatically lose their help in this area. While I expect that – similar to ArbCom – nearly every editor with this right will also be a sysop, I would be sorry if it was made a formal requirement. There are a lot of scripts around here, and sometimes a change in MediaWiki requires updating a lot of them at once. This isn't about the design of the Main Page. Think about what would happen if popular gadgets like Twinkle or WikEd or the watchlist formatting gadgets broke (again). Let's make this available to competent, trustworthy editors, even if they don't choose to become normal sysops. WhatamIdoing (talk) 03:57, 8 August 2018 (UTC)
• Strong oppose option 1. Several posts above note that RfA "gives a baseline indication of the trust the community has in an editor" (to quote Callanecc); I agree with that. However, RfA is a higher bar than just trust: it requires editors to demonstrate interest & competence in some non-technical areas that are irrelevant to the main uses of this permission. I would probably seek intadmin myself to continue the gadget work I'm already doing; requiring RfA would, in my opinion, be an unnecessarily high barrier. I agree strongly with what WhatamIdoing said above, as well. Enterprisey (talk!) 03:52, 9 August 2018 (UTC)
• Support Option 2 While administrators already have (but soon will not, due to this new right) the ability to edit site-wide JS/CSS, a non-admin could be trusted with this right. (As mentioned, this is similar to the edit filter manager group, where most, but not all, members are also admins.) ^Semi_Hypercube ✎ 21:03, 12 August 2018 (UTC)
• Support 2. The tasks expected of administrators and interface administrators are different enough to be placed into separate scopes. With option 2, interested editors are evaluated solely on the privileges they are requesting, which is a model that has been shown to work in WP:PERM. Option 2 also takes into account the need for community trust in both of these roles, and reduces the amount of bureaucracy needed to have the community assess this trust. — Newslinger talk 22:27, 12 August 2018 (UTC)

This is a bigger deal than you seem to think

An admin (after the rights change is completed) or an edit filter manager can temporarily break editing on a wiki, possibly add some vandalism or scare away some editors. That's not good, of course. But someone with this right can steal accounts, install bitcoin cryptocurrency mining JS that runs for every page view, install trackers that violate the privacy policy, and so on. That's a lot worse, and is why this rights split is being done by Wikimedia. IMO we probably should have something akin to an RfA process for this right, with two aspects: evaluate the trust that they won't do the above kind of stuff, and evaluate the technical skill of the applicant that they actually know what they're doing. The exiting RfA process doesn't generally look for the latter. Anomie⚔ 02:03, 31 July 2018 (UTC)

(+1)-I will prefer a BAGRFA like process. ∯WBG^converse 05:17, 31 July 2018 (UTC)

• And there should be a demonstrated need: the person has either done it before or can show what they would do if granted the right. Johnuniq (talk) 05:50, 31 July 2018 (UTC)

Is the bitcoin mining thing actually a concern? I'm pretty sure that the commercial value of dumping a full-screen ad on the main page (or all articles via widely-used template or interface message) dwarfs that of having JS mining cryptocurrency. --Yair rand (talk) 06:40, 31 July 2018 (UTC)

The issue is that a rogue or compromised account could install JavaScript that would be executed by almost every person visiting or editing Wikipedia. One of the least damaging results might be that computers belonging to readers and editors run more slowly because they are running mining software. There are a lot worse things that could result from malicious script. There is also the possibility of an interface admin being coerced into handing over their password. I believe there was a case where that happened: reminder anyone? Johnuniq (talk) 07:18, 31 July 2018 (UTC)

A full-page ad would be a lot more obvious to end users and get removed more quickly than something subtle like a mining script. --Ahecht (TALK
PAGE) 13:33, 31 July 2018 (UTC)

I perhaps misspoke in writing "bitcoin" to mean generic cryptocurrency mining. But someone (at least once) didn't think it wasn't worth it. Anomie⚔ 18:47, 1 August 2018 (UTC)

• Part of why I think this is a bigger deal than WP:EFM is that while EFM can affect a large number of edits, it principally only affects the encyclopedia. Abuse of the edit filter can cause quite a mess, to be sure, but it is one that we can fix ourselves. However site-wide javascript is code executed by a reader's computer and a malicious/compromised TechAdmin account can use known (or currently unknown) javascript exploits to install malware on readers computers without their consent or use Wikipedia to create a botnet. For example, since 2016 we've known of a ransomware application written in 100% javascript: IT Pro Portal. If compromised javascript infects a user's machine, we cannot fix that by reverting like we can most admin and edit filter abuse. A reader's files can be encrypted and lost or be forced to pay money to retrieve them, their financial passwords can be taken, corporate or governmental intranets broken into, the list of dangers of toying with client side code goes on and on. This poses a serious security threat beyond the encyclopedia, and is far weightier than EFM or even most admin tools. We should take a lesson from Facebook's ongoing data breach fallout before we disregard the potential issues of this beyond whether we trust the bit holder or not. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 23:15, 31 July 2018 (UTC)

Technical skill

I would just like to point out that not all regular edits to MediaWiki:***.js actually need any knowledge of javascript. Updating of geonotices being a good example. -- KTC (talk) 08:18, 6 August 2018 (UTC)

That will eventually be moved to JSON pages, which they non-interface admins will be able to edit. See phab:T198758. Any other JS pages that only involve simple key/value pairs should follow suit. For the time being, handing out interface admin rights to some of these people is probably okay, but not in the long-term. — MusikAnimal ^talk 18:55, 7 August 2018 (UTC)

Stop gap option

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The necessity for this group is expected to go live in one month. As our RFC's here can tend to take a long time to settle, I propose a stop-gap process: authorize our bureaucrats to issue interface administrator access to any current administrator requesting access at WP:BN but with a 60 day expiration. Requests will remain open for at least 24 hours, if any 2 administrators object it will be declined. Access to be removed if a desysop occurs, upon self-request, per a WP:AN consensus, or per ArbCom. This option to expire upon the creation of the more formalized process being discussed above. — xaosflux ^Talk 13:30, 31 July 2018 (UTC)

• Support But I would drop the 60 day expiration bit and make this the actual policy rather than a stop gap. TonyBallioni (talk) 16:15, 31 July 2018 (UTC)
• Or, to stop beating around the bush, just grant it to TheDJ, MusikAnimal, Mr. Stradivarius, MSGJ, Krinkle, and perhaps yourself until we've settled on a fully-fledged policy. With the exception of a few one-offs, they are currently doing the lion's share of maintaining these pages, so the community already implicitly and explicitly trusts them. There is unlikely to be any reasonable opposition to that list when the time comes. ~ Amory (u • t • c) 16:39, 31 July 2018 (UTC)
  • Yeah, I'm fine with that as well, though it seems like we have a rough consensus for something like what Xaosflux was proposing above, so I'm going to update the page accordingly and see if we can get an RfC together that will let it go through. @Xaosflux and Amorymeltzer: since the list of people who are likely to be approved under this process is pretty limited and we could count them on our fingers, I think the 60 days thing is just creating more work, so would suggest we not have the expiration at first so we don't have to go through the process of the same people who will get it having to apply again through any new process. Thoughts on this? TonyBallioni (talk) 19:35, 31 July 2018 (UTC)
    • @TonyBallioni: my only point of this section was to have something in case the RFC above was going to go long so we didn't run in to a maintenance gap and have to come up with "emergency plans", as us 'crat critters like to have a clear community mandate for our actions. If you think the issue will be solved above well in time this won't be needed. — xaosflux ^Talk 19:39, 31 July 2018 (UTC)
      • I think the community could get behind an initial process like you described so the 'crat critters will have something to follow, and then can make adjustments as needed after that, which could include a more formalized process. The big thing with most of the new user rights and other proposals is getting something together that people can !vote on, and then changes can be made as needed after there is a starting point. TonyBallioni (talk) 19:44, 31 July 2018 (UTC)
      • Yeah, I'd agree that I don't really think we'll have an issue meeting the deadline. But if my (only slightly tongue-in-cheek) suggestion goes forward, the deadline won't be an issue at all, since those editors are the ones making most of the edits anyway. There's some consensus developing above for the "only sysop" option, and it seems more are fine with the overall picture of receiving the rights. It shouldn't be too hard to hash out the contours (required questions or statement, 24/48/72 hours, 2/3 opposes, etc.) in a timely manner, and get a few more folks in there. ~ Amory (u • t • c) 22:53, 31 July 2018 (UTC)
• IMO this proposal is too loose, since as written it says any admin, even someone who never edited JS before, can have it for the asking as long as no one happens to object. I like Amorymeltzer's better: give it to the few people currently using it until we have a full policy decided. Anomie⚔ 18:50, 1 August 2018 (UTC)

  @Anomie: these admins currently have this access - so I was only proposing a temporary stop gap in case this goes long, the existing "active" editors on this should be able to keep up with any protected-edit-requests as well. Speaking of which ... would you mind adding integration to User:AnomieBOT/PERTable or a similar page - I know I find those reports to be extremely useful. Thank you! — xaosflux ^Talk 20:42, 1 August 2018 (UTC)

  It looks like you already have special highlighting for that, probally best to leave on the PROT report that is watched then to split to an IPROT report anyway. — xaosflux ^Talk 00:56, 2 August 2018 (UTC)

  If we do wind up having a discussion about creating a {{Edit interface-protected}} and Category:Wikipedia interface-protected edit requests or something like that, let me know. Anomie⚔ 12:28, 2 August 2018 (UTC)

• Support, with Tony's addendum. Vanamonde (talk) 05:08, 5 August 2018 (UTC)
• Support, with the addendum. Lots of people edit the geonotices, and I am unconvinced that we need fewer volunteers there. Making geonotices fixes go through an editprotected queue has no advantages I can think of. —Kusma (t·c) 14:09, 6 August 2018 (UTC)
• Counter-proposal - A simpler and more practical stop-gap would be to have the bureaucrats issue interface administrator access to MusikAnimal's list of people who have actually edited the sitewide JS/CSS in the past year. Kaldari (talk) 18:23, 7 August 2018 (UTC)
• Support any of these options as a temporary approach. Amorymeltzer's proposal might be my first choice, but Kaldari's broader approach is good, too. (Does anyone know whether any gadgets/popular user scripts are maintained outside of the main maintainer's userspace, but which wouldn't get picked up in that query? I'd add those editors, too.) WhatamIdoing (talk) 04:05, 8 August 2018 (UTC)
• I'm OK with any of these stopgap measures. Worth noting that Krinkle and Isarra are global interface editors and not local admins, who would not need to be added to the group to retain access. Though that might suggest that there are cases where non-admins might want to help out... ;-) -- Ajraddatz (talk) 16:54, 8 August 2018 (UTC)
• I support stopgap proposals to allow administrators to receive this right for 60 days after a request at BN. The specific details are not extremely important to me. Kevin (aka L235 · t · c) 06:39, 12 August 2018 (UTC)
• I support in order, Kaldari's counter-proposal (all admins who've edited sitewide JS/CSS in the past year as stopgap), then the basic 60-day-by-application stopgap. I think either way the broader community should take its time to decide on a more permanent policy, so that gives me pause on Tony's proposal, despite not strictly objecting to it. Since it's relevant: I'm one of the admins listed in the "past year" query, and will apply for this permission if not given it as part of the initial rollout. {{Nihiltres |talk |edits}} 22:16, 20 August 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A simple proposal

The ability to edit site-wide CSS/Javascript or help individual users with it is one that has historically been entrusted to administrators. I haven't often used it, but I have in a couple cases to help users who had borked Javascript in their personal .js files. So, how about a simple proposal:

• Any administrator may request access to this user group, and absent reasonable objection or suspicion of account compromise, will be granted it. We've been able to do it for years, and I really don't know of any instance of an admin doing something malicious with it. If we can't trust even our admins to not do something harmful to the project, we may as well pack it in and go home right now.
• Any non-admin wanting access to the group must be carefully vetted. Generally speaking, such access should require an RfA-like level of trust, because of the implications of having access to such a powerful interface. I would generally want to see someone with such access show community trust at RfA. It isn't like template editor, this right is even more powerful and even more dangerous. There may be a rare circumstance in which a non-admin would have such permissions, but such an instance should be very much an exception.

Seraphimblade ^{Talk to me} 01:47, 5 August 2018 (UTC)

• Comment I'd like to support this, as it makes sense to me. I really do not see the need for an RFA-type process, as most users are not qualified to judge the technical requirements. That said, two points hold me back: if the approval process is lightweight, we should have a similarly quick removal process; and IAdmins should be required to have 2FA enabled. Vanamonde (talk) 05:18, 5 August 2018 (UTC)
• There have been several recent instances of an attacker managing to compromise an admin account and using the ability to edit site JS to expand their access. Giving the new group to every admin ("suspicion of account compromise" seems pointless since that should result in emergency desysop anyway) on request would defeat the purpose, which is to reduce the attack surface by only giving the right to people who actually use it. Anomie⚔ 13:09, 5 August 2018 (UTC)
• Oppose +1 to Anomie. This proposal is fine in theory but it would defeat the purpose. We've discussed this above, but I'll toss in my thoughts here, too: I really don't know of any instance of an admin doing something malicious with it It has happened and it can happen again. So, we are trying to reduce the number of accounts (attack surface) for which it can happen. The admins who actually edit site JS/CSS are few and far between, so if this is handed out as intended, most admins will go their entire wiki career without noticing they don't have this ability. If we can't trust even our admins to not do something harmful to the project Indeed, most admins will never do intentional wrong. But many have poor account security, and rare as it may be, an admin gone rogue can't really cause permanent far-reaching damage, except through JS/CSS. Any non-admin wanting access This is what #Sysop as requirement is about. You may wish to !vote there accordingly. Kind regards — MusikAnimal ^talk 17:07, 5 August 2018 (UTC)
• Support, absent reasonable objection or suspicion of account compromise indicates a vetting process, just one done at WP:BN. I see no reason to assume that having a second RfA will result in a more useful process. However, I see zero reasons to admit non-admins to this group, and everybody trustworthy enough to be in this group should be given +sysop. —Kusma (t·c) 14:05, 6 August 2018 (UTC)
• Oppose the non-admins portion at this time as it creates a situation where they can create pages that normal admins can't delete, and they can also not delete. — xaosflux ^Talk 14:12, 6 August 2018 (UTC)

  Not sure that's a huge concern. Global interface editors can do this already, and there are a few of them active here over the years. So this is already a "problem", but obviously it hasn't been an actual problem over the years. The only concern would be if we only had non-admin intadmins, because then there would be no local users who could delete. -- Ajraddatz (talk) 16:51, 8 August 2018 (UTC)

  @Ajraddatz: not huge, just don't think its a good idea. GIE's can not currently create pages that our admins can't delete (please provide an example if I'm missing something). — xaosflux ^Talk 00:25, 9 August 2018 (UTC)

Overall / Per-admin stats

It took a little while (and a lot of tinkering) to generate - but I've come up on stats based on actual use for js/css including outside-of-the-admin's-own-userspace (which I don't think I've seen anyone present to date: User:SQL/Admin_CSS-JS_Editing. One thing that can inflate stats a bit is going to be renames. SQL^{Query me!} 00:47, 6 August 2018 (UTC)

What do the numbers look like for the past year/three years of edits? RHaworth, for example, has one edit in general userspace outside his user space to a JS/CSS page (that's User:Cyberpower678/RunI.js) within the past year or two. --Izno (talk) 00:57, 6 August 2018 (UTC)

Soooo, MusikAnimal points out - I wasn't grabbing edits, but **pages edited** due to a distinct from single-user testing making it thru. Once the current run is done, I can have it do those too. SQL^{Query me!} 01:03, 6 August 2018 (UTC)

Removal of permissons

A few comments on the proposed - It seems reasonable to have a higher activity requirement for the interface administrator permission than just sysop - 3 months without editing should be enough to remove the permission, although one could go to the step of requiring at-least one JS/CSS edit in the past 3/12 months. Something along the lines of allowing requesting back at WP:BN as long as two years haven't passed without activity seems reasonable to me too.

On the removal of permissions for misuse, while for emergency situations it is fine for crats to remove the permission, IMO in general ARBCOM should decide as with any other advanced permission Galobtter (pingó mió) 16:38, 30 July 2018 (UTC)

12 months is our standard in general, and I can foresee having people who are sysops on this project but don't edit that often because they are more involved on other projects needing it (i.e. they happen to be en.wiki sysops, but they are much more active as a MediaWiki developer, on meta, etc.) TonyBallioni (talk) 16:44, 30 July 2018 (UTC)

My feeling is that this should definitely have a higher activity requirement than regular sysop, especially as the process for granting is much easier (and re-granting even more so), and the whole point of having this as a separate right is for security etc. One edit to JS/CSS every 12 months could handle that case I think. Galobtter (pingó mió) 16:58, 30 July 2018 (UTC)

• Oppose requiring ArbCom for non-emergency removal - Pretty sure EFM can be revoked by consensus at AN. Techadmin should be similar, especially if the granting process required the same level of noticeboard-discussion-consensus. Of course if sysop is a prerequisite for techadmin, any actual misuse will surely lead to an Arbcom desysop anyways. But I could think of a situation where a sysop and techadmin is being maybe lightly disruptive, unhelpful, toxic, battlegroundy, etc. around techadmin discussions which might warrant community removal of techadmin flag but not necessarily an ArbCom desysop. Neutral on any specific inactivity removal/reinstatement thresholds, whatever works and isn't controversial can be implemented for now and can be refined later if need be. Ben · Salvidrim! ✉ 16:47, 30 July 2018 (UTC)

Consensus at AN for removal seems reasonable to me too. Wasn't able to really think of many cases where you would remove techadmin but not admin, though that you posit is certainly possible. Galobtter (pingó mió) 16:58, 30 July 2018 (UTC)

Agreed - it should be relatively easy to remove. SQL^{Query me!} 21:17, 30 July 2018 (UTC)

• Regarding a requirement for recent Javascript or CSS edits, I don't believe there is a lot of churn on the global pages: the last fifty edits of MediaWiki:Common.js goes back to 2014, and the last fifty edits of MediaWiki:Vector.css goes back to 2013. So I think we'd largely restrict the pool of potential interface administrators to those engaging in active gadget development, which may not be desirable. Regarding a requirement for recent activity in general (3 months), I'm not sure if this is really needed, either. isaacl (talk) 17:04, 30 July 2018 (UTC)
  • On the other hand, it would be good to have an inactivity requirement tied to actual JS/CSS activity so someone who has moved on to other areas of the project doesn't unnecessarily keep the dangerous rights. Anomie⚔ 13:16, 5 August 2018 (UTC)
    • To put it another way, I suspect there may not be enough changes on the site-wide Javascript and CSS files to keep more than one person active at a time, which means a potential bottleneck should important changes need to be implemented quickly. If the risk of undetected compromise is deemed extremely critical to manage, perhaps the process should be turned around: identify a pool of qualified editors, but only assign the interface administration privilege for the period of time when they are making an edit, and remove it immediately afterwards. isaacl (talk) 13:32, 5 August 2018 (UTC)
      • Yeah, I've been thinking toward something like only granting the permission for 1 year at a time and each editor using it needs to actively reapply to keep it. --Izno (talk) 14:14, 5 August 2018 (UTC)
        • The question is what risk are we trying to guard against? If we want to ensure that the editors are regularly logging in so they might detect a compromised account, then an inactivity criterion may be useful. If it's a question of having current Javascript and CSS skills, maybe it's easier to just have the current group of interface administrators regularly vet each other. If it's trying to absolutely minimize the risk of undetected changes, then just assigning the privilege for the period of time to make the edit and then removing it again would be safest. (This would be in parallel with whatever process is in place to determine who is in the pool of qualified editors.) isaacl (talk) 14:40, 5 August 2018 (UTC)
• An inactivity requirement is surely needed, and should be more strict than adminship. 3 months sounds fine to me. We'd go off of any logged action, not inactivity of editing site JS/CSS, because not many edits are made there as it is. Misuse can be discussed at WP:BN or the like. Emergency removal would happen only if the account is compromised, but in that case the account would be locked anyway — MusikAnimal ^talk 01:13, 31 July 2018 (UTC)
  • Would the intent of having an activity frequency be to ensure the interface administrator was regularly logging in, so they could check for any apparent security break-ins? Or is there some reason why regular logged administrator actions is desired? isaacl (talk) 01:38, 31 July 2018 (UTC)
    • I think MA was using it because we can't detect when a user last viewed the project unless they do something. A logged action or edit would suffice to show they had actively done something. ~ Amory (u • t • c) 01:49, 31 July 2018 (UTC)
      • Yes, an edit would indicate activity. Perhaps I misunderstood "any logged action" as referring to logged administrative actions? isaacl (talk) 02:22, 31 July 2018 (UTC)
        • Sorry for the confusion. When I said "logged action", I meant any sign of activity. This would include edits, administrative actions, marking a page as patrolled, abuse filter modifications, etc. — MusikAnimal ^talk 02:37, 31 July 2018 (UTC)

“Permission should be removed by local bureaucrats” - Support: at present, this has to be done by a steward. —MBq (talk) 09:54, 1 August 2018 (UTC)

@MBq: our bureaucrats are able to add and remove this access. On wikis with crats being able to remove sysop this was maintained. — xaosflux ^Talk 10:55, 1 August 2018 (UTC)

RFC participants

@SoWhy, NinjaRobotPirate, Xaosflux, Ahecht, MusikAnimal, Mz7, MelanieN, WhatamIdoing, and Johnuniq: You all commented at WP:VPM#RFC: Interface administrators and transition with some opinion or another. You may wish to provide feedback here. --Izno (talk) 00:32, 31 July 2018 (UTC)

The link to this talk page on Centralized discussion

I'm pointing the Cent link to a specific topic heading: Proposed access requirements, so we can know when the discussion is finished even if this talk page continues to be active.

(Perhaps someone may wish to move some topic on this page to be a subtopic under that heading due to this.) --Pipetricker (talk) 16:09, 31 July 2018 (UTC)

WMF raises connection between this user right and Superprotect

In Phabricator task T190015 creating this user right, the WMF says:

The obvious solution for this is to split Javascript editing into a separate, dedicated user group, take away the right from all other user groups (sysop, interface-editor/engineer/templateeditor on some wikis), clearly document the risks of handing out that user group, and set higher expectations for membership (e.g. use of two-factor authentication). There is some paranoia around this issue (some people an attempt to revive Superprotect behind anything that changes Javascript editing workflows) but it is unlikely that many editors will be concerned as long as it is made clear that the power to assign Javascript editing capabilities is left with the local communities.

The WMF became particularly interested in creating this user right during the Superprotect incident. Since that time I have repeatedly asked the WMF for any kind of dispute resolution plan for handling a WMF-Community disagreement in the future. They have been unwilling or unable to provide any meaningful answer. This is not an idle concern:

The WMF has been making efforts to "deprecate wiki syntax as the primary input method" since 2011.[1] In Phabricator T102398[2] I noticed that the WMF planned to switch wikis from giving users two EDIT links (one for Wikitext editor and one VE), and instead providing users only one EDIT link. I asked: Jdforrester-WMF, could you please clarify? It's very possible I'm misreading this, but it sounds like you just declared an unconditional force over of all wikis to a VE-default as part of the single-edit-tab project.[3] I was assured: ...Obviously we're not going to just do it without talking to the wikis first.[4] When the software was deployed, it removed the Wikitext EDIT link and did in fact default the only remaining edit link to VE. I, and other editors, spent over a week trying to contact the WMF. We were unable to get any response. I had to take the issue to the WMF Executive Director. We were then told that the VE default was a bug, and assured that all issues would be addressed. After a weak with no action the manager then said his original plan was to set VE as the default, and that he was now unwilling fix it. One of us then wrote (but did not deploy) a Javascript bugfix from our end. (The WMF explicitly said it was a bug!) The WMF then reluctantly agreed to fix the bug from their end.

With this new user right the WMF can prohibit us from fixing issues by revoking Interface permissions, which is merely redeployment of Superprotect under another name!

To re-quote: it is unlikely that many editors will be concerned as long as it is made clear that the power to assign Javascript editing capabilities is left with the local communities. Nope. That does not address my concerns at all. The concern is revoking the user right. If the WMF has no intention of revoking this user right for Superprotect-purposes, perhaps we can negotiate sufficiently strong assurances that it will never be used in such a fashion. Do other editors share my concern that exceptional assurances are necessary? Or should I drop the topic? Alsee (talk) 15:48, 1 August 2018 (UTC)

The WMF has no control over the assigning or removing of these permissions, so I don't think there is anything it worry about. This change also was not mandated by WMF leadership, so it is unlikely to be some backdoor effort to take control of the interface away from the community. I changed my earlier comment because it wasn't as nice/effective as I hoped it would be. -- Ajraddatz (talk) 16:01, 1 August 2018 (UTC)

WMF can change any user groups by office action, so could remove all interface admins unsympathetic to it. This separation, while good for promoting security, thus also allows the WMF to prevent community JS interventions in the name of security, in a more PR-friendly way than reinstating superprotect. The key for the community is to not allow the interface admins to become a tiny clique dominated by, for want of a better phrase, WMF sympathisers. BethNaught (talk) 16:34, 1 August 2018 (UTC)

Which doesn't change under interface-administrator-dom. They could have done just the same with the administrator user right. This looks like a conspiracy theory to me. --Izno (talk) 16:41, 1 August 2018 (UTC)

Izno, currently if the WMF wants to war against a consensus Javascript edit, they have to threaten to revoke any and all admins who would follow consensus. Revoking admins would be a shitstorm. With this change they could be far more tempted to revoke *just* the interface permission, hoping to get away with a smaller backlash. Note: Even if this is a misguided conspiracy theory, if the WMF would never use this new page-protection to win an edit dispute by force, it costs them nothing to give strong assurances that they won't use it this way. Alsee (talk) 18:10, 1 August 2018 (UTC)

At what level does an organization get to refuse to address misguided conspiracy theories? Do we need the WMF to give strong assurances that they aren't being run by Lizard People too? --Ahecht (TALK
PAGE) 18:21, 1 August 2018 (UTC)

It would also cost them nothing to say one thing and then do something else. There would be no precedent for the WMF to remove interface-admins on a wiki (they can remove CUs because they govern access to non-public info), and even if they did, stewards and global-interface-admins would still be able to implement changes requested by the community. This isn't an area of WMF control, and superprotect is a thing of the past. The comments about superprotect above were, ironically, probably intended to recognize this potential concern from the community.

And a little note on being a WMF sympathizer: I find that the further up you go on the community "hierarchy" for lack of a better term, the more your view on the WMF changes. Undoubtedly there have been things that they've done wrong in the past, but the WMF exists to support the community - not the other way around. The WMF provides direct support to the steward team, handling cases that we don't have the capacity or scope to, and providing technical support to develop new tools for the community to use and resolve security issues. I know I won't convince any of the WMF-is-evil crowd, but please take a walk outside and ponder how we might not live in a world where one side is totally good and one exists only to torment the other. We're all complex humans trying to work towards the same goal. We will accomplish more by having mature conversations than demanding assurances and taking things out of proportion, like I think this discussion is doing. -- Ajraddatz (talk) 18:22, 1 August 2018 (UTC)

I never said that the WMF is evil, or that it exists only to torment the community, and I do not believe those things. However, it is uncontrovertible that some senior staffers have acted disingenuously with regard to past deployments, and that community JS interventions were and remain an important check and balance on WMF technical power. Therefore the community should be careful to retain a good number of users able and willing to implement such interventions. Also, as I noted, "sympathisers" is a poor phrase; but I would not want to end up in a situation where all or most of the interface admins have links with the WMF strong enough to prevent them implementing a community intervention or to induce them to actively prevent such. BethNaught (talk) 18:52, 1 August 2018 (UTC)

Yes, there have been negative actions from them in the past. I would argue that office actions have not and would not be used in that way. First of all, WMF-mandated removal of advanced permissions requires approval right up the WMF chain of command, so it's unlikely that an office action could be done quickly enough to remove community control or be done by a few rogue agents trying to implement technical control. Second, all office actions as they relate to permissions removal are overseen by stewards (and I assume local arbcoms too), in that we are informed of the rationale for them and when they will occur. Of course, it's possible for the WMF to ignore all existing processes if they wanted to restrict community control, but if they really wanted to then they just would. They have no need to go through back channels like this, when they have complete control of the servers and could just mandate that change whenever they wanted to. The point I was trying to make above is that their goal isn't to restrict community control, it's to empower the community. We're on the same side. And until the WMF actually takes action to remove community control, there isn't much need for us to be concerned with it. Because we won't be able to do anything but complain either way. -- Ajraddatz (talk) 19:02, 1 August 2018 (UTC)

• Please do not derail this important process with fairy tales about big bad WMF. They don't need an evil new group to do whatever they want. There really is a need to protect the project against the likelihood of an attacker getting access to an admin account in order to spread malware via scripting. Johnuniq (talk) 00:50, 2 August 2018 (UTC)

  The WMF did not have the ability to do whatever it wants. Superprotect did not actually prevent admins from editing JS, because the software is built around admins being trusted. Preventing admins from having absolute control over the interface without wrecking the site would require putting in extensive engineering work over a long period of time, which is what they're doing now, ostensibly without the last step of actually removing community control. We're not dealing with "fairy tales"; the WMF has, in the past, unambiguously denied the validity of the community veto over all aspects of the interface. Things have changed since then, but there's no guarantee that it won't change again. Previously, they could not remove community control. Now they can. This matters. --Yair rand (talk) 01:16, 2 August 2018 (UTC)

  I think Yair rand has a fair point. --Nemo 05:21, 24 August 2018 (UTC)

• I'll withold my judgment of the WMF ih this instance. I have more than enough direct experience with them to know that while they may not be evil, their motivations are clearly and provenly not always the best for the projects and/or the volunteer communities who build and maintain them. I'll just repeat my earlier caveat that this CSS/js maintenance has been carried out discretely for years by a small group of reliable users, and the creation of a new user group will cause a stampede of hat collectors if not managed with discretion. Kudpung กุดผึ้ง (talk) 01:29, 2 August 2018 (UTC)

• WMF Paranoia--I'm not a much fan of WMF's approach as to the liaosoning between their devs and the editorial community,which often leads to stupidity,all around.But, it's hardly fair to view everything through the same shades and generate conspiracy theories,at will.∯WBG^converse 05:53, 2 August 2018 (UTC)

As a Less Important Consideration

• What would we consider the logical descriptor for interface administrators right be described as? I suggest the robo-mop Nosebagbear (talk) 17:04, 3 August 2018 (UTC)
  • "Robo-mop" to me would mean something to do with bots, not interface editing, so that would not be a good descriptor. Thryduulf (talk) 08:21, 5 August 2018 (UTC)

    It does sound cool though :) Galobtter (pingó mió) 08:28, 5 August 2018 (UTC)

    Obviously, it could be something like a squeegee, as interface admins edit the way users see the wiki through the interface, like how a squeegee is used to clean a window that people see through (is that a bad analogy? It seems logical, but it might not be). ^Semi_Hypercube ✎ 00:22, 9 August 2018 (UTC)

  Wrench or screwdriver, maybe? They're associated in my mind with "technical" roles like this one. Enterprisey (talk!) 03:42, 9 August 2018 (UTC)

• A wrench sounds a bit "blunt" for their technical role (as opposed to, you know, a robo-mp ;) ) - but perhaps a different tool, like pliers or, more nerdily, an Allen key, since that gives us a ready name for them. Nosebagbear (talk) 12:36, 9 August 2018 (UTC)

  Allen key, hex key or spanner (for across-the-pond compatibility) work fine for me. Enterprisey (talk!) 13:26, 9 August 2018 (UTC)

  Also, wrench and screwdriver are already used for both bureaucrats and edit filter managers anyway. ^Semi_Hypercube ✎ 21:34, 9 August 2018 (UTC)

  @Nosebagbear: Also, was the pun of the wrench being "blunt" intended? ^Semi_Hypercube ✎ 21:37, 9 August 2018 (UTC)

• ^Semi_Hypercube...damn, I wish I could say it had been! Nosebagbear (talk)

• Spanner doesn't seem suitably technical. In the Allen key wiki page, it suggests that it is actually better known as allen than hex in the USA - which is interesting, since I've never heard it be called anything else, and I'm a Brit. I'm too nervous to ask the random people around me which term they prefer, but off this very small sample size, Allen key seems fairly cross-atlantic, if nothing else. Nosebagbear (talk) 09:17, 10 August 2018 (UTC)

• I would not choose an Allen Key, solely because I don't think it would be very distinctive in image form --Danski454 (talk) 09:25, 15 August 2018 (UTC)

• @Danski454: - putting aside my technical comment, a spanner, as seen in the pic below, seems fairly similar to a wrench - you might be right about an allen key's distinctivness, but I think a spanner runs the same risk. It sort of looks like half the 'Crats' (that's two apostrophes, btw) one.

• (New Thought) - how about a Caliper? I think it is both distinctive (probably, like the other tools, slightly "simplified" in appearance), and suitable. Nosebagbear (talk) 13:14, 15 August 2018 (UTC)
• Since versions of the HTML5 shield have become widely used as CSS and Javascript logos, it might make sense to use a shield instead of yet another permutation of hand tools. --Ahecht (TALK
  PAGE) 17:31, 15 August 2018 (UTC)

Possible images

• 
  Using spanner - by Danski454
• 
  Using pliers
• 
  Using caliper
• 
  Using shield
• 
  Spanner & mop

@Danski454: I like the pliers (spanner a.k.a. wrench is already used for bureaucrats and edit filter managers). Could you perhaps also make an image with a caliper like User:Nosebagbear suggested? ^Semi_Hypercube ✎ 13:50, 15 August 2018 (UTC)

I do like the pliers, but if someone with both more than my lack of artistic talent and better at uploading to wiki can make the caliper equivalent to compare that'd be massively appreciated :) Nosebagbear (talk) 14:03, 15 August 2018 (UTC)

@Danski454: I think the caliper should look less flat (look more like the spanner and pliers in the other images in terms of shading—it currently looks way out of place). ^Semi_Hypercube ✎ 15:08, 15 August 2018 (UTC)

@SemiHypercube: I have added shading to the image --Danski454 (talk) 15:33, 15 August 2018 (UTC)

Pliers I do like the pliers better, but I think the caliper could also work. (Not like I'd ever have this right anyway, I'm just commenting) ^Semi_Hypercube ✎ 15:37, 15 August 2018 (UTC)

I like the pliers so far. — xaosflux ^Talk 18:41, 15 August 2018 (UTC)

• Pliers I agree - I think the pliers are the best, with the calipers the second best (I suspect my calipers would go missing less if they were bright turquoise) Nosebagbear (talk) 14:29, 16 August 2018 (UTC)

I'd also like to thank @Danski454: for his graphical work Nosebagbear (talk)

• Pliers I also prefer the pliers --Danski454 (talk) 14:33, 16 August 2018 (UTC)

• What should the logo be for the new interface administrator group? ^Semi_Hypercube ✎ 23:03, 16 August 2018 (UTC)

Just added my $0.02 in bold to make it easier for whoever looks over this in a few days. Nosebagbear (talk) 23:10, 16 August 2018 (UTC)

I removed the RfC template that was added here. Choosing a logo for the group is probably the lowest priority issue on this page. Let's not distract attention from the more important discussion about how we're even going to implement this group on the English Wikipedia. Mz7 (talk) 04:19, 17 August 2018 (UTC)

@Mz7: - clearly you lack judgement on assessing priorities ;) Nosebagbear (talk)

Especially since those pliers seem to have unanimous consent so far. :P Barring any loud objections, I'm guessing we should probably just roll with those. Mz7 (talk) 04:26, 17 August 2018 (UTC)

What about this image? This too looks appropriate to the usergroup. --✝iѵɛɳ२२४०^{†ลℓк †๏ мэ} 08:39, 17 August 2018 (UTC)

I've moved the image into the gallery as Spanner & mop --Danski454 (talk) 10:47, 17 August 2018 (UTC)

I get the general gist/justification of the spanner/mop combo, but I still think it both risks confusion and, that aside, will work less well when shrunk to the usual sizes. Nosebagbear (talk) 11:53, 17 August 2018 (UTC)

@Nosebagbear: By the way, I found this topicon and this userbox, which were made a few days before this thread was started and use a completely different image. Perhaps you could give your opinion on the image used? Also pinging @Danski454: because they created some of the images. (You could also change the image in the templates) ^Semi_Hypercube ✎ 16:40, 20 August 2018 (UTC)

While I do quite like it - the pick-like "lower" tool (you can tell I'm a DIY expert) is nice, but I'm not sure about the whole set. I still prefer the pliers, though I'd be open to a 2-tool crossed one, including the pliers, though that's only a guess at this point. Nosebagbear (talk) 17:05, 20 August 2018 (UTC)

I don't like that image, it looks too realistic. --Danski454 (talk) 17:25, 20 August 2018 (UTC)

Also, @Danski454:, if there is near unanimous support for the pliers, do you think you could make the background on the image transparent? ^Semi_Hypercube ✎ 16:29, 21 August 2018 (UTC)

I have tried to remove the background, but when I upload the image to Wikipedia the background reappears. I have also tried to create an svg: File:Wikipedia Interface administrator.svg, but that does not work. If anyone wants to try to make the image the pliers I used are here: [5] --Danski454 (talk) 09:41, 22 August 2018 (UTC)

Tracked in Phabricator
Task T198370

@SemiHypercube and Danski454: Transparent PNGs are currently broken on Wikipedia and Wikimedia commons. There is no ETA for a fix. See T198370. I did, however, fix the SVG for you. Whatever program you used to generate it, I would highly suggest Inkscape next time. What is the source of the CC0 pliers image? Even if no attribution is required, linking to a source from the file page is needed to provide evidence of permission. --Ahecht (TALK
PAGE) 18:22, 22 August 2018 (UTC)

I have added the source of the image. --Danski454 (talk) 19:02, 22 August 2018 (UTC)

Password strength requirements

I think its obvious that people with this right be expected to comply with the password strengths requirements expected of admins and bureaucrats, but I feel this should be written down somewhere. --Danski454 (talk) 15:50, 4 August 2018 (UTC)

The page currently says: (choosing strong unique passwords, not getting infected by malware, preferably using two-factor authentication). I made it a little more clear that it was talking about the interfaceadmin's own account, is that sufficient? If, as it seems likely, all interfaceadmins are current sysops, the PSRs will apply. ~ Amory (u • t • c) 19:33, 4 August 2018 (UTC)

I'd go one step further. If you want interface admin, 2FA is mandatory in addition to following WP:PSR. Tazerdadog (talk) 21:54, 5 August 2018 (UTC)

If this right should have the same password and security requirements as admins, then I would prefer a more descriptive section that is similar to WP:ADMIN#Security, rather than the two sentences that was essentially copied from Meta:Interface administrators. (e.g. there should be stronger language like: Because editing CSS/JS executed in other users' browsers is very powerful and potentially dangerous in the hands of a malicious user, a compromised account will be blocked and its privileges removed on grounds of site security.) Zzyzx11 (talk) 01:32, 6 August 2018 (UTC)

Just to follow-up on this, interfaceadmins have the same strong password requirements as sysops and bureaucrats, that's coded in. ~ Amory (u • t • c) 19:49, 7 August 2018 (UTC)

Permissions question about dealing with inappropriate user JS/CSS

Will regular administrators still have the ability to modify/delete individual users' JS/CSS pages? We had some problems at MfD a couple months ago where a couple of users had copy/pasted copyrighted code into their personal JS pages (or were using their personal JS pages to webhost JS code they were retaining copyrights over; it was unclear which), and I'm slightly concerned that if only a dozen or so people can delete pages like that, it might become difficult to deal with them. I'm concerned this might develop into a similar situation to the edit filter managers, where I need to ping specific EFMs to false positive reports requiring their attention because none of them ever bother to check the page, and legitimate false positives just went unaddressed. —Compassionate727 ^(T·C) 17:00, 4 August 2018 (UTC)

Regular admins can delete JS/CSS pages but not modify them Galobtter (pingó mió) 17:02, 4 August 2018 (UTC)

Cool, thanks. —Compassionate727 ^(T·C) 17:03, 4 August 2018 (UTC)

@Compassionate727: Galobtter is incorrect. To delete a page you need to have the ability to edit it, so admins without the new group would be unable to do so. Anomie⚔ 13:03, 5 August 2018 (UTC)

Huh, I think I misread something somewhere.. Galobtter (pingó mió) 13:14, 5 August 2018 (UTC)

Wait, really? In general? When did that happen? I distinctly recall during the superprotect crisis that admins were still able to delete Common.js even after it being superprotected, which incidentally also would remove protection, because there's never been a thing about practically restraining admins. If the devs specifically changed this also, and the interface admin business is part of a broader set of changes about setting up effective restraints against what admins can do, this is starting to sound a lot more dangerous. --Yair rand (talk) 17:38, 5 August 2018 (UTC)

That happened in August 2014 when it was noticed that someone with permission to delete and undelete a page but not to edit or unprotect it could "unprotect" the page by deleting and then undeleting it. Wikimedia wikis don't generally have any groups that can delete but not edit (although the "eliminator" group on jawiki, ptwiki, urwiki, and viwiki might), but other non-Wikimedia wikis might have more hierarchical levels of protection. Anomie⚔ 21:53, 5 August 2018 (UTC)

@Anomie: phab:T201052 suggests otherwise, but it could be wrong. Asked for clarification in phab:T190015. — xaosflux ^Talk 19:27, 5 August 2018 (UTC)

I think that phab was what confused me; Tgr is pretty clear here though in agreeing with Anomie. Galobtter (pingó mió) 19:32, 5 August 2018 (UTC)

Left several questions on the phab ticket, including a possible bigger problem for oversighters and global renamers.. — xaosflux ^Talk 19:50, 5 August 2018 (UTC)

Yeah I was thinking previously that if that is the case then we're definitely going to need some techadmin oversighters.. Galobtter (pingó mió) 19:57, 5 August 2018 (UTC)

At meta, Ajraddatz said renames would be fine, as the global renaming process bypasses any local restrictions, which seems right. ~ Amory (u • t • c) 20:10, 5 August 2018 (UTC)

@Ajraddatz: have these interactions been tested anywhere yet? — xaosflux ^Talk 20:18, 5 August 2018 (UTC)

The global renaming ones don't need to be tested, since it's built in already. I can test the sysop and oversight ones though. -- Ajraddatz (talk) 20:26, 5 August 2018 (UTC)

Done testing. It is not currently possible for a user with the delete permission to delete a CSS or JS page without also holding editsitecss and editsitejs respectively. The page also cannot be suppressed by a user without the appropriate editing permissions. I didn't test revision deletion. -- Ajraddatz (talk) 20:35, 5 August 2018 (UTC)

I can confirm I cannot delete pages I cannot edit: 07:08, 4 August 2018 Cynko (talk | contribs | block) protected Arturo Vidal [Edit=Dozwolone tylko dla redaktorów] (expires 07:08, 7 August 2018) [Move=Dozwolone tylko dla redaktorów] (expires 07:08, 7 August 2018) (do czasu ewentualnej zmiany klubu) (hist | change) (thank) - stewards don't have that edit permissions and I don't see delete buttons unlike this page. — regards, Revi 06:33, 6 August 2018 (UTC)

That's weird. The 'protect' permission is supposed to give access to all subordinate protection levels. They must have accidentally set up their own superprotect when they requested the config change. -- Ajraddatz (talk) 07:15, 6 August 2018 (UTC)

It's not weird at all. The 'protect' userright has never given access to all "subordinate" protection levels as far as I know (it might have worked that way in 2005, I haven't looked). For that matter, MediaWiki doesn't even have a concept of "subordinate" protection levels.

Here's how it actually works: Each protection level is a separate userright. If you have that right, you have the ability to edit pages protected with that right. If you also have the 'protect' right, you can apply and remove protection for any protection level for which you have the corresponding userright. Anomie⚔ 14:00, 6 August 2018 (UTC)

Thanks for the clarification - it's been a while since I set up new protection levels. -- Ajraddatz (talk) 15:44, 6 August 2018 (UTC)

What about admins' ability to help users with their JS/CSS?

I'm putting this as a subtopic of "... dealing with inappropriate user JS/CSS" above, since it concerns the same permissions, but may be of less importance. I've seen it touched upon, but not really discussed (but I may have missed it). --Pipetricker (talk) 07:10, 6 August 2018 (UTC)

You don't seem to have actually asked a question here. But in general, membership in the new group will be required to edit another user's JS or CSS subpages. Anomie⚔ 14:00, 6 August 2018 (UTC)

I've changed the topic heading to question form. --Pipetricker (talk) 07:33, 9 August 2018 (UTC)

• Well, that will be no longer possible but whatever 'help' a user needs on their CSS/JS page, the new Interface administrators will provide that. This is simple, unless if I didn't understand what you mean even after you changed it to question. –Ammarpad (talk) 07:19, 10 August 2018 (UTC)

Help could also be provided by regular admins, or indeed any competent editor, who can instruct the user who asks for help as to how to edit their CSS/JS page to fix an issue. WJBscribe (talk) 10:21, 10 August 2018 (UTC)

Well, assuming that they haven't screwed things up so badly that they can't edit. SQL^{Query me!} 02:33, 15 August 2018 (UTC)

Someone else could probably walk them through turning off JS (via extension or browser preferences), and then from there blanking their common.js. I'm also writing a tool to allow nontechnical users to manage their JS files, and it would be pretty easy to add an option to blank their common.js as well. Enterprisey (talk!) 02:40, 15 August 2018 (UTC)

@Enterprisey: pretty sure https://wiki.alquds.edu/?query=User:Enterprisey/common.js?safemode=1 can be loaded with little trouble, I suppose you could simultaneously screw up your common, and you global, and you skin- but not very likely. — xaosflux ^Talk 03:09, 15 August 2018 (UTC)

I learn something new every day :) Enterprisey (talk!) 03:16, 15 August 2018 (UTC)

Timing

When does this go live, i.e. on what date will admins lose the ability to edit pages now covered by the interface admin permission? I am concerned that there doesn't seem to be much of a consensus above as to who will be granted this and how. Will we need an interim stopgap to allow the permission to be granted those who need it while discussions about applicable policy going forwards continue? WJBscribe (talk) 10:18, 10 August 2018 (UTC)

Re the last issue, see #Stop gap option above. Johnuniq (talk) 10:35, 10 August 2018 (UTC)

@Johnuniq: "end of the month" is the last notes I saw on phab as the target. — xaosflux ^Talk 14:09, 12 August 2018 (UTC)

The Phab ticket at T190015 is one source of information for this. From the Meta discussion, the precise date is probably August 27th, European SWAT (so, midday UTC). I've asked for confirmation on phab, however. Enterprisey (talk!) 06:30, 19 August 2018 (UTC)

This has been confirmed, both on phab and on the Wikitech wiki, so the window during which the configuration will change is Monday, August 27th, 11:00–12:00 UTC. Enterprisey (talk!) 18:46, 20 August 2018 (UTC)

RfC: Approving the current proposal

Should this proposed policy be enacted? Danski454 (talk) 20:12, 20 August 2018 (UTC)

Summary of the proposal:

• The interface administrator right (used to edit non-personal JS and CSS pages) will be granted by reuest at the bureaucrats' noticeboard.
• Requests are open for 24 hours and are declined if 2 administrators object.
• Permission should be removed by bureaucrats in the following circumstances:

1. Interface administrators who have made no edits or other logged action for at least 12 months should have the user right removed.
2. Voluntary request by the interface administrator at the bureaucrats' noticeboard.
3. After misuse of the access, by consensus at Wikipedia:Administrators' noticeboard.
4. By request of the Arbitration Committee.

Danski454 (talk) 19:03, 20 August 2018 (UTC)

Original proposal:

Since we're limited on time, I've adapted Xaosflux's proposal with my addendum as suggested above (i.e. we don't make people go through this every 60 days.) The community would be free to change this as needed, but this will at least get us to a policy for the 'crats. The proposal being discussed is this version of the page. TonyBallioni (talk) 13:19, 13 August 2018 (UTC)

Discussion

• Support to get this approved with the understanding that it can be expanded and changed going forward. TonyBallioni (talk) 13:19, 13 August 2018 (UTC)
• Comment with this "temporary" measure assuming it will be replaced with a better proposal, I'd like to see an expiration kept - maybe 6 months? I think the stable implementation should be indefinite though. As for the temporary solution: if gaining access is tied to current sysop, removal should include "Upon removal of administrator access for any reason". This may change in the stable release if these are uncoupled. — xaosflux ^Talk 13:26, 13 August 2018 (UTC)
• and if any two administrators object, the request will be declined. is inappropriate. Either make it community members or loosen the objection requirement to straight "bureaucrat discretion" or similar. --Izno (talk) 15:45, 13 August 2018 (UTC)

  Just to be clear, I oppose that section as written and would oppose any attempt to make that the policy/guideline. --Izno (talk) 15:36, 15 August 2018 (UTC)

• Comment - the proposal should also oblige (rather than prefer) any admin granted the rights to enable 2FA. Since this whole shebang is to increase security, it makes sense that those given the rights take security of their accounts seriously. This is not an endorsement of the rest of the proposal, I need to think on that. Nosebagbear (talk) 20:45, 13 August 2018 (UTC)

  @Nosebagbear: We don't even require the many groups that can grant this access to have 2FA. — xaosflux ^Talk 00:07, 14 August 2018 (UTC)

  I don't think we can require 2FA, technically. But "...preferably using two-factor authentication" as the policy page currently is written, is surely an understatement. The interface admins will be publicly identifiable at Special:ListUsers, and these will be the accounts that are targeted. — MusikAnimal ^talk 01:09, 15 August 2018 (UTC)

  @MusikAnimal: not yet - but unless you require it for all the groups that can grant it, its a bit silly to argue for it to be forced. — xaosflux ^Talk 01:50, 15 August 2018 (UTC)

• Oppose Requiring some sort of "demonstrated need" would be nice. Otherwise you'll get admins who just want another hat (yes it happens), because this one seemingly is easy to get. They'll apply, we all concur they can be trusted. Great, they can be trusted, but the attack surface is still that much larger. If they don't edit JS/CSS currently, and don't exemplify some necessity for it moving forward, they can get by with consulting existing interface admins as needed. "Just asking" for the rights doesn't seem appropriate if you wish to be consistent with why this user group is being introduced. I for one don't want to have to monitor WP:BN. Franky I think requests should happen right here on this page, where JS/CSS people and existing interface admins can assess. I understand we want to get some policy out the door, but filling up all the interface admin roles with people who won't use it isn't the answer. If you hand out the user group to people who would use it, currently, then we'll have enough interface admins to handle requests, and give us more time to refine the policy around it. — MusikAnimal ^talk 00:27, 15 August 2018 (UTC)

  I'll remind you again that interface admin is above checkuser, oversight, etc. One day of consultation doesn't seem like enough — MusikAnimal ^talk 00:29, 15 August 2018 (UTC)

  @MusikAnimal: I don't think we should just "get some policy out the door" either, that is why I proposed a time-limited grant to alleviate pressure. — xaosflux ^Talk 01:50, 15 August 2018 (UTC)

  @MusikAnimal: I don't see interface admin being "above checkuser". Sure, if a bad guy has interface admin and introduces the right malicious code in the right places, they could possibly escalate their privileges. But to say "interface admin is above checkuser, oversight, etc." actually means that you say currently "admin is above checkuser, oversight, etc." because admins hold all of the rights interface admins are supposed to hold in the future. Please refrain from unnecessary hyperbole. —Kusma (t·c) 09:56, 15 August 2018 (UTC)

  That is correct, admins can currently do more damage than a checkuser or oversighter. This has already proven itself. It's a loophole that was known but not given enough attention until recently. I don't think it's a hyperbole, rather we have just been lucky that enwiki has not fallen victim.

  Either way, trivial things (by comparison) like edit filter helper (not manager) require a minimum 3 days of consultation. You don't think a single day for interface admin is too brief? — MusikAnimal ^talk 15:13, 15 August 2018 (UTC)

• Oppose Per MusikAnimal, well said. Anomie⚔ 00:37, 15 August 2018 (UTC)
• Support. Once the technical feature is introduced, we need some policy to deal with it, and we could just try this and see if it works. I don't actually see how any process will come to substantially better results than "be an admin, say why you can be an interface admin and ask nicely". If we turn this into a vote, should I oppose everyone who I think shouldn't have oversight rights?? —Kusma (t·c) 09:59, 15 August 2018 (UTC)
• Oppose right now the process for getting rights is too short. I would suggest a 1 or 2 week waiting period after which the user is granted the right at bureaucrat's discretion, as well as emailing the user so they have time to react if their account was compromised and a hacker made the request. --Danski454 (talk) 15:46, 15 August 2018 (UTC)
• Support, balance between bureaucracy and mess. Stifle (talk) 16:12, 16 August 2018 (UTC)
• Oppose, for a few reasons: this page would be better than BN, requests should be open for at least a week, admins shouldn't be the only people who can object, and we shouldn't be rejecting requests based on the number of people who object - rather it should be on the strength of the arguments given. I think the uncontroversial list idea is slightly better. Enterprisey (talk!) 04:01, 17 August 2018 (UTC)

  I'd rather see requests either on RFx or BN, or even possibly PERM then here, it really depends on what the "discussion" / "vote" / whatever process will be. — xaosflux ^Talk 14:27, 19 August 2018 (UTC)

  Sure, RfX or PERM sound good to me; it's just BN that I would prefer not to use for this. Enterprisey (talk!) 20:16, 19 August 2018 (UTC)

  I wouldn't favor using this page, I don't think it'd get enough eyes. Likewise with PERM, which is also a place for sysops to grant requests for permissions. A RfIA page might get enough eyes, but after the first flurry likely wouldn't be used much. BN makes the most sense to me — it's bureaucrat related, has plenty of eyes, and won't go stale. What's your aversion to it? ~ Amory (u • t • c) 21:17, 19 August 2018 (UTC)

  BN doesn't naturally seem to me like the place for discussions for adding permissions. It does host discussions generally related to permissions (i.e. mop renewals/removals), but no new requests for permissions. Both of the two similar user groups (EFM & BAG) have discussions on their own pages as well. If we wish to benefit from BN's watchers, we can always put a notice on BN for new discussions whenever they start. Enterprisey (talk!) 19:07, 20 August 2018 (UTC)

  That's reasonable. I had thought BN could absorb it, but perhaps we should create Wikipedia:Interface Administrators' noticeboard where 1. requests and hearings for the perm could be made and 2. folks could request edits by IAs. The latter seems decentralized, as those discussions should happen on the talk pages of the relevant page (and we'll likely have a edit request template/category), but I suppose it'd still be useful in the absence of those posts. Another thought (which I don't agree with) is that if the "declined if 2 sysops oppose" thing is implemented, then WP:AN would be an option (repeat: this is a bad idea). ~ Amory (u • t • c) 19:17, 20 August 2018 (UTC)

  Excellent idea, and then we could also use that for general peer review of intadmins' edits. Enterprisey (talk!) 19:31, 20 August 2018 (UTC)

  I also like the noticeboard idea, for the reasons stated above. I see this as tantamount to WP:EFN, which is a venue to seek help regarding filter implementation, express concerns on filters, and request related user rights (requesting filters is actually done at WP:EF/R, but that has a high volume of requests unlike what'd we see for site JS/CSS). WT:EF meanwhile is for modifications/concerns with the guideline. The interface admin noticeboard and this talk page could serve a similar purpose. — MusikAnimal ^talk 21:31, 20 August 2018 (UTC)

• Oppose. I think 24 hours is too short. huji—TALK 02:18, 21 August 2018 (UTC)
• Oppose: 24 hours is too short, 2 admins should not be able to veto a grant if there is otherwise consensus. BethNaught (talk) 09:17, 21 August 2018 (UTC)
• Oppose in favor of #Yet_another_proposed_granting_process, but vague Support for the removal conditions. Stopgap should be done to jumpstart the ranks. ~ Amory (u • t • c) 19:04, 21 August 2018 (UTC)
• Oppose per MusikAnimal. I'd be more willing to support if it was explicitly temporary like Xaosflux mentioned, but it isn't, so I don't. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 21:20, 21 August 2018 (UTC)
• Note to closer since this was proposed, the page has been edited in ways that change the meaning of the policy. If this is accepted, changes since then would need to be merged with the proposal, provided they do not change its meaning. --Danski454 (talk) 21:37, 21 August 2018 (UTC)
• Weak oppose: I think this is OK as a stopgap if we have literally nothing else, but it's not a good permanent solution. The two-admin veto and 24-hour discussion are both undesirably small amounts, and it does literally nothing to select against needless "hat collection" or for, uh, competence. I would weakly support this if it were framed explicitly as a temporary measure, with a reconfirmation or something for extant IA permissions once we settle on something better. {{Nihiltres |talk |edits}} 21:35, 24 August 2018 (UTC)
• I have removed the RfC template that was added to the top of this section, as it's fairly clear there's no consensus to implement this version of the proposal. It's not clear to me whether the rfc template was meant to encompass just this proposal or any of the alternative proposals submitted below. I would hold off on a formal RfC until the main Wikipedia:Interface administrators is workshopped into something that we like. Enterprisey's proposal below (#Yet another proposed granting process) seems like the most promising solution so far. Mz7 (talk) 07:23, 25 August 2018 (UTC)

  Yep, I agree with that. I left some holes in the proposal below, and we can resolve them in a discussion that'll be tagged with the RfC template. In particular, three questions have yet to be conclusively settled: who's allowed to have the right, where requests are made, and who can comment on requests. The first is being discussed above, where the "keep it to admins"/Option 1 camp have a slight lead, and I don't think we need to have another discussion on it. The second can be debated at a later time. As for the third, I put it in there (even though not too many people mention it on this page) because I thought people may want to discuss it. After someone closes the "Sysop as requirement" discussion and my "Yet another..." proposal, we can start talking about the remaining couple of questions (after a possible break so people don't get sick of talking on here?) and hopefully after that we'll have a complete granting process. Enterprisey (talk!) 07:33, 25 August 2018 (UTC)

Alternative stopgap

Would it be possible to come up with an uncontroversial list of say 10-20 users who do this work already who can be given access in the first instance? Or we could do it on the basis of giving access to everyone who already has more than X edits to pages that will require interface admin going forwards? WJBscribe (talk) 14:46, 15 August 2018 (UTC)

@WJBscribe: perhaps this list — xaosflux ^Talk 15:02, 15 August 2018 (UTC)

Extract of local controlled accounted used in last year
user num_edits User:TheDJ 196 User:MusikAnimal 50 User:Ragesoss 40 User:There'sNoTime 22 User:Dinoguy1000 15 User:MSGJ 14 User:Xaosflux 12 User:Mr. Stradivarius 10 User:Ocaasi 7 User:Amorymeltzer 7 User:Smith609 2 User:Legoktm 1 User:Alex Shih 1 User:Trappist the monk 1 User:Writ Keeper 1 User:Jason Quinn 1 User:Nihiltres 1 User:DMacks 1

SQL provided a list above at #Overall / Per-admin stats which includes user-space edits, which should be a consideration. (I asked him there about recent edits but we haven't heard back.) --Izno (talk) 15:07, 15 August 2018 (UTC)

#Overall / Per-admin stats is still inaccurate. The edits by MBisanz, Xeno, and WJBscribe for instance are chiefly from renames (which move personal JS/CSS pages). — MusikAnimal ^talk 15:17, 15 August 2018 (UTC)

@MusikAnimal: my list above was from your prior quarry, minus non-local people (WMF staff, global interface editors, etc), -1 one blocked/retired admin. — xaosflux ^Talk 15:23, 15 August 2018 (UTC)

I was referring to #Overall / Per-admin stats (I've amended my comment for clarity). On that note, to be clear, global renamers will still be able move user JS/CSS pages after the rollout of interface admin — MusikAnimal ^talk 15:26, 15 August 2018 (UTC)

And also this has no impact on editing your OWN js/css pages that appear to be included in that other dump. Also for users editing their own alt account's js/css pages (e.g. bot accounts); they can just log on as those accounts. — xaosflux ^Talk 15:28, 15 August 2018 (UTC)

Let's get accurate stats then. No one has provided actual stats which take into account: editors of Mediawiki, editors of Mediawiki JS/CSS, editors of non-personal-userspace JS/CSS (excluding renames). SQL's is what we have for the last bucket. --Izno (talk) 15:40, 15 August 2018 (UTC)

@Izno: (non-js/css mediawiki) editing should be irrelevant, it is not changing. — xaosflux ^Talk 15:42, 15 August 2018 (UTC)

Sure, I see that I misinterpreted earlier discussion on that point. --Izno (talk) 15:45, 15 August 2018 (UTC)

• Having just talked to another user on this, I think it’s worth pointing out that even if we had as lax a criteria as “Any admin gets it automatically upon request” we likely wouldn’t be looking at more than 20 users, including hat collectors who wouldn’t use it. That’s a more than 98% reduction from the current system. I get the security concerns (or rather, I don’t but I understand they are very significant) but getting a policy in place that results in an over 90% reduction in this risk can’t be classified as anything but good. I don’t really care what that policy is, I won’t be using this, but I do care that we have something. TonyBallioni (talk) 15:50, 15 August 2018 (UTC)
• OK, so taking what appears to be the top 10 editors of the relevant pages. Would anyone object if, in the first instance, the following people were to be grated interface admin rights, with future users to be added to the group once a consensus emerges for a suitable process to approve new candidates: TheDJ (talk · contribs), MusikAnimal (talk · contribs), Ragesoss (talk · contribs), There'sNoTime (talk · contribs), Dinoguy1000 (talk · contribs), MSGJ (talk · contribs), Xaosflux (talk · contribs), Mr. Stradivarius (talk · contribs), Ocaasi (talk · contribs), Amorymeltzer (talk · contribs)? WJBscribe (talk) 12:32, 20 August 2018 (UTC)

  Sounds good to me, with a few notes:

  • Dinoguy1000 is retired.
  • Ocaasi hasn't edited in three months, which (by a couple of editors above me, with whom I agree) would already count as inactive.
  • Ragesoss & Ocaasi, as far as I can see, only edit configuration files (in particular Guided Tour files), which are practically JSON anyway. Moreover, Ocaasi made most of his edits to those files in 2013. I'm not saying these two editors should definitely not get intadmin, since we don't have a strong consensus on requirements for granting yet - but maybe not in the first "wave".
  • There'sNoTime has made edits to three MW JS pages, two of which were single edits because a Teahouse page was moved. The other was a Guided Tour config page, to which 22 edits were made. Same comments as for Ragesoss & Ocaasi.

  Important note: I'm not saying anything about the JS abilities of the latter three editors - I just wrote my observations about their MW-space edits. In particular, There'sNoTime has written a number of offwiki tools that probably indicate a high level of JS ability. Enterprisey (talk!) 19:28, 20 August 2018 (UTC)

  I think it'd be worth outright asking for self-nominations for the initial list, and to actively prompt all active administrators who have edits to pages with titles matching the regex ^MediaWiki:.*\.(j|cs)s$ to apply. I'm biased: assuming I'm not part of this notional initial group, I will apply for the permission. :) {{Nihiltres |talk |edits}} 21:57, 20 August 2018 (UTC)

  Just to note, my retirement has only ever been a "soft" retirement - while my editing rate has been significantly reduced compared to when I was active, I've never actually stopped editing altogether, I've just moved the focus of my editing to other wikis. I can understand if this is still enough to disqualify me, though. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 17:43, 21 August 2018 (UTC)

  Sounds good to me; struck my comment. Enterprisey (talk!) 18:12, 21 August 2018 (UTC)

  I would support giving this right to TheDJ, MusikAnimal, MSGJ, Xaosflux, Mr. Stradivarius and Amorymeltzer as an interim measure. However, it's worth bearing in mind that these are volunteers, and it would be incumbent on the community to sort out the situation quickly so that these users don't feel any additional pressure. (Although such additional pressure is likely to be minimal, given the status quo already sees these users updating most of our CSS and JS.) — This, that and the other (talk) 02:44, 21 August 2018 (UTC)

Stop-gap users nominated

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

We are up against the -sysop access rollout in just over 5 days. I'd like to nominate myself and the rest of This, that and the other's list to have this access added for 60 days to give the rest of this page time to complete. Users requested (who may of course decline if they don't want it). I think this group of editors will be available, are technically adept, and will make non controversial edits and logged actions relating to this access. For anyone worrying, lets bind to a control similar to GIE's: Any English Wikipedia bureaucrat can revoke access if what they deem to be misuse occurs, either individually or by community request. Such a decision by a bureaucrat can be appealed at WP:BN. Assuming this RFC's get completed, the users selected below will need to apply using the normal process to maintain access. This comment period to run until 26 August 2018 at midnight. — xaosflux ^Talk 02:35, 22 August 2018 (UTC)

TheDJ

TheDJ (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

• Support as nominator. — xaosflux ^Talk 02:34, 22 August 2018 (UTC)
• Support, excellent demonstrated JS experience in interactions with him. Enterprisey (talk!) 02:51, 22 August 2018 (UTC)
• Support of course Kevin (aka L235 · t · c) 02:57, 22 August 2018 (UTC)
• Support no reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 02:58, 22 August 2018 (UTC)
• Support Known good. Johnuniq (talk) 03:30, 22 August 2018 (UTC)
• Support Obviously Hhkohh (talk) 03:44, 22 August 2018 (UTC)
• Support Already implicitly trusted by the community. There'd be real harm to the site if there were any lapse in DJ's ability to edit these pages. ~ Amory (u • t • c) 10:12, 22 August 2018 (UTC)
• Support Trusted member, seems to know how to use JS/CSS. ^Semi_Hypercube ✎ 12:45, 22 August 2018 (UTC)

MusikAnimal

MusikAnimal (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

• Support as nominator. — xaosflux ^Talk 02:34, 22 August 2018 (UTC)
• Support excellent demonstrated JS experience. Enterprisey (talk!) 02:51, 22 August 2018 (UTC)
• Support of course Kevin (aka L235 · t · c) 02:57, 22 August 2018 (UTC)
• Support no reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 02:58, 22 August 2018 (UTC)
• Support Known good. Johnuniq (talk) 03:30, 22 August 2018 (UTC)
• Support Obviously Hhkohh (talk) 03:44, 22 August 2018 (UTC)
• Support As Johnuniq said, they are a god of scripts. --TheSandDoctor ^Talk 04:05, 22 August 2018 (UTC)
• Support —TheDJ (talk • contribs) 07:47, 22 August 2018 (UTC)
• Support Already implicitly trusted by the community. There'd be real harm to the site if there were any lapse in MA's ability to edit these pages. ~ Amory (u • t • c) 10:12, 22 August 2018 (UTC)
• Support Trusted member, seems to know how to use JS/CSS. ^Semi_Hypercube ✎ 12:45, 22 August 2018 (UTC)

MSGJ

MSGJ (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

• Support as nominator. — xaosflux ^Talk 02:34, 22 August 2018 (UTC)
• Support excellent demonstrated JS experience. Enterprisey (talk!) 02:51, 22 August 2018 (UTC)
• Support of course Kevin (aka L235 · t · c) 02:57, 22 August 2018 (UTC)
• Support no reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 02:58, 22 August 2018 (UTC)
• Support Known good. Johnuniq (talk) 03:30, 22 August 2018 (UTC)
• Support —TheDJ (talk • contribs) 07:46, 22 August 2018 (UTC)
• Support Already implicitly trusted by the community. ~ Amory (u • t • c) 10:12, 22 August 2018 (UTC)
• Support Trusted member, seems to know how to use JS/CSS. ^Semi_Hypercube ✎ 12:45, 22 August 2018 (UTC)

Xaosflux

Xaosflux (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

• Support demonstrated JS experience. Enterprisey (talk!) 02:51, 22 August 2018 (UTC)
• Support of course Kevin (aka L235 · t · c) 02:57, 22 August 2018 (UTC)
• Support no reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 02:58, 22 August 2018 (UTC)
• Support Known good. Johnuniq (talk) 03:30, 22 August 2018 (UTC)
• Support Obviously Hhkohh (talk) 03:45, 22 August 2018 (UTC)
• Support nothing which would cause me concern. --TheSandDoctor ^Talk 04:06, 22 August 2018 (UTC)
• Support —TheDJ (talk • contribs) 07:46, 22 August 2018 (UTC)
• Support Already implicitly trusted by the community. ~ Amory (u • t • c) 10:12, 22 August 2018 (UTC)
• Support Trusted member, seems to know how to use JS/CSS. ^Semi_Hypercube ✎ 12:45, 22 August 2018 (UTC)

Mr. Stradivarius

Mr. Stradivarius (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

• Support as nominator. — xaosflux ^Talk 02:34, 22 August 2018 (UTC)
• Support demonstrated JS experience. Enterprisey (talk!) 02:51, 22 August 2018 (UTC)
• Support of course Kevin (aka L235 · t · c) 02:57, 22 August 2018 (UTC)
• Support no reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 02:58, 22 August 2018 (UTC)
• Support Known good. Johnuniq (talk) 03:30, 22 August 2018 (UTC)
• Support —TheDJ (talk • contribs) 07:46, 22 August 2018 (UTC)
• Support Already implicitly trusted by the community. ~ Amory (u • t • c) 10:12, 22 August 2018 (UTC)
• Support Trusted member, seems to know how to use JS/CSS. ^Semi_Hypercube ✎ 12:45, 22 August 2018 (UTC)

Amorymeltzer

Amorymeltzer (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

• Support as nominator. — xaosflux ^Talk 02:34, 22 August 2018 (UTC)
• Support demonstrated JS experience. Enterprisey (talk!) 02:51, 22 August 2018 (UTC)
• Support of course Kevin (aka L235 · t · c) 02:57, 22 August 2018 (UTC)
• Support no reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 02:58, 22 August 2018 (UTC)
• Support Known good. Johnuniq (talk) 03:30, 22 August 2018 (UTC)
• Support Obviously Hhkohh (talk) 03:45, 22 August 2018 (UTC)
• Support —TheDJ (talk • contribs) 07:46, 22 August 2018 (UTC)
• Support Trusted member, seems to know how to use JS/CSS. ^Semi_Hypercube ✎ 12:45, 22 August 2018 (UTC)

Stop this insanity!

If you think this proposal is just ridiculous feel free to comment here. — xaosflux ^Talk 02:38, 22 August 2018 (UTC)

• I think it's far from insanity. But I'm also too lazy to comment individually. Support all. -- Ajraddatz (talk) 04:07, 22 August 2018 (UTC)
• Great proposal, and I am even more lazy, so per Ajraddatz and Support all. Alex Shih (talk) 05:47, 22 August 2018 (UTC)
• Supporting all nominees down to Amorymeltzer (in case someone else would be added)--Ymblanter (talk) 06:44, 22 August 2018 (UTC)
• I support this general stopgap, and specifically all these through Amorymeltzer. Noting for the record the scan for activity does not address MW: namespace, though the long-range plan for interface-admins apparently includes the editinterface right. DMacks (talk) 07:06, 22 August 2018 (UTC)

  That was discussed a bit above: it was noted that there are just so few edits to that namespace that requiring intadmins to make them to keep the user right wouldn't be realistic. Enterprisey (talk!) 07:20, 22 August 2018 (UTC)

Now I'm confused. Are deferring action on the full MW: until the editinterface mode is flipped from the admin set to the interface-admin set? Or are we going to have those who we give .css/.js now as the starting set for the full MW: when the time comes? Or we are not going to flip that at all? DMacks (talk) 07:34, 22 August 2018 (UTC)

I do not believe editinterface will be removed from the admin rights. I thought you were talking about the activity requirements discussion above. Enterprisey (talk!) 07:39, 22 August 2018 (UTC)

Sorry for confusing you about my confusion! This all started from #Clarify scope of affected pages and other proposals, where I had gotten the impression that the full MW: was in scope to be removed from admin, not just added to interface-admin. DMacks (talk) 07:57, 22 August 2018 (UTC)

Hope this makes sense now? Administrators will still be able to edit the MediaWiki namespace in general (e.g. messages, things like the title blacklist, spam blacklist, etc) - just not the pages ending in .js/.css — xaosflux ^Talk 10:29, 22 August 2018 (UTC)

And yes, non-admin IA's will be able to edit the mediawiki namespace, though sysops can override this on a per-page basis with admin-only protection. — xaosflux ^Talk 11:05, 22 August 2018 (UTC)

• Support all till amorymeltzer Galobtter (pingó mió) 07:30, 22 August 2018 (UTC)
• It is good to see this support all option. –Ammarpad (talk) 07:44, 22 August 2018 (UTC)
• Of course the people who do the work should be continued to allow to do the work. Too lazy to comment on individuals. Go for it. —Kusma (t·c) 10:17, 22 August 2018 (UTC)
• Support the six users listed at Special:PermaLink/856037083#Stop-gap users nominated. Anomie⚔ 12:51, 22 August 2018 (UTC)
• Support the six users listed at Special:PermaLink/856037083#Stop-gap users nominated as qualified, trusted and apparently competent. · · · Peter (Southwood) ^(talk): 16:14, 22 August 2018 (UTC)
• Support all six. --Rschen7754 18:00, 22 August 2018 (UTC)
• Support all. (I also support granting to any Sysop on request, though, so...) Courcelles (talk) 23:51, 23 August 2018 (UTC)
• Support all six. Tazerdadog (talk) 04:16, 24 August 2018 (UTC)
• Support all six. All hail the first techadmins! — pythoncoder  (talk | contribs) 14:40, 25 August 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Yet another proposed granting process

• Users who want this permission can make a request at WP:Interface administrators' noticeboard some venue to be decided later.
• Discussion proceeds for a week, and is closed by a crat who evaluates the consensus, if one exists.
• Users who apply are encouraged to answer two questions: "Please describe any relevant on-Wiki experience you have for this role" and "Please outline, without breaching your personal privacy, any off-Wiki experience or technical expertise you may have for this role".
• Community notices will be posted to relevant noticeboards, including AN and VPT.

This proposal says nothing about whether only admins are allowed to make requests, whether only intadmins/sysops can participate in the discussion, or where we talk about this; we can decide those questions later. It's similar to the EFM process, taking some ideas from previous posts on this page (in particular Amory's proposed questions from CUOS). Enterprisey (talk!) 04:06, 21 August 2018 (UTC)

• Support this addresses every issue i have with the current process Danski454 (talk) 08:51, 21 August 2018 (UTC)
• Amorymeltzer has created the (blank) noticeboard. Looking at this from the POV of the folks who will end up with this user right, I suspect that they would be perfectly happy to have it redirected to WP:VPT. "Please get this right, do this work – oh, and you won't mind if we sometimes post technical requests at VPT, and sometimes at this new noticeboard, will you?" doesn't sound like quite as attractive an offer as we could make. WhatamIdoing (talk) 15:38, 21 August 2018 (UTC)

  WhatamIdoing, I think it's mostly about signal-to-noise ratio: if I become an intadmin, probably a low percentage of village-pump posts will be interesting to me; by contrast, I'll definitely read everything in the new noticeboard. Enterprisey (talk!) 18:14, 21 August 2018 (UTC)

  Per the above, ideally all requests for edits would be discussed on the respective talkpages, as is done now. A centralized board could be used to discuss the granting of the permission, in particular by other intadmins, as well as some broader discussion and coordination about edits, such as more complex or wide-ranging or temporary edits (might've made transitioning to templatestyles smother?) or for broader input on more complicated measures. Presumably, all of these would be fairly uncommon. ~ Amory (u • t • c) 19:00, 21 August 2018 (UTC)

  • My guess is that the main candidates for this are already reading VPT, and that most requests for edits will naturally appear at VPT or on the relevant talk page. So I think that creating a special board will spread the discussions out (three "correct" places, rather than the current two), without saving them any effort. WhatamIdoing (talk) 19:47, 21 August 2018 (UTC)

    WhatamIdoing, I have struck the part about the noticeboard from the proposal. Further thoughts on it are welcome. Enterprisey (talk!) 07:01, 22 August 2018 (UTC)

• Comment Just pinging some people who commented in the above discussion: TonyBallioni, xaosflux, Izno, Nosebagbear, MusikAnimal, and Anomie. Enterprisey (talk!) 18:15, 21 August 2018 (UTC)
• Minor Tweak - "Please outline, without breaching your personal privacy, what off-Wiki experience or technical expertise you have for this role" should be tweaked to "what, if any," - It's perfectly possible that someone would satisfy the requirements without off-Wiki experience (or at least, any they'd want to mention) so the question shouldn't be phrased in a sense that either assumes they would, or implies they should. I'm positive that this wasn't intended, but I feel it is how it reads. Nosebagbear (talk) 18:20, 21 August 2018 (UTC)

  Done. Enterprisey (talk!) 19:03, 21 August 2018 (UTC)

• Support Satisfies my concerns. Thanks — MusikAnimal ^talk 18:28, 21 August 2018 (UTC)
• +1, with Nosebagbear's suggested tweak or just "...privacy, any off-Wiki..." I'd also say "encouraged to answer" rather than "allowed to answer" but YMMV. A week seems overlong, but I was concerned about eyeballs elsewhere, so I don't think I can nitpick it both ways. ~ Amory (u • t • c) 19:00, 21 August 2018 (UTC)
• With this being "more dangerous then ....(everything?)" I think whatever the request venue, a community notice of the discussion should be posted to to at least WP:AN. — xaosflux ^Talk 19:02, 21 August 2018 (UTC)

  Sounds good; updated proposal. Enterprisey (talk!) 19:15, 21 August 2018 (UTC)

• A very sensible proposal, support. -- Ajraddatz (talk) 21:18, 21 August 2018 (UTC)
• Weak support I think this is a better place to start than the previous proposal, but I think it may be a tad heavy handed. I would like anyone to be able to comment (not just flavors of admin) but I do not want this to turn into an RFA clone. This is a better stop gap, but my ideal would be something in between the two proposals so far. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 22:39, 21 August 2018 (UTC)

  Wugapodes, I appreciate the comment. Do you think it would help if we suggested, to any editors commenting on each request, that they keep their comments limited to the candidate's level of trust and their technical ability? Enterprisey (talk!) 07:04, 22 August 2018 (UTC)

• Minded to oppose mainly because I think that having yet another noticeboard is scary. Jo-Jo Eumerus (talk, contributions) 06:58, 22 August 2018 (UTC)

  Jo-Jo Eumerus, I have struck the part about the noticeboard from the proposal, as I don't feel very strongly about it. What other concerns do you have? Enterprisey (talk!) 07:00, 22 August 2018 (UTC)

  Only other concern is that I also don't want an RfA clone. Jo-Jo Eumerus (talk, contributions) 07:06, 22 August 2018 (UTC)

  Well, that's a valid concern. It's very likely related to who we allow to request the permission: if it's going to be admins only, we probably won't have all the same discussion again, whereas if we allow non-admins to apply, trust questions will start being asked.

  Regardless, as I said to Wugapodes above, limiting the scope of comments in the discussion is one possible solution to this. I'm not completely convinced that "turning into RfA" is an unavoidable problem with the current proposal. Enterprisey (talk!) 07:12, 22 August 2018 (UTC)

• Clone Thoughts - so I'd actively suggest it isn't watchlist notified, which brings everyone and their goat. I think it could work if comments are limited to literally two things (as mooted by Enterprisey): Trust and technical ability. If all other !votes were not considered when judging consensus, I think it will keep it reasonably well on track.
• Thought bubble: The noticeboard could be WP:AN where there are plenty of admins who would rein in disruptive commentary, if only because they wouldn't want a lot of crap on that page. Johnuniq (talk) 09:26, 22 August 2018 (UTC)
• VPT should be enough for the noms and discussions for intadmin, I guess... Otherwise LGTM, +1. — regards, Revi 11:07, 22 August 2018 (UTC)
• This proposal seems sane to me. Anomie⚔ 12:34, 22 August 2018 (UTC)
• I would really rather WP:AN not be the location for discussion, the tone of discussion (including from the admins) is rather more curt and lacking AGF then I think is beneficial. VPT seems a better option. Nosebagbear (talk) 13:12, 22 August 2018 (UTC)
• Support—this seems sensible. I'd suggest lumping in the requests with RfAs/RfBs (i.e. our existing system for "advanced" permissions), but really, the colour of the shed doesn't matter much. {{Nihiltres |talk |edits}} 21:43, 24 August 2018 (UTC)

"Consensus of bureaucrats" amendment

I think the above may lead to another RfA-like process, which I think should be avoided at all cost considering how broken it became. How about this? As above ("Yet another proposed granting process") but instead of:

• Discussion proceeds for a week, and is closed by a crat who evaluates the consensus, if one exists.

we replace it with:

• A consensus of bureaucrats will decide if a candidate is successful . Non-bureaucrats will be allowed a week (or some other time period) to make comments that may be helpful to the bureaucrats, but will not take part in the actual decision.

The decision making of the bureaucrats would be similar to present day 'crat chats, but instead of assessing consensus of other editors they will be entrusted with making their own decision. Non-'crats would only allowed to make comments on the candidate without actually !voting.

I feel this is preferable in avoiding all the "assume bad faith" and wiki-drama that seems to be attached to RfX-like processes. Also bureaucrats are highly trusted users who are probably under-used, and could be trusted with the decision without the need to go down the RfX-like route. Since 'crats are only ones who could grant/remove this permission, it makes sense to make them the ones to decide who gets the permission. Any comments on this? --Jules (Mrjulesd) 18:42, 25 August 2018 (UTC)

I have enough qualms about the crat chat process - I don't think it adds any value to have a bunch of random people who were elected a decade ago get together and vote on whether the nebulous concept of consensus exists in a discussion without any defined criteria for what would constitute a consensus in that situation. Permanently adding that to all requests for intadmin doesn't seem like a good idea to me. -- Ajraddatz (talk) 19:11, 25 August 2018 (UTC)

But look at the way RfA has degraded over the years, very few are coming forward to it and even fewer are passing. Another RfX process is very likely to end up the same way. The reason why very few new 'crats are coming forward is very probably connected with the failure of RfX processes on Wikipedia. 'Crats are the only ones who can actually bestow this permission anyway, so they are trusted to this extent. --Jules (Mrjulesd) 20:10, 25 August 2018 (UTC)

By nature, we don't want many intadmins. We're doing fine even if we only get one or two new ones per year (or less depending on need). And if the goal of your proposal is to encourage people to come forward, how would the double vote actually do that? -- Ajraddatz (talk) 20:14, 25 August 2018 (UTC)

It wouldn't be a double-vote. Only interested 'crats would !vote, others could only comment. --Jules (Mrjulesd) 21:05, 25 August 2018 (UTC)

My concern is that it would still be a vote. There would still be people saying oppose or support, and bureaucrats would still end up counting "comments" when making their decision. RfA here is a broken process, but not everywhere. On projects where RfA is a smaller deal, candidates are still willing to come forward and a proportionally acceptable rate. If we can use an intadmin selection process similar to EFM, then we should be able to avoid the massive stage of RfA and keep things more focused on evaluating useful metrics relevant to the position, and thus not dissuade people from applying. -- Ajraddatz (talk) 21:56, 25 August 2018 (UTC)

Not really a concern. "Opposes" or "Support" comments could be removed. Or else the 'crats could be allowed to ignore such comments.

For precedence, look at how the CheckUser or Oversight permissions are granted. Although all editors are allowed to voice their approval or disapproval, only ArbCom are allowed to !vote on who gains these permissions.

If we allow another RfX process on Wikipedia, it will only be time before it slumps to its last legs (RfA) or dies completely (RfB). --Jules (Mrjulesd) 11:19, 26 August 2018 (UTC)

• Oppose and I am a 'crat. I think granting of this access should be reviewed and approved by the community at large. I am supportive of giving a discretionary removal-for-cause power to the crats, so long as there is an appeal process. — xaosflux ^Talk 15:05, 26 August 2018 (UTC)

Clarify scope of affected pages

Our local Wikipedia:Interface_administrators says:

sitewide CSS, JavaScript and JSON pages (pages such as MediaWiki:Common.js or MediaWiki:Vector.css, or the gadget pages listed on Special:Gadgets), CSS/JS/JSON pages in another user's userspace, and pages in the MediaWiki namespace

but meta:Interface administrators says:

sitewide CSS/JS pages (pages such as MediaWiki:Common.js or MediaWiki:Vector.css, or the gadget pages listed on Special:Gadgets)...(they can also edit all other pages in the MediaWiki namespace)

The "..." does not mention CSS/JS/JSON in another user's userspace or MediaWiki namespace in general. The "they can also edit..." parenthetical seems to amplify that this is adding MW:*.js and MW:*css rather than allowing edit of only these MW and not others. But it does not seem to imply that this right is required to edit the whole MW: namespace, only the js/css subset.

What is the actual scope? Where is the formal implementation/documentation of it? DMacks (talk) 20:41, 21 August 2018 (UTC)

The formal changes that will be made on the 27th are here. The actual code that assigns permissions (presumably the version that will be deployed) is here. It explicitly gives intadmins the "editinterface", "editsite*", and "edituser*" perms, where * means css, js, or json. Enterprisey (talk!) 21:12, 21 August 2018 (UTC)

In summary, the new access already exists - we are talking above about how to give it out. The next change is about removing existing access form sysops. — xaosflux ^Talk 22:19, 21 August 2018 (UTC)

According to that deployment plan, the relevant code changes are gerrit:421124 and gerrit:421125, which only remove editsitecss, editsitejs, editusercss, edituserjs but not editinterface and not editsitejson or edituserjson. I guess MW is taking it step by step. DMacks (talk) 07:04, 22 August 2018 (UTC)

There's no plan to remove editinterface, editsitejson, or edituserjson from the groups that currently have it, as far as I know. Anomie⚔ 12:32, 22 August 2018 (UTC)

I've updated the page on meta to align with our page. The rights are listed at Special:ListGroupRights#interface-admin. — JJMC89 (T·C) 05:02, 22 August 2018 (UTC)

It still looks like something should be done with the phrase "and pages in the MediaWiki namespace" here, if other administrators will still be able to edit non-CSS/JS/JSON interface pages in the MediaWiki space. Dekimasuよ! 18:40, 24 August 2018 (UTC)

@Dekimasu: they can edit these pages, unlike standard editors. Administrators may also edit them, unlike standard editors. — xaosflux ^Talk 20:07, 24 August 2018 (UTC)