Wikipedia talk:Interface administrators

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
• 
  Wizard

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

In my opinion, the few people whom have the tech capabilities necessary to edit and transform the interface are the true wizards of our communities. I hope you'll like the sixth option I added. ויקיג'אנקי (talk) 06:46, 1 September 2018 (UTC)

@ויקיג'אנקי: I think there is already near unanimous support for the pliers. ^Semi_Hypercube ✎ 22:39, 2 September 2018 (UTC)

• @SemiHypercube: The pliers is fine, but have you seen it in smaller versions like in the {{Interface administrator topicon}}? It’s fugly as heck in its current state, it needs a change of color and the pliers needs to be made a little thicker. I suggest a warmer color like orange or red so it’s at least visible in smaller versions.--▸ ‎épine _talk♬ 03:29, 7 September 2018 (UTC)

  Agreed, and a shadow on the pliers (like the EFM/EFH, mass messenger, and page mover) would improve the logo's appearance in my opinion. Enterprisey (talk!) 03:34, 7 September 2018 (UTC)

  I didn't make the image, so I'll ping @Danski454: the creator of the image to inform them of this. ^Semi_Hypercube ✎ 12:20, 7 September 2018 (UTC)

Additional temporary access requests

 Bureaucrat note: I know some people are getting rather frustrated with the recent change. I'm willing to grant interface-administrator to those that request it here provided:

1. Access will be temporary (60 days), permanent access will require a community process to be ratified (at which time this process will be voided)
2. Requester is already an administrator
3. Your request here is advertised at WP:AN and WP:VPT
4. Your request is open for community comments for 96 hours
5. The community commentary leads to a strong consensus of support (~75%+ support)
6. Revocation criteria 1: "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"
7. Revocation criteria 2: Any removal of sysop access

— xaosflux ^Talk 22:57, 30 August 2018 (UTC)

Can we just use this (save the temporary part) as the final process? The criteria seem to be either widely agreed on or a good compromise between options. -- Ajraddatz (talk) 23:42, 30 August 2018 (UTC)

@Ajraddatz: it could be, and the last thing I want to do is dictate policy from above - but it has many of the elements from above, plus some safeguards. Personally: I'm not strongly opposed to non-admin intadmins - so long as they are strongly supported; and I think a week is a better review period; if not tied to sysop I'd argue for inactivity removal no longer than a year as well; I also don't think this is the best process page, but as long as requests are advertised that is the least important thing. — xaosflux ^Talk 00:08, 31 August 2018 (UTC)

Xaosflux, we could also request non-administrators to go trough an RfA with the explicit statement that they are requesting iadmin instead of sysop (or both for all i care). —TheDJ (talk • contribs) 14:47, 31 August 2018 (UTC)

---

IAdmin temporary access request for User:Oshwah

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.

---

Earliest closure has started. (refresh)

Oshwah (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 · ev · fm · mms · npr · pm · pc · rb · te)}

Xaosflux - Cool deal. Care if I re-open my request that I made on WP:BN here? I'll throw a notice at WP:AN and WP:VPT if you don't mind... ~Oshwah~^{(talk) (contribs)} 23:09, 30 August 2018 (UTC)

Hi there! I'm here to request the 'interface administrator' user rights so that I can continue to do what I've done before, which is to assist users with their .js and .css code within their user space (in fact, I have a message on my user talk page here with an active request for help regarding their .js file and scripts). I won't be able to continue assisting users with their code without the permissions. I'm a software engineer, have designed my own versions of scripts within my user space, and I completely know and understand the sensitivity of these user rights and the impact that making careless edits and mistakes can cause to Wikipedia; I have a strong password, use 2FA, and promise to use the rights with care at all times. If anyone has any questions or concerns, please let me know and I'll be happy to respond. ~Oshwah~^{(talk) (contribs)} 23:10, 30 August 2018 (UTC)

Notifications have been left on WP:AN and WP:VPT (AN diff, VPT diff) ~Oshwah~^{(talk) (contribs)} 23:15, 30 August 2018 (UTC)

• Support no concerns Mz7 (talk) 23:24, 30 August 2018 (UTC)
• Support I see no problem with this request. Cullen³²⁸ Let's discuss it 23:35, 30 August 2018 (UTC)
• Support –Ammarpad (talk) 23:48, 30 August 2018 (UTC)
• Support. Obviously trusted user and has demonstrated a need for the tools. No reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 23:55, 30 August 2018 (UTC)
• Support. Handy admin and doesn't abuse the tools. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 00:09, 31 August 2018 (UTC)
• Support Has a use for it and has appropriate account security. Natureium (talk) 00:39, 31 August 2018 (UTC)
• Support No reason not to. Home Lander (talk) 00:58, 31 August 2018 (UTC)
• Support Obviously. ^Semi_Hypercube ✎ 01:16, 31 August 2018 (UTC)
• Support Obviously Hhkohh (talk) 01:23, 31 August 2018 (UTC)
• Support Technically competent and trustworthy. Tazerdadog (talk) 01:31, 31 August 2018 (UTC)
• Support Kevin (aka L235 · t · c) 01:59, 31 August 2018 (UTC)
• Yup SQL^{Query me!} 03:23, 31 August 2018 (UTC)
• Support Enterprisey (talk!) 04:14, 31 August 2018 (UTC)
• Support can definitely be trusted. Lepricavark (talk) 04:28, 31 August 2018 (UTC)
• Support, no problem.--Ymblanter (talk) 05:58, 31 August 2018 (UTC)
• Support. This admin has used to tool without abuse before the system got changed, so we should trust him by default. Deryck C. 09:28, 31 August 2018 (UTC)
• Support —AE (talk • contributions) 10:15, 31 August 2018 (UTC)
• Support as no objection. I would, having criticised a few of Oshwah's blocks, just give my usual word of caution to him to not get carried away with things and double check stuff before hitting the "submit" button. Ritchie333 ^{(talk) (cont)} 13:07, 31 August 2018 (UTC)
• Sure. —Kusma (t·c) 13:42, 31 August 2018 (UTC)
• Support 78.26 _{(spin me / revolutions)} 16:26, 31 August 2018 (UTC)
• Comment: Intadmin isn't really needed for the stated purpose of assisting users with their JS/CSS, it just makes it a bit easier (see #Userspace pages above). --Pipetricker (talk) 22:48, 31 August 2018 (UTC)
• Support. I trust him - he's highly competent. — Diannaa 🍁 (talk) 23:21, 31 August 2018 (UTC)
• Support a suitable reason for needing this access. Graeme Bartlett (talk) 00:41, 1 September 2018 (UTC)
• Support Per past work and future requirement. Lourdes 05:53, 1 September 2018 (UTC)
• Support. Has not broken anything yet. No reason to expect them to start now. Per Deryck Chan. · · · Peter (Southwood) ^(talk): 15:44, 1 September 2018 (UTC)
• Support Agathoclea (talk) 19:09, 1 September 2018 (UTC)
• Support – Oshwah definitely knows where his towel is. — JFG ^talk 21:32, 2 September 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.

IAdmin temporary access request for User:Cyberpower678

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.

---

Earliest closure has started. (refresh)

Cyberpower678 (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 · ev · fm · mms · npr · pm · pc · rb · te)}

I'm not the moist active user in this community that edits JS pages, but I have done it and fairly recently too. I primarily use my access to update Geonotices but occasionally alter JS code elsewhere. I consider myself technically competent and knowledgable enough to know what the risks of editing these pages are. Evidence of that is that I'm the developer and operator of InternetArchiveBot and the accompanying tool found here. Being that I used to have access to them as an admin, I am hereby requesting returning my access. Naturally I take account security very seriously and have a strong password and 2FA enabled. :-)—CYBERPOWER (Chat) 23:36, 30 August 2018 (UTC) AN notice

• Support –Ammarpad (talk) 23:51, 30 August 2018 (UTC)
• Support. Obviously trusted user and has demonstrated a need for the tools. No reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 23:55, 30 August 2018 (UTC)
• Support, without comment regarding his moistness. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 00:08, 31 August 2018 (UTC)
  • Curious who the moist active user is...--SkyGazer 512 ^{Oh no, what did I do this time?} 00:12, 31 August 2018 (UTC)

HA! That's funny! :-) ~Oshwah~^{(talk) (contribs)} 00:15, 31 August 2018 (UTC)

• Support without hesitation - If we can't entrust Cyberpower with this access, we should close up shop entirely. Ben · Salvidrim! ✉ 00:29, 31 August 2018 (UTC)

"I consider myself technically competent" -- and he's overly modest too! Ben · Salvidrim! ✉ 00:30, 31 August 2018 (UTC)

• Support Has a use for it and has appropriate account security. Natureium (talk) 00:39, 31 August 2018 (UTC)
• Support regardless of moistness. Home Lander (talk) 00:59, 31 August 2018 (UTC)
• Support - trustworthy and extremely competent. Tazerdadog (talk) 01:22, 31 August 2018 (UTC)
• Support Hhkohh (talk) 01:23, 31 August 2018 (UTC)
• Support Kevin (aka L235 · t · c) 01:59, 31 August 2018 (UTC)
• Support moist & competent. Enterprisey (talk!) 04:14, 31 August 2018 (UTC)
• Support despite the watered-down nomination statement. Lepricavark (talk) 04:29, 31 August 2018 (UTC)
• Support, no problem.--Ymblanter (talk) 05:58, 31 August 2018 (UTC)
• Support. This admin has used to tool without abuse before the system got changed, so we should trust him by default. Deryck C. 09:29, 31 August 2018 (UTC)
• Yup SQL^{Query me!} 10:06, 31 August 2018 (UTC)
• Support One of our best techie admins. Ritchie333 ^{(talk) (cont)} 13:07, 31 August 2018 (UTC)
• Sure. —Kusma (t·c) 13:42, 31 August 2018 (UTC)
• Support 78.26 _{(spin me / revolutions)} 16:26, 31 August 2018 (UTC)
• Support no problem, no matter how moist he may be. ^Semi_Hypercube ✎ 18:50, 31 August 2018 (UTC)
• Support this user really knows where his towel is. Perhaps that's why he's not the moistest :). But seriously, he has the coding chops to handle this task. — Diannaa 🍁 (talk) 23:23, 31 August 2018 (UTC)
• Support a good reason to have access. Graeme Bartlett (talk) 00:42, 1 September 2018 (UTC)
• Support Per past work and future requirement. Lourdes 05:53, 1 September 2018 (UTC)
• Support per Deryck Chan · · · Peter (Southwood) ^(talk): 15:51, 1 September 2018 (UTC)
• Support Agathoclea (talk) 19:02, 1 September 2018 (UTC)
• Support – No-brainer. — JFG ^talk 21:32, 2 September 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.

IAdmin temporary access request for User:Deryck Chan

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.

---

Earliest closure has started. (refresh)

Deryck Chan (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 · ev · fm · mms · npr · pm · pc · rb · te)}

Good morning everyone! I'm requesting to be a stop-gap Interface Administrator. I have been an admin for Wikipedia:Geonotice (MediaWiki:Gadget-geonotice.js, MediaWiki:Gadget-geonotice-list.js) for seven years and have made over 100 edits on these JavaScript pages over the years. I would like to gain the Interface Administrator so I can continue to help maintaining Geonotices. Outside the en.wp MediaWiki namespace, I have also authored Module:RfD close (used in the closure of every closed RfD since March 2017) and helped to maintain closerfd.js (now superseded by XFDcloser). I am a civil engineer IRL and do programming work in my day job on a regular basis. I am open to recall and I hope you will trust me to continue editing site-wide JavaScript pages. Deryck C. 09:59, 31 August 2018 (UTC)

AN notice; VPT notice --Deryck C. 10:03, 31 August 2018 (UTC)

• Yup SQL^{Query me!} 10:06, 31 August 2018 (UTC)
• Support, no issues--Ymblanter (talk) 10:14, 31 August 2018 (UTC)
• Support I am leaning to agree with Rob13 here because this process is becoming boring and exceedingly needless. –Ammarpad (talk)
• Support Hhkohh (talk) 10:44, 31 August 2018 (UTC)
• Support. Obviously trusted user and has demonstrated a need for the tools. No reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 23:55, 30 August 2018 (UTC)
• Sure, no reason to stop you from doing your work! —Kusma (t·c) 13:42, 31 August 2018 (UTC)
• Question: Do you have 2FA enabled? I'm strongly in support of this being a requirement for int admins. Natureium (talk) 13:46, 31 August 2018 (UTC)
  • Hello User:Natureium. I had tried Wikimedia 2FA for a few months but currently have it disabled due to technical issues described on phab:T172079, which means that given my personal circumstances the risks outweigh the benefits using the current version of Wikimedia 2FA actually weakens my account security(edited 11:06, 1 September 2018 (UTC)). I can email you to discuss this privately if you wish (because this is a security issue) and I can totally understand if you wish to oppose my request on this basis. Deryck C. 14:36, 31 August 2018 (UTC)
• Support 78.26 _{(spin me / revolutions)} 16:27, 31 August 2018 (UTC)
• Support Kevin (aka L235 · t · c) 23:04, 31 August 2018 (UTC)
• Support checking Module:RfD_close it appears to be written in an understandable and safe manner, which I hope is deliberate! Graeme Bartlett (talk) 00:49, 1 September 2018 (UTC)
  • Thank you Graeme Bartlett! Deryck C. 11:07, 1 September 2018 (UTC)
• Support Per past work and future requirement. Lourdes 05:53, 1 September 2018 (UTC)
• Yes I know him and I trust him. OhanaUnited^{Talk page} 15:22, 1 September 2018 (UTC)
• Support for same reason as others above. · · · Peter (Southwood) ^(talk): 15:55, 1 September 2018 (UTC)
• Support having met the user at a Wikimania, I definitely trust him, based on the impressions he left me with.—CYBERPOWER (Chat) 22:22, 2 September 2018 (UTC)
• Support No major problems. ^Semi_Hypercube ✎ 15:59, 3 September 2018 (UTC)
• Support - trustworthy and competent. Tazerdadog (talk)

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.

IAdmin temporary access request for User:Beetstra

withdrawn, this shows exactly the problem with the RfA type proposals below

Earliest closure has started. (refresh) Beetstra (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 · ev · fm · mms · npr · pm · pc · rb · te) AN & VPT notices. Good evening, everyone. I just noticed that I cannot edit any of the protected pages of my bots at the moment (e.g. User:COIBot/Settings.css/User:COIBot/RevertList.css), unless I log out and log back in to the bot account. To me that is inconvenient (or I have to revert and make it regular protected pages, in which case the bot themselves can not edit them - which is one of the tricks of User:COIBot). For my on-wiki coding work, see e.g. my gadget at User:Beetstra/SBH. --Dirk Beetstra T C 15:32, 3 September 2018 (UTC) Note: I have to jump through several hoops to make things work again now. For COIBot I had to delete a page, login to the bot account, move the page from the .css to a non-.css name, then login to my admin account again, copy the text from the page, delete the page, recreate the page, and then undelete the old revisions. When I asked this, I was not aware that there were other workarounds (which, probably, do not solve all problems either ..), but to get to that stage is now a lot of work. It looks like I need this temporary access more than (later) permanent access. (and it looks that COIBot is still broken :-) and I have two more to do). --Dirk Beetstra T C 14:27, 5 September 2018 (UTC) Support. User has previously used the same technical permission without abuse. Deryck C. 15:56, 3 September 2018 (UTC) Support Is an admin. Should be granted on request. This kind of a vetting is an unneeded investment of time and absolutely not required. Lourdes 18:43, 3 September 2018 (UTC) Support, no problem--Ymblanter (talk) 18:46, 3 September 2018 (UTC) Support no problem, shows need for tools. SemiHypercube ✎ 18:52, 3 September 2018 (UTC) Support - Trustworthy, and has a demonstrated need. Tazerdadog (talk) 20:09, 3 September 2018 (UTC) Support - Has a clear need for the user rights. If Beetstra really wanted to burn the site down using these permissions, he/she would have been able to do it for many years prior and he/she could do it right now. :-) ~Oshwah~(talk) (contribs) 21:26, 3 September 2018 (UTC) I don't see why not. SQLQuery me! 21:27, 3 September 2018 (UTC) Support. No reason not to. Pretty much what Oshwah said. :-)--SkyGazer 512 Oh no, what did I do this time? 23:23, 3 September 2018 (UTC) Support Well d’uh.—CYBERPOWER (Chat) 15:36, 4 September 2018 (UTC) Oppose Nothing against Beetstra. There seems to be a common misconception that this user right is chiefly about trust. It is not, it's about reducing the attack surface (number of accounts that could be breached to cause damage). As such, I like to see a demonstrated need, and I don't see that here. In the past 5 years, the only non-Beestra userspace edits they've made were to the bot CSS pages (quarry:query/29548), which don't have to be CSS pages. It doesn't seem like much of a hassle to login to the bot account to tweak settings when they are made this rarely, and per below the CSS content model isn't needed anyway. Again my opposition is not against Beestra (has my trust, no question!), but against granting the rights to accounts that don't need it, which is why interface admin was introduced. — MusikAnimal talk 03:43, 5 September 2018 (UTC) Oppose per MusikAnimal. Beetstra does not need to be an interface administrator to accomplish this task; a small and presumably simple technical change and some page moves would restore his ability to edit his bot's settings pages. — This, that and the other (talk) 11:14, 5 September 2018 (UTC) I have little issue with a temporary grant so that Beetstra can change the data type of the pages (and apply protection as necessary)--there isn't really a need for the CSS page type. Per Musik, I would have issue if Beetstra attempted to convert a temporary permission into a permanent permission. --Izno (talk) 12:28, 5 September 2018 (UTC) I personally don't see a need for temporary interface admin to do something that only takes a few minutes. If Beestra so desires, I can move the pages now (they can protect them as desired). I'll have to check, but it's possible the interface admin checks look at the content model, and not the page title, meaning we don't even need to move the pages and the bot code doesn't need to be changed. — MusikAnimal talk 16:12, 5 September 2018 (UTC) Moving does not remove the content model, there is more necessary. And we are talking about quite a number of pages over a couple of bots (and elsewhere in userspace). --Dirk Beetstra T C 16:33, 5 September 2018 (UTC) Oppose per MusikAnimal Hhkohh (talk) 10:40, 6 September 2018 (UTC) Oppose per MusikAnimal. Enterprisey (talk!) 02:53, 7 September 2018 (UTC) Discussion @Beetstra: Have you tried converting the pages to JSON? Admins can still edit those.--Danski454 (talk) 15:46, 3 September 2018 (UTC) @Danski454: No, that is an option, and Deryck Chan suggested to consider template-level protection on a regular page which would work as well. Thanks! --Dirk Beetstra T C 16:24, 3 September 2018 (UTC) @Beetstra: in regards to some of the opposes above, is the a period of less than 60 days you would like assuming this gets done? — xaosflux Talk 11:25, 6 September 2018 (UTC) @Xaosflux: it will take me a couple of days I think (I have to find the time, I am editing less in the weekend). More in line with the bottom proposal, I have to move and edit a couple of pages, and then see if the bots don't break. I am very willing to just post to WP:BN if I think I am finished (and if something else turns up, just ask again for having it for a couple of days). I don't need full access, I can very well live with short bursts of a couple of days (if I ever turn my private gadget into a real gadget then it would require some time, but there is even in such cases no need for full-time access, a short burst of 5-7 days to set it all up, and maybe later short bursts of 2-3 days - and I think that that is true for most tasks that require the bit). --Dirk Beetstra T C 12:03, 6 September 2018 (UTC) Note: most edits will probably need me to restart (parts of) my bots that depend on the pages to make sure that the bots do not get 'lost' (like happened to COIBot yesterday with my logging in back and forth). --Dirk Beetstra T C 13:29, 6 September 2018 (UTC) Thanks for the note Beetstra I understand. From a change perspective if you are going to move to JSON configuration files, you should be able to build these without any "moves" or "content model changes" - just create the new pages and adjust your bots. This is assuming you don't care about the page histories of the old config files on-wiki (and if you do you can just leave the old pages there as well). This is not a comment on the "request" components above, just a general observation that may be useful if others are running in to this issue in the future. — xaosflux Talk 14:19, 6 September 2018 (UTC) Well, I do care about the history, as I sometimes need to look back at them. I will gothe long way. --Dirk Beetstra T C 16:46, 6 September 2018 (UTC)

IAdmin temporary access request for User:Ragesoss

Earliest closure has started. (refresh)

Ragesoss (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 · ev · fm · mms · npr · pm · pc · rb · te)}

AN notice, VPT notice

I'm requesting IAdmin access so that I can continue doing what I've done in the Mediawiki namespace for the last few years: create and maintain Guided Tours, which are mainly used by new users going through Wiki Education's training modules and by Programs & Events Dashboard users who go through the similar training modules there. Aside from GuidedTours work, I maintain the JavaScript-heavy Wiki Education Dashboard codebase.--ragesoss (talk) 16:52, 4 September 2018 (UTC)

• Support Glad to see another admin I regard in high esteem wanting to continue technical work! Deryck C. 17:08, 4 September 2018 (UTC)
• Support--Ymblanter (talk) 17:22, 4 September 2018 (UTC)
• Support Demonstrated need, and they will use it regularly. Ragesoss should have been included as one of the stop-gap users, given the data clearly proves they are among the most prolific JS/CSS editors in the MediaWiki namespace. — MusikAnimal ^talk 04:42, 5 September 2018 (UTC)
• Support no reason not to.--SkyGazer 512 ^{Oh no, what did I do this time?} 14:32, 5 September 2018 (UTC)
• Support Why not — pythoncoder  (talk | contribs) 21:33, 5 September 2018 (UTC)
• Oppose three days of 'need' in one year does not warrant a continuous bit. --Dirk Beetstra ^{T C} 17:13, 7 September 2018 (UTC)
• Support Competent in the field, clear indication of need. –Ammarpad (talk) 05:09, 8 September 2018 (UTC)

RfC: Approving the updated proposal

The purpose of this discussion is to create a process for the interface administrator right on the English Wikipedia. Please take a look at and give feedback on the proposals below. Thanks, Mz7 (talk) 23:02, 7 September 2018 (UTC)

Direct links to all proposals

1. #Original proposal
2. #Alternative / modified proposal: Grant for admins on request without process
   • #Alternative proposal with waiting period
3. #Alternative proposal, with 'indication of need'

Original proposal

Should we adopt the following process regarding the interface administrator permission?

Process for requesting

Administrators who wish to request this permission may make a new request at Wikipedia:Interface administrators' noticeboard (WP:IANB). A notice should be posted to WP:VPT and WP:AN to invite community participation. Those making a request are encouraged to answer the following two questions:

• Please describe any relevant on-wiki experience you have for this role.
• Please outline, without breaching your personal privacy, any off-wiki experience or technical expertise you may have for this role.

Requests will be open for one week, during which any editor may comment on the request. Editors are encouraged to comment on the requester's level of trust and technical ability. Requests will be closed by a bureaucrat.

Removal of permissions

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. Upon removal of administrator access, for any reason.
5. By request of the Arbitration Committee.

To be clear, this is the text that is currently on the main Wikipedia:Interface administrators page, authored primarily by Enterprisey in the section "Yet another proposed granting process" above. Mz7 (talk) 00:51, 2 September 2018 (UTC) Note: Per #Sysop_as_requirement, at this time only sysops can request this right.

Straw poll (Sept 2)

Support (Sept 2)

1. Support. After much informal discussion, I think we've refined a proposal to the point where we can make it formal. It's clear that as a community we need to pass something, and I think this is as good a starting point as any. As many others have explained before me, the intent of creating this permission was to improve the overall security of Wikimedia projects. Allowing all administrators access to JS and CSS pages that affect other users increases the risk of attackers compromising an account and running malicious code on another Wikipedia user's computer, which is a situation that has occurred on several occasions before. This proposal limits this access to individuals who have a need for the access.
   Previous proposals made the discussion time frame 24 hours and allowed requests to be rejected if any two administrators object, but many editors thought that was too short and that objections should be open to other editors, not just admins (see the section "RfC: Approving the current proposal"). Enterprisey authored the current proposal, which increases the discussion length to seven days and allows any editor to comment, the result to be determined by a bureaucrat (see the section "Yet another proposed granting process"). There was also debate as to whether we should host nominations at the newly created Wikipedia:Interface administrators' noticeboard or at WP:BN (see the section "Noticeboard?")—this proposal is going with the intadmin noticeboard idea.
   I hope this version of the proposal accommodates everyone's concerns. Again, it's clear we need to pass something at this point; if it needs tweaking (e.g. allowing non-admins to request the right, requiring a consensus of bureaucrats to grant instead of a single 'crat's discretion), we can tweak it in a future discussion. Mz7 (talk) 00:51, 2 September 2018 (UTC)
2. Support, with a note (to my peers that preferred creating a process for non-admins) that, as Mz7 said, we can always go back and modify the process to support that in the future. Enterprisey (talk!) 04:55, 2 September 2018 (UTC)
3. Support - happy with this for now. I think there may be circumstances where non-admins should be allowed to have access, but we can discuss that later if needed. -- Ajraddatz (talk) 05:21, 2 September 2018 (UTC)
4. Support as well. Like others here, I also think we should look into a process for non-admins once we get this proposal implemented. — AfroThundr ^{(u · t · c)} 06:20, 2 September 2018 (UTC)
5. Support and hope his will be extended to non admins who need it also. –Ammarpad (talk) 07:03, 2 September 2018 (UTC)
6. Support reasonable, though I'd prefer that the activity requirements be three or six months rather than twelve months (but making it a simple request at WP:BN to get back the rights if they were removed for activity), and 1 week seems rather unnecessarily long for discussion, though I suppose after the first few rounds new intadmins will be rare. Galobtter (pingó mió) 08:12, 2 September 2018 (UTC)
7. Support, sounds reasonable.--Ymblanter (talk) 08:30, 2 September 2018 (UTC)
8. Support sounds great Hhkohh (talk) 09:16, 2 September 2018 (UTC)
9. Support Seems logical, fair, and a reasonable process to me. ~Oshwah~^{(talk) (contribs)} 09:25, 2 September 2018 (UTC)
10. Support, and agree with comments above by Galobtter re activity and regaining the bit, and Ajraddatz on non-admins, Though as this is actually a species of admin, a RFIA would probably be the way to go. · · · Peter (Southwood) ^(talk): 13:34, 2 September 2018 (UTC)
11. Support looks good --Danski454 (talk) 16:30, 2 September 2018 (UTC)
12. Support. I personally would support reducing the time to 48 hours - I don't think a week-long discussion is really necessary and I don't want to make the process for granting requests like a second RfA. However, this proposal seems reasonable, and I hold no objections to getting this going and then making modifications from there.--SkyGazer 512 ^{Oh no, what did I do this time?} 16:42, 2 September 2018 (UTC)
13. Support Per my comments above. 48-72h would be better, but, meh. ~ Amory (u • t • c) 18:07, 2 September 2018 (UTC)

    Expanding on my comment here rather than in the oppose section. Regarding the idea that this will be just another RfA process (JARfA?), I think the better analogy is WP:EFM: users with a demonstrated technical ability and use/need ask, and folks assess the need based on that. Quiet, technical, and like the edit filter, something most people don't interact with, so free from drama. Second, separating this ability from RfA can only make RfA better; it means the risk of any given sysop will be lowered, so while it won't make RfA perfect, a little less risk can only help. Thirdly, just because we've existed with a risky situation doesn't mean we should continue it; the risk is on par with a Bureaucrat account. Kevin expands below on just some of the things one could do with this ability, but there are more. Wikipedia is the 5th most visited site in the world, and I am consistently surprised we haven't had an incident where someone does something "for the lulz." ~ Amory (u • t • c) 12:03, 3 September 2018 (UTC)

14. Support not perfect but it gets things moving. --Rschen7754 18:08, 2 September 2018 (UTC)
15. Support – a clean and straightforward process. We need more of those. — JFG ^talk 21:35, 2 September 2018 (UTC)

    Extra remark: like other commenters, once this process is in place, and if at all possible technically, I'd like to see it open to tech-savvy non-admins. — JFG ^talk 21:42, 2 September 2018 (UTC)

16. Support Logical, efficient, and fair. ^Semi_Hypercube ✎ 22:20, 2 September 2018 (UTC)
17. Support for non-admins, but oppose for admins - see oppose below. WJBscribe (talk) 22:45, 2 September 2018 (UTC)
18. Support. I don't fully agree with all elements of this proposal, but I think something needs to be adopted that can be amended later. I don't agree with the community's decision that only admins should hold this permission, but as long as that decision is the consensus of the community, this policy is acceptable to me. At risk of violating BEANS, I suggest that some of the opposes may not quite appreciate the degree of access that IAdmin has – with a click or two, IAdmins can assign themselves CU/OS and mass-access highly sensitive data that way; violate the privacy of and run malicious code on the computer of every person who views Wikipedia (until discovered); run cryptocurrency mining rigs on Wikipedia readers' computers (this has happened on other WMF projects); etc. I personally doubt that this will turn IAdmin requests into an RfA 2.0 – just look at the ease with which all of the temporary IAdmins have been granted the permission above. I also think this process is insufficient for non-admins – I envision a proper RfA-like process for those who are trusted enough to pass an RfA but don't meet some of the other requirements (content creation/etc.). For admins, a lightweight noticeboard request and comment is appropriate in my view. Kevin (aka L235 · t · c) 23:34, 2 September 2018 (UTC)
19. Support to get something going. As far as the opposition comments so far, this was designed with "higher expectations for membership" (than administrator) in mind, and it is not the first time such a technical control has been implemented globally (for example bigdelete was removed from admins, not at the request of the local community - but unlike bigdelete the local community has been empowered to issue iadmin access to users). I'm not strongly opposed to the idea of non-admin iadmins - but would rather get this in to production before what I anticipate will be a much more contentious discussion for such a future amendment option. — xaosflux ^Talk 01:19, 3 September 2018 (UTC)
20. Support, but prefer the shorter procedures proposed below. We need to get ourselves out of the limbo of not being able to grant this permission formally. Deryck C. 11:55, 3 September 2018 (UTC)

    We can also do that by just allowing crats to assign the permission to any admin who asks, can't we? So why do you support this specific proposal? Regards SoWhy 13:45, 3 September 2018 (UTC)

    @SoWhy: What Deryck is trying to say is, that right now, there exists no process of granting this permission on a permanent basis, and that having no process at all is worse the having a flawed process. He's just supporting the fact that this group needs a process, and it needs it now. That's how I interpret his rationale.—CYBERPOWER (Chat) 13:54, 3 September 2018 (UTC)

    @Cyberpower678: That might be a possible interpretation but saying "I support proposal X because it creates a process" does not explain why you support X and not Y or Z. Hence my question. Regards SoWhy 15:20, 3 September 2018 (UTC)

    Where's Y and Z. I only see X, while the opposers are creating Y.—CYBERPOWER (Chat) 15:52, 3 September 2018 (UTC)

    @SoWhy: I would much rather crats simply granted interface-administrator to any admin who asked for it at their own discretion, but User:Xaosflux has refused on behalf of crats to even grant the permission temporarily [2] [3] unless there is a community mandate. So I am willing to support any proposal that instructs crats to grant interface-administrator to current admins. If anyone drafts a simpler proposal I am happy to support that as well, like how I have supported all the draft proposals above. Deryck C. 16:16, 3 September 2018 (UTC)

    @Deryck Chan: just to note, I am the author of the temporary access processes currently running on this page. If the community wants to approve "must grant to any sysop at anytime without question" then you don't really need bureaucrats involved: start the us-vs-them fight with the developer team by requesting a configuration change to allow admins to addself/removeself from this group (though I expect it will end up at meta:Limits to configuration changes. — xaosflux ^Talk 16:30, 3 September 2018 (UTC)

    Oh stop it, there is no "us vs them" Back to the point, there are two issues here. First, everybody who was a sysop as of last month had the rights of what is now an interface administrator, so I believe these users should be allowed to claim their permission through an expedited process. Second, we do have a number of permissions such as rollback and filemover and where we trust individual admins with full discretion to grant rights to any user, subject to policy but not community discussion; I think the process for bureaucrats to grant interface administrator rights should be kept simple in a similar vein. Deryck C. 17:22, 3 September 2018 (UTC)

21. Support no obvious issues that would cause me to prevent the intadmin pool from being expanded at this time. Anything else can be hammered out later. --SarekOfVulcan (talk) 16:08, 3 September 2018 (UTC)
22. Support addresses my concerns raised in the above discussions. Amory's comment above on how this is different from an RFA clone aleviated most of my concerns on that front. I am strongly opposed to giving this ability to all admins which seems to be the main alternative offered by the oppose rationales. This is not a situation to wait around for problems to appear if we gave it to all admins: compromised or malicious accounts can run malicious code on readers' computers and threatens data or economic loss for readers that we cannot fix. That we've been lucky so far is no reason to keep doing it. This bit should be given to as few people as possible, and only for as long as they continue to use it. I am open to non-admins going throught this same process for the bit but appreciate the concerns raised by Kevin. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 17:26, 3 September 2018 (UTC)
23. Support: I don't understand why people are opposing. As Kevin explains, the risks of this right are enormous so removing it from admin privileges was both the right move and not something we have authority to overturn. As Deryck Chan says, we need a process imminently so that we have at least a sizeable quantity of iadmins while we squabble over the precise details. I would probably support a slightly more lax procedure but opposing doesn't argue for a less strict procedure; it just stops any procedure from being put into practice. I also think fears this would become RfA2 are unwarranted, as this is a very technical area that I wouldn't expect many users without substantial technical knowledge to watch closely. — Bilorv_(c)(talk) 19:11, 3 September 2018 (UTC)
24. Support Admins need to stop seeing this as the masses rising with pitchforks with some kind of RfA sequel (maybe we are :'/), but more importantly, it's as Anomie said above. We're gravely underestimating what a compromised here-there might do. I doubt this proposal will be opened up to non-admins in the near future, every unbundling has an impressive amount of resistance; but the point about security questions is undebatable. --QEDK (後 ☕ 桜) 19:55, 3 September 2018 (UTC)

    Support: It's not a perfect solution, but it's definitely a step in the right direction. I need more time to thoroughly review this after reading more of those who opposed. Neovu79 (talk) 08:43, 4 September 2018 (UTC)

25. Support Better is the enemy of good enough. --Ahecht (TALK
    PAGE) 15:25, 4 September 2018 (UTC)
26. Support - with even more conditions. IAs should be required to identify with the WMF. My concerns and reasons are noted below, under Oppose #1 by Courcelles. - wolf 18:58, 4 September 2018 (UTC)

    I would strongly oppose identification with the WMF as a requirement. Bureaucrats, those granting the right, are not required to identify. That aside, in all the time in which all administrators held this right, has it ever been used maliciously? Bottom line: the fewer roles that require identification to the WMF, the better; anonymity should be respected unless, quite frankly, the WMF forces those wishing to serve in a certain capacity to identify. — Godsy ^(TALK_CONT) 19:26, 4 September 2018 (UTC)

    "...has [IA] ever been used maliciously?" - Not that I know of. Can you say for certain is hasn't? If not, we should do everything we can to ensure there is never a first time. But should that occur, we should be able to hold those responsible for the abuse accountable. That might require more than a simple desysop and a block. That's where identification comes in. Perhaps every anonymous user with access to this right should identify, considering the kind of access we're talking about here. - wolf 22:05, 4 September 2018 (UTC)

27. Support this looks fair enough. This process isn't RfA, the bureaucrat isn't being asked to assess the consensus of the discussion. It just provides people with an opportunity to comment on the request. I don't think this should be given to all admins either. Admins who don't have the relevant technical experience shouldn't have the right. Hut 8.5 21:23, 4 September 2018 (UTC)

    It's not RfA v.2 indeed, but still a bureaucrat has to assess consensus of the commenters. Otherwise, you're suggesting that, even if the consensus of the commenters shows clearly the user is not suitable for the right, the bureaucrat can just disregard that and assign the permission since he "...isn't being asked to assess the consensus of the discussion.". –Ammarpad (talk) 07:17, 5 September 2018 (UTC)

    I'm suggesting it comes down to a judgement call by a bureaucrat. Obviously the bureaucrat will read the comments and take them into account when making the judgement call, but it is still down to the judgement of the bureaucrat and not the commenters. Hut 8.5 19:59, 5 September 2018 (UTC)

28. Support I've said what I needed to say many times on this page, but in summary: Demonstrated need is the biggest requirement, not trust (admins already have proven that), and we need time to evaluate that someone meets this criteria. A week of waiting seems trivial for someone who doesn't regularly edit site/user JS/CSS (most of these accounts already have access!). I'd even be okay with 4 or 5 days, but definitely need more than 24 hours which was the original proposal. — MusikAnimal ^talk 03:53, 5 September 2018 (UTC)

Oppose (Sept 2)

Very weak oppose because of removal criterion #4, which appears to imply that interface-administrator is necessarily a position of higher trust than sysop. I can imagine an emerging troop of editors who hold templateeditor + interface-administrator but not sysop because they're technically highly competent to be trusted to edit important code, but not sufficiently diplomatically talented to be trusted with the delete and block buttons. #4 would also tie the hands of AN and ArbCom, preventing them from letting a user continue as interface-administrator but revoking sysop, which is something the community might like to try at some point in the future. Deryck C. 21:18, 2 September 2018 (UTC)

Though another discussion was closed which requires all applicants of the permission to be an admin to begin with. So that's not really debatable.—CYBERPOWER (Chat) 22:15, 2 September 2018 (UTC)

The proposed policy is a starting point more than it is a final policy and is more to get things going for those admins who want the tool back (even if they didn't want to take Xaosflux up on the opportunity to have the interim tool). There are a number of questions like "non-admins" that I think are reasonable, but I think there is a significant divide on that question that we should talk about it separately to "give the ones who knew how to use it before and had the permission before", which is the current proposal. --Izno (talk) 23:46, 2 September 2018 (UTC)

Point taken. Switch to support for now since it's better to have a granting policy than not to have one. Deryck C. 11:54, 3 September 2018 (UTC)

1. Far too complicated a process for my taste, which is to just give it to all admins who ask. Courcelles (talk) 21:37, 2 September 2018 (UTC)

   The main objection to this approach when we discussed it before is that there will inevitably be administrators who ask for the right but never use it. As interface administrators essentially have the ability to run code on another user's computer, the intent of the process was to limit the size of the user group only to those that truly need it. The worry is that by opening it up to "any admin that asks", we risk inflating the user group in the long run and ending up with the same security problem we did before. Mz7 (talk) 23:37, 2 September 2018 (UTC)

   "...just give it to all admins who ask.". Sorry, but no. Make that hell no. We have, what? About 1200 admins? Do you trust every one of them right now? Every one? Including the ones that got the bit back in the days when it was given to anyone who asked for it? (RfAs passed in a couple days with a !vote of 6-0... not exactly "running a gauntlet"). What about admins that have shown some truly disturbing behaviour? Admins that have had their bit taken and returned? More than once? Would you trust every one of them with say, your banking info? But you would allow any one of them fuck around with your computer? "The ability to edit CSS/JS that is executed in other users' browsers is very powerful and potentially dangerous in the hands of a malicious user" Sorry, but no. We have many good admins, some great admins in fact. But just becasue they passed an RfA doesn't mean you truly know them, and it certainly doesn't mean you can trust all of them with that particular type of access. (and yes, I know these comments will be unpopular in some circles) - wolf 21:40, 3 September 2018 (UTC)

   I don't think the issue is trust... it's attack surface. I can't count how many times this has been reiterated on this page. Granting access upon request defeats the purpose. — MusikAnimal ^talk 03:55, 5 September 2018 (UTC)

2. I agree with Courcelles above. I'm really not crazy about following RFA's format either as I mentioned in the comments below. SQL^{Query me!} 21:51, 2 September 2018 (UTC)

   It only follows RFA format in the length of time. Maybe the policy should make it clearer that it is not RFA 2 and that the only judgement in the request for IA is whether the admin has technical trust rather than just the social trust garnered at RFA? --Izno (talk) 23:46, 2 September 2018 (UTC)

   There is an encouragement to keep it to technical ability, but no requirement to do so. I'm not sure what to say if you don't think that there are strong parallels here to RFA. The process described sounds identical to me. SQL^{Query me!} 00:31, 3 September 2018 (UTC)

   I get that, though I would say the intent is rather to mirror the process for WP:EFM rather than RfA. ~ Amory (u • t • c) 01:14, 3 September 2018 (UTC)

3. Oppose per Courcelles. I don't see why any admin who needs this cannot just have it, as they always have done so. I don't see the need for non-admins to have it either. Aiken D 22:19, 2 September 2018 (UTC)
4. Oppose per Courcelles. I'm OK with this for non-admins requesting the right, but not for admins. This used to be something all admins could do, there was no enwiki consensus to remove this ability from admins, and it seems to me on that basis any admin in good standing should be able to request restoration of the ability to edit these pages. WJBscribe (talk) 22:46, 2 September 2018 (UTC)

   Regarding "all admins had this and now don't", realistically, if user scripts had been built today rather than 15 years ago (if they were built at all!), this user right would have been required from the start. Most admins neither need nor want this. I don't think it's unreasonable to ask admins to have some technical skill and to Know What They Are Doing; as it happens, most don't (and most probably have a reasonable approach on the point). --Izno (talk) 23:46, 2 September 2018 (UTC)

   On the other had, should we approve this proposal, that would essentially be a consensus that not all sysops should have it. At any rate, giving IA to any sysop and using the above process for non-sysops would have the opposite effect of the intent behind the change — it'd open up the right to edit these pages to more users, not fewer, creating a larger threat. ~ Amory (u • t • c) 01:14, 3 September 2018 (UTC)

   That's assuming all admins request this permission. I trust admins to only request it if they have a genuine need for it, which will be a small subset of the total number of admins. WJBscribe (talk) 23:56, 3 September 2018 (UTC)

   @WJBscribe: kind of like how they only hold on to sysop if they have a genuine need.... From last months inactivity report of admins that "kept" that access see 1, 2, 3, 4, 5 examples of actual behavior. — xaosflux ^Talk 00:04, 4 September 2018 (UTC)

   Actually, I more had in mind edit filters as a comparison. It's not like every admin adds that for the sake of it... WJBscribe (talk) 11:14, 4 September 2018 (UTC)

5. Like the previous four above me, it seems like an invitation for RFA round two. I'm fine with this process for those who are not admins, but admins have already had this ability and it should be readily given to them. Killiondude (talk) 23:13, 2 September 2018 (UTC)

   Re: admins have already had this ability, the point is that this ability was recently removed from all admins for security reasons, and now it can be added back to admins who request it and demonstrate a need. It would be unfair to give it more-or-less automatically to newly-minted admins, while the corps of current admins would have to request it specifically. — JFG ^talk 23:50, 2 September 2018 (UTC)

   Yes, I am aware of the background and proposal. I like Izno's thought above in reply to SQL. Killiondude (talk) 00:16, 3 September 2018 (UTC)

   I don't see this as necessarily a bad thing, there are quite a few admins who are not trusted by the community, or for whom this would essentially be their first RFA. --Rschen7754 02:34, 3 September 2018 (UTC)

6. Oppose - Per Courcelles and WJBscribe. - FlightTime (open channel) 23:47, 2 September 2018 (UTC)
7. Oppose Just make it the same as for the AbuseFilter. Most admins have never been vetted to be allowed to edit this, most admins are not vettted for the mediawiki namespace. This results in just another RfA-type process, frustrating the hell out of people, and capable people not getting access because some people have axes to grind, or because you have some broken mops in the cupboard. This is a slippery slope towards limiting access to the MediaWiki namespace or module namespace. We only need clear process for when the right was removed from you, that you are not allowed to self-reinstate. --Dirk Beetstra ^{T C} 03:38, 3 September 2018 (UTC)

   In addition to my earlier post (thinking about it a bit further), I will move to Strongly Oppose - I think that ALL admins should standard have this bit enabled (or at the very least enable it at will per my original comment), and only have it removed when they have grossly misused or abused it (where re-instating the right without discussion would be abuse of rights). The reason for that is that when someone with the bit does break the wiki I expect a large editor base to be able to revert to an earlier version, not just the few who have been specifically granted the bit. Admins have had this right for a long time, and most stay away from editing (as they stay away from the MediaWiki namespace) because they know of themselves that they do not have the capability to work in that area and that if they would break something there that the community would at least WP:TROUT them (I've seen enough blacklist requests of admins that knew that they could but did not want to because they were afraid to break something). The risk of them breaking something is minimal, and is outweighed by the need to quickly revert. --Dirk Beetstra ^{T C} 07:26, 3 September 2018 (UTC)

   The right was removed because it posed a demonstrable security risk to the Wikimedia projects. It’s not just about whether we can trust administrators not to misuse this ability, it’s about reducing the pool of accounts that attackers can compromise to run malicious code on someone else’s computer. To return the permission to all adminisrators would reintroduce the security flaw that was identified by the technical community. Mz7 (talk) 07:50, 3 September 2018 (UTC)

   @Mz7: Absolutely NOT convincing at all, and more a reason to strongest possible oppose to NOT hand it out to all administrators.  1) In all the years that administrators had this ability no account was compromised and subsequently used to insert malicious code.  2) even if we hand this out to a sub-significant number of accounts, those would be the accounts to hack (do you really think that a hacker who wants to exploit this would be so stupid as to try to hack a random admin account?).  3) if one of the now granted iadmin bit accounts is being hacked and that account starts to damage Wikipedia, there is only a small number of other accounts that can repair the situation (and blocking the compromised account is obviously not enough, admins cannot undo).  (and 4) there is no reason to hammer all opposers of this process as if we do not know why it was taken out).  --Dirk Beetstra ^{T C} 08:15, 3 September 2018 (UTC)

   While I'm on the oppose side for this specific RFC, I want to make sure I point out this threat is absolutely not imaginary, and has actually happened. example SQL^{Query me!} 08:41, 3 September 2018 (UTC)

   I know, the same goes for the not-imaginary f*ck up on that could occur on the MediaWiki namespace: once a mistaken edit on the meta spam blacklist resulted in all domains with a 't' to be blacklisted on all 700+ MediaWiki wikis (and many outside). The solution was a quick revert and then solve the problem, but that needs a significant pool of editors that can do said revert. Realizing where the mistaken edit (which complex broken regex?) took place may take time (there was significant time between the blacklisting and de-blacklisting, the blacklisting admin may already have been in bed).

   The paradox is difficult to solve - you want a small pool of editors that possibly could get hacked, but you want a significant pool of editors that can solve a problem in case one of the editors does get hacked, or one of the editors screws up. Or you have to completely take the right. --Dirk Beetstra ^{T C} 08:54, 3 September 2018 (UTC)

   I'm with ya there, and I probably placed my reply in a bad place. I just wanted to make sure we were all aware that this isn't a 'what if' situation. SQL^{Query me!} 09:13, 3 September 2018 (UTC)

   I think I'm just not convinced that anything but total removal of 'our' rights to edit the interface is going to solve this issue. We have about 300 active administrators here, but I think a 'healthy base' of interface admins would probably amount to at least half of that. You don't want a hacked piece of code to stay for anything more than 2-3 minutes, and a broken piece of software not more than about 30 minutes. With our current base of 6 interface admins I doubt that a smart choice of hacking an account (which leaves 5) of which 2 others are also asleep (assuming that those three are on the same side of the planet), 1 having dinner, and 1 doing something important at work .. that may be quite a bit longer. --Dirk Beetstra ^{T C} 10:17, 3 September 2018 (UTC)

   Meh - if there is a hacked piece of code, then that's enough of an emergency that the 30 or so pretty active stewards can act too and so can the crats. Granted, the amount should probably be more like ~15 or something, not 6, but I don't think 150 interface admins are needed. Galobtter (pingó mió) 10:25, 3 September 2018 (UTC)

   I think a solid base of 20 or so should be able to handle requests in a fairly timely fashion, and any incidental changes that arise. I'll add too that I think the worry is less about an accidental screw up and more that someone malicious can do something that would require devs to fix. Interface admins won't necessarily be able to undo it, but having fewer accounts capable of doing something like that reduces the threat. ~  Amory (u • t • c) 14:26, 3 September 2018 (UTC)

   (edit conflict) If the risk is really so low that it is always quickly resolved, then there was no much reason to separate it, and to minimize the number of people who could possibly break it in the first place.  Still, I am also fine with the bureaucrats just handing out the bits 'at their own discretion' to people who can reasonably show that they need it. --Dirk Beetstra ^{T C} 14:32, 3 September 2018 (UTC)

   In reply to User:Xaosflux: I also would not be opposed to having non-admins this particular bit, but that I think that that does need a separate process.  --Dirk Beetstra ^{T C} 07:26, 3 September 2018 (UTC)

   This has repeatedly been said on this page (not just by me), but the issue is not trust, it's a matter of security, to reduce the attack surface (accounts that could be compromised in order to cause damage). AbuseFilter is child's play compared to what JavaScript can do. Can you use edit filters for monetary gain, to cause permanent damage to the site, to people's privacy, and consequently even potentially endangering people's lives? Of course not. Can you with JavaScript? Yes. No, it hasn't happened on enwiki yet, but it has elsewhere, and we shouldn't wait for it to happen here and then decide to change our ways. — MusikAnimal ^talk 04:34, 5 September 2018 (UTC)

   @MusikAnimal: OK, we are now getting seriously in WP:BEANS territory, but this is implementing a false security. Again, whether we have 1, 10, or 100 editors with access to iAdmin, it does not matter except for maybe the amount of effort it takes to find someone with access to attack that is not having sufficient security levels (and if it is a proper hacker, they are not stupid). But still, my main problem is with the procedure of how to get the bit when you need it. --Dirk Beetstra ^{T C} 08:10, 5 September 2018 (UTC)

   Interface admin was carefully thought out by the technical community, including the security experts (not me :). It's the best we have right now. All I can say is a smaller pool of accounts to hack definitely helps, even if it's easy to see which accounts those are. — MusikAnimal ^talk 16:21, 5 September 2018 (UTC)

8. Oppose Per Courcelles. Further, I still haven't understood when or where did the community gain consensus to remove this right from administrators. Pending that, the default should be what Courcelles or Rob suggests – that administrators should be granted this right on request. Lourdes 05:02, 3 September 2018 (UTC)

   The right was removed from administrators on all Wikimedia projects as a consensus of the Wikimedia technical community, not by local projects, because it posed a significant computer security flaw. Mz7 (talk) 07:50, 3 September 2018 (UTC)

9. Oppose per above. Admins were able to do this for years and no one blew up the wiki—those who shouldn't be screwing with something tend to know they shouldn't do that, and don't. If needed even occasionally or just for a few specific tasks, an admin should be able to request the right and just have it granted. They've already demonstrated community trust by passing RfA. Besides, given how people currently treat the RfA process and those who dare step into it, I don't want to make any more processes that are anything at all like it. Seraphimblade ^{Talk to me} 05:43, 3 September 2018 (UTC)
10. Oppose - Per Courcelles and WJBscribe. Limiting the access is probably a good idea to prevent mistakes (I don't need or want the access, I have no interest) but any admin that requests it should automatically get it. This shouldn't be a "super admin" bit. I would even support admin being able to enable and disable the bit themselves, like abuse filter. I don't have a problem if the default state is "not enabled", but admin do not need Crats to decide if they are technically capable as we've already walked through the gauntlet and the community has decided our judgement can be trusted. Having the Crats decide who can and can't obtain the bit would be putting a new duty on Crats that I'm not convinced is a good idea. I'm neutral as to non-admin obtaining the bit, and see little harm, but there would need to be some process of community approval rather than just Crat approval, imho. Dennis Brown - 2¢ 11:48, 3 September 2018 (UTC)
11. Oppose per Courcelles and Dennis Brown. Admins are already trusted users and thus should be able to request any such right that allows them to improve the wiki without a new RFA-style process for creating "admin+" or "super admins" as Dennis aptly puts it. IA should be the same as the edit filter: Available when needed but not assigned to the majority of admins. That said, I personally still believe the whole IA change misguided anyway because clearly the last 15+ years have demonstrated the risks are minimal. But if we have to have this change, at least don't force admins to jump through hoops to get it. Regards SoWhy 13:42, 3 September 2018 (UTC)
12. Oppose this talk page is a relative backwater. I still support having a 48 hour hold at BN, which is much more watched and transparent (and less likely for notices to be ignored.) That, and the fact that even if this were grant on demand means that we’d still have something like a 99% reduction in users with access means the security concerns here are really overstated: any restrictions here are good. The question of how good is relative and needs to be balanced with community usefulness. The safest would be to let no one have it, but it also wouldn’t be useful then. TonyBallioni (talk) 15:45, 3 September 2018 (UTC)

    @TonyBallioni: as far as visibility goes, there are just over 1000 watchers at BN, this proposal requires notices at AN (~4500 watchers) and VPT (~3100 watchers). — xaosflux ^Talk 16:09, 3 September 2018 (UTC)

    @Xaosflux: it’s the noise to request ratio. Any post at BN will have significantly more attention than a post at VPT/AN because things don’t get posted there often. Also, I generally have misgivings about letting people who are primarily technical contributors have control over technical things that impact other users: there is often a real disconnect, and having it not be as visible to the entire community runs the risk that we’d have artificially higher standards than the community as a whole wants. TonyBallioni (talk) 16:22, 3 September 2018 (UTC)

    @TonyBallioni: I got the impression from some of the earlier discussion that general notifications aren't useful - but this could easily be integrated to T:CENT or MediaWiki:Watchlist-messages. Alternatively, adding WP:BN to the places to notify could be added in without otherwise cluttering up BN. — xaosflux ^Talk 16:33, 3 September 2018 (UTC)

13. Oppose anything beyond a hold and a clearly-stated need. Specifically, oppose requiring admins to go through an RFA-like process just to get access to do something the community never even agreed to remove from their toolset. I understand restricting access to this, but a hold and need accomplishes that. ~ Rob₁₃^Talk 16:39, 3 September 2018 (UTC)

    @BU Rob13: what sort of potential opposition are you trying to say should be invalid? It should be trivial for 'crats to apply "less weight" to opposition along the lines of "I don't like BU Rob13", but I don't think we should disregard something like "Oppose, BU Rob13 was admonished by ArbCom last week for edit warring in the MediaWiki space". — xaosflux ^Talk 16:50, 3 September 2018 (UTC)

    I'm saying anything along the lines of oppositions based on lack of trust should be invalid. If we genuinely don't trust an admin to be able to use this, they shouldn't be an admin. I trust admins not to mess with this/request this if they aren't technically able. I trust them not to edit war, etc. ~ Rob₁₃^Talk 19:17, 3 September 2018 (UTC)

14. Oppose This is a technical right and yet, unlike other technical rights, this is being reserved for admins who can have it at the asking so long as there isn't political resistance from the hoi polloi. If WMF, in the depths of their ignorance, will not simply allow admins to edit JS/CSS, then we need a thought-out selection process for technical editors or we're just passing out candy. Chris Troutman (talk) 17:53, 3 September 2018 (UTC)
15. Oppose - Given the result of the section above requiring Sysop, we really only need to answer three questions when evaluating an IA request: Has anything come up since the RFA that massively changes the trust the community has placed in them? Are we confident that the same person is in control of the account? Does the user have the technical skill to evaluate complex JS/CSS to ensure it does what it is expected to do and is not malicious? Those are the only germane questions. The solution, therefore is not to create another pseudo-RfA, and subject users to another broken inquisition-like process where anything and everything should be dredged up. Instead the discussion should be shorter, lasting only 2-3 days, and advertised only to the boards that can speak to those questions (VPT and BN), and not to broader community boards, where people will bring up points unrelated to the questions above. We also need an aggressive clerking system to filter out and strike comments that are not very explicitly germane to one of the above questions. This proposal results in a new RfA being formed that will ultimately discourage qualified admins from applying. (On a sidenote, it is a perfect application process for non-admins if sysop as a requirement gets overturned. I'd hate to force someone like Enterprisey to go through an RFA just so they can apply for this. Tazerdadog (talk) 19:55, 3 September 2018 (UTC)
16. Oppose This should be looked at by bureaucrats and nothing more. Give the right to them if they ask unless there is a history of problematic usage of the right. If you want non-admins to have this right, then set up a different process. Nihlus 21:19, 3 September 2018 (UTC)
17. Oppose - Bureaucrats should grant this as necessary. No need to create another RfA-like process. — Godsy ^(TALK_CONT) 03:22, 4 September 2018 (UTC)
18. Oppose per WJBScribe. The need to be able to understand js/css script is unnecessary. Can I write code? No. Can I read an edit request on a js/css talk page, confirm that the person making the request understands what they are doing and that there is consensus to make the change? Yes. That is all that is required, and therefore the permission should be given to all admins on request. (Also it would allow me to change css/js on my alternative account without the need to log in separately.) Voice of Clam (formerly Optimist on the run) (talk) 14:06, 4 September 2018 (UTC)
19. Oppose per Voice of Clam, TonyBallioni, and SoWhy. I can see this quickly devolving into RfA 2.0, we don't need that. Supporting the alt proposal below. — Insertcleverphrasehere ^{(or here)} 00:28, 5 September 2018 (UTC)
20. Oppose Making people jump through hoops again just to do something that they had been able to do for years is downright silly. It should be a simple process, not another vote. OhanaUnited^{Talk page} 01:04, 5 September 2018 (UTC)
21. Oppose In general, I don't think that the RfX processes here are really set up to check someone's technical and security skills, they focus on social/policy skills. The former are more important than the latter for Interface admins while the latter get more focus in regular admins. Maybe I'd agree with an RfA-like process for non-admin Interface admins but not in general. Jo-Jo Eumerus (talk, contributions) 15:25, 5 September 2018 (UTC)

Discussion (Sept 2)

• I figured, since #Yet another proposed granting process seems to have a good amount of support, now was a good a time as any to start the formal RfC. If you think I was too hasty and we still need to discuss this informally, I would be happy to collapse this section and deactivate the {{rfc}} template. Mz7 (talk) 00:51, 2 September 2018 (UTC)
• Is the presumption that an administrator should receive this user right unless there is a compelling reason they should not, or does there need to be a strong consensus for handing out this user right? That is unclear from the proposal. ~ Rob₁₃^Talk 03:09, 2 September 2018 (UTC)

  For reference, the RfA header has At the end of the discussion period, a bureaucrat will review the discussion to see whether there is a consensus for promotion. - As far as "presumptions" go the tech guidance was that this should have higher expectations for membership - so I'd expect that a consensus would need to emerge for actual support, and that the lack of such consensus would not be sufficient. — xaosflux ^Talk 03:18, 2 September 2018 (UTC)

  I agree with xaosflux's interpretation. · · · Peter (Southwood) ^(talk): 13:27, 2 September 2018 (UTC)

• Derp, I just closed a discussion further up where the right is requested at the WP:BN. The section is #Sysop as requirement.—CYBERPOWER (Chat) 16:55, 2 September 2018 (UTC)

  @Cyberpower678: I think the venue is more flexible and the more important part of that section was establishing the prerequisite adminship component, thoughts?. — xaosflux ^Talk 17:03, 2 September 2018 (UTC)

  True.—CYBERPOWER (Chat) 17:36, 2 September 2018 (UTC)

  I don't think there's any basis for requiring 6 months to pass before the issue of whether or not adminship is required to request this right is revisited. I think imposing such a limit lies outsides the remit of the person closing a discussion. If consensus changes sooner, so be it... WJBscribe (talk) 22:43, 2 September 2018 (UTC)

  6 months was not a hard restriction. It's simply advisory so the more important issues of establishing process for requesting are set up first. But knowing enwiki, that can take forever.—CYBERPOWER (Chat) 15:57, 3 September 2018 (UTC)

• I made this edit today regarding whether there should be consensus to provide the tool... I'm happy to make it a separate heading under this discussion or in a separate discussion on what kind of consensus (no, not % range like with RFA) should be expected out of the community consult for a bureau to promote. Someone can revert me if that one feels bad. I also made a slightly earlier edit to clarify that the bureaucrat should be uninvolved, which I don't expect to be contentious. --Izno (talk) 20:02, 2 September 2018 (UTC)
• I'm concerned to see us using another week-long RFA-Like process here, with as much of a broken cesspit as RFA is. I see that there's at least encouragement to focus on the editor's technical ability, which is a step in the right direction. SQL^{Query me!} 21:27, 2 September 2018 (UTC)

  @SQL: with admin being a prerequisite (currently) I'm not worried about this turning in to a big drama-fest, we've had 9-mini requests on this page so far and they have all been as calm as they could be. — xaosflux ^Talk 22:39, 2 September 2018 (UTC)

  @Xaosflux: - I'm not sure a handful of temporary requests in the very earliest days while we're still drafting the policy is really enough data to make me feel that mirroring RFA won't end up with something like RFA down the road. SQL^{Query me!} 22:50, 2 September 2018 (UTC)

• I think this is a good idea to separate that ability from the admin flag: it mitigates the risk of a mishap since most admins don't routinely edit the interface. I don't see however why this needs to be more complex than a "Hi, I need the bit because xxx" followed by " Done" conversation. Reading the proposal, it looks however like this is turning into another of our crazy processes and there's no need for that: there has been virtually no admin abuse and we can assume that someone that wants the bit is trying in good faith to fix something that is broken. Regarding non amdmins, is there really a need for editing the interface that can't be solved using the {{editprotected}} process? -- Luk ^talk 09:03, 3 September 2018 (UTC)

• Since there are now three alternative / counter proposals, can we maybe close this RFC that is unlikely to result in consensus anyway (imho) and start a new RFC where people can !vote on all four proposals and also indicate their preferences which proposal is their first, second, third etc. choice? Regards SoWhy 10:18, 6 September 2018 (UTC)

  Second that. Lourdes 10:36, 6 September 2018 (UTC)

  I've restructured the RfC so that it explicitly encompasses the proposal below. I hope this is a satisfactory way to avoid having to start completely over with a new RfC. Mz7 (talk) 23:10, 7 September 2018 (UTC)

  Mz7, I'm very confused as to what is going on here. I thought you had closed the above RfC, now it is open again. Mainly commenting as I had changed CENT because of it, and now I see a revert there to this RfC, which hasn't been commented on in 3 days. TonyBallioni (talk) 15:12, 8 September 2018 (UTC)

  @TonyBallioni: I'm sorry about the confusion. I'm also a little frustrated with trying to organize this. The reason I've reopened this is to have all of the current proposals on this page closed together as one giant RfC, instead of it being just one RfC about one proposal. Maybe I could have done this without re-opening the section I closed, but I thought it was important that the closer consider comments in this section. Mz7 (talk) 17:11, 8 September 2018 (UTC)

  Makes sense, and I was not critiquing you (you've done a wonderful job herding cats here.) I was just trying to figure out what was going on/if the above was still being actively considered. Thanks for all your work TonyBallioni (talk) 17:16, 8 September 2018 (UTC)

Alternative / modified proposal: Grant for admins on request without process

A number of editors have expressed their opposition to the proposed implementation for creating too many hurdles and a number of supporters have explicitly only supported just to have any process in place, however flawed. I thus propose that instead of implementing a flawed process and trying to fix it later, we KISS and just implement a simpler process now and think about a more difficult process if (and only if) this process does not work out:

Process for requesting

Administrators who wish to request this permission may make a new request at Wikipedia:Bureaucrats' noticeboard (WP:BN). Bureaucrats are authorized to grant the permission to any administrator asking for it without any further requirements. Administrators are encouraged to only request the permission if they plan to use it continuously and request one-time edits at WP:IANB instead. Administrators are expected to relinquish the permission if they no longer need it.

Removal of permissions

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 2 months or who have made no edits using the permission for at least 6 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 (e.g. at Wikipedia:Administrators' noticeboard).
4. Upon removal of administrator access, for any reason.
5. By request of the Arbitration Committee.

I think this addresses the concerns of those favoring a stricter process by imposing shorter limits on acceptable inactivity, thus reducing risks of accounts being inactive while having the right. After all, if you can get the right by just asking, you won't mind relinquishing it whenever you are inactive for a period of time. Thoughts? Regards SoWhy 17:48, 3 September 2018 (UTC)

Discuss Alternative / modified proposal

@SoWhy: I think the best place for one-time edits would be to use the edit request process on the associated talk-pages, they would be more likely to be seen by watchers of those pages. — xaosflux ^Talk 18:27, 3 September 2018 (UTC)

@Xaosflux: Yes but that requires that those pages are monitored. Not all those pages are watchlisted at all or by all IA permission holders. On the other hand, they probably all monitor the IANB, so requests there will likely be seen by more editors. Regards SoWhy 19:10, 3 September 2018 (UTC)

I missed this comment earlier, but I'm with Xaosflux on this. We shouldn't pull history away from the relevant talk pages, and folks should continue to use edit requests, as they do now. My intent when making the board was to help fuel a discussion above. To quote myself below, [t]he initial intent of IANB was to have 1. a place where IA nominations (and removals) could be discussed (like the edit filter) and 2. to discuss bigger-picture edits, perhaps involving coordination amongst editors. ~ Amory (u • t • c) 11:46, 4 September 2018 (UTC)

• Thanks for starting this, SoWhy. I at least think there is some support for a “hold” period between the request and the earliest it can be granted to allow for potential objections, similar to how we handle resysop requests or requests for edit filter helper and edit filter manager for non-admins. It was originally 48 hours when we were workshopping this proposal, but I guess we thought that was too short and made it a week; now that we’ve opened this up to the whole project, I think it’s clear we shouldn’t have thought that. Mz7 (talk) 18:45, 3 September 2018 (UTC)
  • Imho, if there is a reason not to trust an admin with the IA permission, they shouldn't be an admin at all, IA or not. What reason could there be to trust someone with deleting basically all pages except a few, blocking everyone and protecting everything but not with editing JS / CSS pages if they expressed a wish to do so? Regards SoWhy 19:06, 3 September 2018 (UTC)
    • I think that’s a fair point. I support a hold mainly as a compromise between those who want a full vetting process and handing it out on request. TonyBallioni (talk) 19:08, 3 September 2018 (UTC)
    • I don’t think I agree with that. This permission gives the ability to run code on millions of computers. Many well-respected technical editors who have opined here have placed the potential for misuse even higher than checkuser/oversight. With that in mind, I just think it isn’t a bad idea to vet for technical competence and demonstrated need. Mz7 (talk) 19:13, 3 September 2018 (UTC)
      • It does but again, why trust an admin with the ability to wipe out thousands of pages or block thousands of users if they feel like it and not edit the JS / CSS? I don't expect many admins will request this permission anyway, just like only a few admins use the edit filter right. Regards SoWhy 19:18, 3 September 2018 (UTC)
        • Well, I think deletion/block rampage is less likely to be as disruptive as the ability to install malware on thousands of computers and potentially violate the privacy of other users. I’m not sure I agree with your equivalence. Mz7 (talk) 19:21, 3 September 2018 (UTC)
        • To be clear, I think a 48-hour hold is a good compromise, as Tony suggests. Mz7 (talk) 19:38, 3 September 2018 (UTC)
          • In regards to what Mz7 stated, this happened already before. Miraheze is an ad-free wikifarm that hosts wikis and is run by members of this community. They had to deal with a security incident where one of the wikis had malicious JS installed in the common.js file that resulted in the users' own computers transmitting, Username, IP, UA, and CSRF tokens to a third party party server. So while admins here are held to an extremely high standard, it's very possible for one of us to do that, if we had malicious intent, or if one of us is not technically inclined, and proxied an edit on behalf of someone that said it does X, but it actually did Z, the damage is then done, and likely irreversible. I'm saying this as an argument in regards of why security is absolute paramount, but I'm not commenting on whether all admins should have been stripped of their rights after such long-standing. I'm still very neutral on this.—CYBERPOWER (Chat) 20:10, 3 September 2018 (UTC)
• This proposal sounds the most pragmatic one till now. There's no need for a holding period, given that being an admin would be a pre-requisite. A holding period would go against the basic premise of handing over the right on request. Lourdes 18:54, 3 September 2018 (UTC)
• I’d support with a 48 hour hold in case there are reasonable objections, but would support this over the proposal above. TonyBallioni (talk) 19:06, 3 September 2018 (UTC)

The only reason I can think of is if the admin is currently under discussion at AN/ARBCOM with the threat of desysopping. But even then, a 24-hour-period like for resysops should suffice. Regards SoWhy 19:18, 3 September 2018 (UTC)

• Tracking 2mo/6mo activities may be a bit awkward. — xaosflux ^Talk 19:11, 3 September 2018 (UTC)

I'm no expert but I'm pretty sure a bot could do that, no? Regards SoWhy 19:18, 3 September 2018 (UTC)

• A 48 hour hold is a minimum here, due to the security reasons that added interface admins in the first place. Otherwise, a malicious actor could simply compromise the admin account, ask for and receive Iadmin, and the security flaw was never actually patched on enwiki. I think we also want some level of vetting for technical competence on top of a hold, but that's a separate discussion. Tazerdadog (talk) 20:19, 3 September 2018 (UTC)
• For those that think this will end in every admin just having the permission anyways, and there being no reduction in users able to edit JS - let's look at the abusefilter permission, which admins can self-grant, is complicated, and in the wrong hands can easily be very dangerous. There are 159 abusefilter users, 148 of which are admins. That's approximately 12% of admins. SQL^{Query me!} 20:28, 3 September 2018 (UTC)
  • Another busy project, commons handles it this way as well, FWIW: Commons:Commons:Interface_administrators "Every Administrator who can make plausible a need to edit the interface will be granted temporary or permanent Interface administrators right on request at the Bureaucrats' noticeboard per bureaucrats discretion." SQL^{Query me!} 20:42, 3 September 2018 (UTC)
  • On the other hand, 148 is 26% of sysops with at least one logged admin action in the past three months, and 38% of those who made at least five logged admin actions. That jumps to 35% and 52%, respectively, for one month. ~ Amory (u • t • c) 20:49, 3 September 2018 (UTC)
    • On a third hand, if we're going to try to use that as an honest statistic we should probably remove inactive AF users as well. SQL^{Query me!} 20:54, 3 September 2018 (UTC)
• Strong support (with a 48 hour hold). ~ Rob₁₃^Talk 20:59, 3 September 2018 (UTC)
• I agree this is a simpler process than the one above, and I would prefer to raise the inactivity threshold of not editing CSS/JS pages to 1-2 years. I think many of the admins who eventually get IA permissions are maintainers of individual tools like WikiLove or Geonotices. If things go well, they might not need to edit any CSS/JS page for months on end, but it will be nice for them to keep the ability to edit the tools so they can respond to any new requirements quickly (e.g. upstream MediaWiki changes breaking their tools) without waiting another few days for bureaucrats to grant them the bit back first. Deryck C. 09:33, 4 September 2018 (UTC)
  • The proposed removal only works without a holding period of course. Timely removal of access for security reasons makes sense but only if the right can be regranted without delay. I'll whip up a modified alternative below. Regards SoWhy 09:47, 4 September 2018 (UTC)
• Also I agree with this much simpler situation. It should be fairly easy to check when was the last time CSS/JS pages were edited by the person, and if that is 'a long long time ago' (1 year or more?) then a discussion with the editor can be started to see whether removal is better (but without restrictions towards getting it back later) (and if that actually is warranted based on the number of iadmins we have - I still think we need a healthy base of them to repair broken stuff). --Dirk Beetstra ^{T C} 09:41, 4 September 2018 (UTC)
  • If the additional bit can be removed and regranted easily, why wait a year? From a security perspective, the concept should be more like typing su - on a *NIX machine, i.e. only using elevated access if necessary and relinquishing it when you don't need it. If one knows they can "type su -" whenever they need it, they have no reason to keep the permission while not using it, thus decreasing the security risks. Regards SoWhy 11:54, 4 September 2018 (UTC)

    • @SoWhy: I'd be fine with interfaceadmin's having "removeself" access from the group so they can remove their own access whenever they want. The tech team should have no pushback on that, but we need a community approval to submit this as a configuration request. — xaosflux ^Talk 14:40, 4 September 2018 (UTC)

      • • @Xaosflux: Makes sense but that's something we can discuss once we have established how to grant it. My proposal does not specify how the access is removed and thus is compatible with "removeself". Regards SoWhy 14:49, 4 September 2018 (UTC)
    • I'm fine with self removal and/or a reminder after 2 months as well. Should just not be too short. In the end it will also depend on how many inactive bits will be lying around. --Dirk Beetstra ^{T C} 16:20, 4 September 2018 (UTC)

Alternative proposal with waiting period

Because of popular demand, here's a proposal that tries to address the comments above while still keeping it simple:

Process for requesting

Administrators who wish to request this permission may make a new request at Wikipedia:Bureaucrats' noticeboard (WP:BN). Bureaucrats are authorized to grant the permission to any administrator asking for it without any further requirements after an 48-hour waiting period (similar to the process of re-granting administrator status after inactivity) for first-time requesters; administrators whose permission was removed within the last two years for inactivity or voluntarily can be re-granted the permission without a waiting period. Administrators are encouraged to only request the permission if they plan to use it continuously and request one-time edits at WP:IANB using the process for requested edits outlined on this page instead. Administrators are expected to relinquish the permission if they no longer need it.

Removal of permissions

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 2 months or who have made no edits using the permission for at least 6 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 (e.g. at Wikipedia:Administrators' noticeboard).
4. Upon removal of administrator access, for any reason.
5. By request of the Arbitration Committee.

This adds a waiting period for first-time requesters while still making it simple to gain and lose the permission for already experienced admins without having to wait 48 hours each time, thus promoting a voluntary removal. Regards SoWhy 09:56, 4 September 2018 (UTC)

Collapsing large and over-length comment ~Oshwah~(talk) (contribs) 15:20, 4 September 2018 (UTC)

That "process" is so full of holes any "letter of the law" administrator could use to go from having been "de-sysoped" years ago right back to having the "mop" plus a "right" that what, all of a dozen or so "interface adminstrators" seem to have ever used period but now seems to be quite the "essential" right to "regain" like suddenly being told they're "losing" something they may not have known they "had" or even known how to use that the ways an "existing administrator" could "wiki-lawyer" his or her way into "promoting" themselves right to "interface editor" simply by going to the Arbitration Committee and "requesting" that "access" (which can't really BE misused while actual EDITS USING IT are an entirely different story - one of those holes in your "process" I mentioned so nobody can demand an "example" of a hole in the process begging to be exploited) without the "casual observer" of RFAs having any idea an "existing administrator" with whom they may have differences is suddenly "interface administrator" and with a new "tool" that seems to make possible editing user and talk pages so their "owners" could be unable to find or access them. Or even EDIT them. I'm completely ignorant on the whole .css and .js things and couldn't code my way into my own home security system if I had one, but a "right" or "access" that has been used so rarely by so few editors and so many of them only having used it a few times and long ago must be really something special all of a sudden since so many "existing administrators" are just proposing and discussion and debating up a STORM to make sure "existing administrators" get it back even if they've never used it before. And oddly enough the list of editors who have used it and the list of very interesting and involved "existing administrators" who are suddenly very concerned with regaining "access" and "protecting" it hardly overlap at all. I've even seen "existing administrators" requesting the "temporary" rights and....justifying would be the right word, I guess...their "access" and its "return" so they can keep doing what must be important work that requires it but they don't show up on the list of interface editors who have actually used it. Makes me wonder just how qualified "sysops" who seem to be pretty unfamiliar with that "access" and their own use or non-use of that access they're so concerned about really are operate a "system" nobody ever seems to mention as their "priority" during an RFA. Not only does that access have to be something only a tiny fraction of a percent of all admins ever have "needed" to use, it has to be the most "unused" access and "tool" in history still considered "necessary" since that relative handful of editors have only edited with it maybe 400 times in its whole history and HALF of those are "recent" and were performed by two editors with one of those two responsible for 90% of that half. If I'm not mistaken there is already a process for getting "temporary" interface administrator privileges and I believe somewhere around 5-10 "temporary" interface administrators already have had their "access" returned and I think those 5-10 individuals are the only "existing administrators" and ACTIVE EXISTING ADMINISTRATORS on the "all-time user list". Its hard to imagine something so "useless" is really something that "existing administrators" who have never used it should be spending so much time "proposing" and "discussing" alternative ways to get "temporary" access the only experienced interface administrators and a majority of the interface administrators to have ever used it have "temporary" access to. And what "inactive administrators" who were "de-sysoped" years ago could want or need with that "bit" or "mop" so badly it would drive them to decided to pick up their original "bit" or "mop" again and start doing the work they were "elected" to do after an extended "Wikibreak" from "sysoping" is something apparently only you know. So could you provide an example of a situation where that would be the case and maybe toss out a quick "plain English" summary of what that "access" gives "interface administrators" the ability to do so non-coder Java Script "virgins" like me at least know what kind of "power" administrators who have never used it will suddenly be wielding for the first time ever? I say "wielding" because your "process" also mentions that they're "expected to relinquish" that "access" when its no longer "needed". More "holes" but someone reading that in GOOD FAITH and TRUSTING an "existing administrator" to not be "wikilawyering" a bunch of "loopholes" into a process might assume that in an "emergency" for some important and heretofore unnecessary "sysoping" an "existing administrator" would NEED to go straight to Arbcom with their sudden request for "temporary" access and of course not being "first-time requesters" and "trusted" existing administrators "exempt" from a "48-hour waiting period" for a "temporary" access. And some further expansion on the "process" for "relinquishing" the access as they would be "expected to" might be nice. And on the subject of "first-time requesters" and the "48-hour waiting period" before THEIR "temporary" access could be "approved", just what is a "first-time requester" in that process and why would someone who has never "requested" that "bit" or "mop" suddenly need it but yet could wait 48 hours or MORE to get it? Its just kind of strange that an "emergency" for a "first-time requester" could "wait" while an "existing administrator" even if "inactive" for YEARS would just need to "request" access and they could be an "interface editor" apparently IMMEDIATELY and with a "consensus of one" since you don't really mention any specifics about "Arbcom" and just what "authority" to "approve" or "grant" that access your "proposal" empowers them with would actually require FROM THEM in the way of "discussion" or "consensus" and how many "Arbom members" even need to have that access "requested" from them. Seems like an "existing editor" could sure end up with a fast-track to a whole new "position" and that ARBCOM MEMBERS THEMSELVES could "approve" or "grant" THEMSELVES that "access" and "re-sysop" themselves even if THEY "lost" or were "denied" the "bit" or "mop" in the past and regardless of when, why, how many times or for what reasons. And all it takes is a "first-time request" to go from "48-hour wait" to "front of the line". Hmm. Can you elaborate a little on what kind of "first-time request" is required for that VIP front of the line treatment? And are you talking about "administrators" ONLY being permitted to request that "temporary" access and is their "administrator" status - of whatever specific "type" such as "inactive" or "existing", etc - the real "protection" of that "access" someone might think is the whole point of your "process" because "administrators" already had it and therefore should have it again? I'm assuming their "first-time request" for that "access" that was "bundled" in with the "bit" or "mop" whether they knew it or not so they had it previously and are therefore "qualified" to have it "restored" - temporarily and only as "needed" of course - would be considered their "RFA" and hopefully a SUCCESSFUL "first-time request" that was SUCCESSFUL is REQUIRED so a "non-existent administrator" who was maybe denied or "lost" the "bit"or "mop" can't game the system and jump right back to "interface editor" maybe even after having been "desysoped" by the community. Sure seems like someone so concerned about protecting that "access" would be much more specific in a "proposal" and would call it more of a "draft" and would have an RFC on it somewhere rather than throwing it out there as a "cut and paste" policy all packaged up and ready to go and without any "consensus" having ever been reached on whether or not that "access" which was "removed" is SUPPOSED to be "restored" to every "administrator" who wants it but has never used it. From what VERY little I know about that "bit" or "mop" and judging by the removal of that "access" from all but "interface editors" who have USED IT PREVIOUSLY, the primary concern and reason FOR restricting "access" TO "interface editors" who have USED IT was that it could be used or abused by "sysops" who are clearly WP:NOTHERE if they spend their valuable "free time" editing scripts or codes or whatever on pretty much anybody's user and/or talk pages. Certainly plenty of "existing administrators" have very strong feelings about the "unwelcome" and "uninvited" editing of their OWN talk and user pages period so what would they say if some "existing administrator" who may have been an "inactive administrator" maybe "desysoped" YEARS AGO and "missing" for years suddenly returned from the dead and "gamed the system" to get that "bit" or "mop" and started editing scripts or code or whatever on THEIR user or talk page? And exactly WHAT could THEY do about it except "edit war"? I think there needs to be a lot more discussion about what exactly is being "accessed" and why its suddenly so important to a relative handful of "existing administrators" who have never used that access that they not only have it "restored" to them but be so involved in "proposing" just how, when, where and why and to whom that "access" IS "restored". Presumably as "sysops" and trustworthy and capable and qualified "sysops" it never would have been "restricted" if whomever did the "restricting" considered every "administrator" worthy of the "access" simply because he or she hasn't used or abused it previously. I'm also pretty sure that "proposals" for how to "restore" that access were being drafted, posted and debated and "existing administrators" were more or less "demanding" it be restored before they even knew what they had "lost". And I wouldn't call any "existing administrator" who claims they need it "restored" to continue to do whatever work they were doing prior to "losing" it "worthy" of access they either have used but have somehow don't show up on the "all-time user list" OR mistaking for some other "bit" or "mop" they have used. Or think they've used. I'm kind of reminded of kids who will completely ignore a toy they received as a gift and don't like and don't want and would just as soon throw away as look at and be reminded asking for a specific gift and getting it are two different things suddenly falling in love with that gift if a sibling or other relative starts playing with it or a parent threatens to or actually does give it away to someone who will appreciate it. Its also amazing how often the same "existing administrators" who "strongly oppose" any change to Wikipedia that gives "editors" more or easier access to simple "tools" that "existing administrators" seem to "grant" to "registered users" and that are otherwise in the "administrator toolbox" and without "consensus" that a mere "editor" should be "granted" ADMINISTRATOR TOOLS, or who ban/block/restrict "users" and "editors" who somehow offend them with no "consensus" (unless its that "consensus of one" thing again) and "indefinitely" and even REVOKE THE USER'S OR EDITOR'S TALK PAGE ACCESS RENDERING HE OR SHE UNABLE TO "APPEAL" THEIR ARBITRARY ACTIONS THAT HAVE NOTHING TO DO WITH "OPERATING" ANY "SYSTEM" OR ANY OF THEIR OTHER "BITS" OR "MOPS" AND WHEN THAT USER OR EDITOR WOULDN'T EVEN BE ON THEIR "RADAR" IF THEY DIDN'T EDIT THINGS LIKE "ABUSE FILTERS" AND IN GENERAL "VANDALIZE" WIKIPEDIA AS THEY PLAY "CYBER COP" WHICH ISN'T "MOPPING" OR "PULLING A CART" AT ALL. They think its their "duty" to block/ban/delete/attack/belittle/abuse anybody and everybody who doesn't "comply" with their "requirements" for what is "acceptable" existence on and inclusion in "Wikipedia". But when a "right" or "access" or "tool" they probably didn't even know existed and they had suddenly is "threatened" and they find out about the "threat" because "administrator" and/or "right" and/or "access" and/or "tools" and/or "edit" trip some "filter" which causes some "bot" to immediately notify them of where, when, how, why and who somebody is DARING to reduce/restrict/remove THEIR "access" to ANYTHING and EVERYTHING they can possibly "edit" on Wikipedia, the "rescue party" of "existing administrators" who have "protect all administrator power at all costs" as one of their "areas of focus" on Wikipedia, well....I think your "process" and all those "proposals" and how suddenly important "debate" and "consensus" and "politeness" and "good faith" become to "existing administrators" who otherwise seem to be here only to "build an encyclopedia" by making sure THEIR "contributions" stay and everything that isn't up to their "standards" - including people just trying to contribute - end up "restricted". — Preceding unsigned comment added by 68.234.100.169 (talk) 15:16, 4 September 2018 (UTC)

Discuss alternative proposal with waiting period

• Can you reword request one-time edits at WP:IANB? I made the board following some discussion above, mostly as a way to see what it would look like, but also with the idea that something that exists (e.g., BN) would always be chosen over something that didn't yet exist. One-off edits should still be made at the relevant talkpage, as currently happens now, and folks should use an edit request template, as currently happens now. The initial intent of IANB was to have 1. a place where IA nominations (and removals) could be discussed (like the edit filter) and 2. to discuss bigger-picture edits, perhaps involving coordination amongst editors. We shouldn't pull history away from the talk page of interface pages, and the way things are going here, I think it likely the IANB need not exist. ~ Amory (u • t • c) 11:43, 4 September 2018 (UTC)
  • As I pointed out above, a noticeboard (whichever name it uses) is probably better in terms of visibility than talk pages, considering that now all people available to make a certain edit have all those pages watchlisted. An alternative using some form of {{edit protected}} for these pages feeding a category that can be monitored by people with IA access would be a viable alternative of course. I'll amend the proposal but the specifics of which template to use should not matter for the proposal. Ideally, there should be an explanation page that informs editors of how to make such requests. Regards SoWhy 11:58, 4 September 2018 (UTC)
• Support per my comments above and my thanks to SoWhy for taking initiative here. TonyBallioni (talk) 13:43, 4 September 2018 (UTC)
• Support as an acceptable compromise. I would also like to thank SoWhy for starting this. I still prefer requiring at least a statement of demonstrable need, but this is an acceptable starting point for a process that I hope addresses the concerns that we would be making another RfA. Mz7 (talk) 19:24, 4 September 2018 (UTC)
• Strong oppose 1) Doesn't establish a proof of need process, but rather one which is time-based. 2) Doesn't guarantee actual usage of rights and gives a 6-month interim period. My suggestions include: 1) Require a proof of need and present technical requirements. 2) Have stricter requirements for removal, such as two months of no logged action and not using the IA right as well. 4) Finally, implement the proof of need only on first-time requesters with later ones being subjected to a simple 24-hour wait or similar. I think this is too sensitive a right to grant to anyone (we do not seem to exactly get that fact), and needs to be treated as such, sort of like how EFM is held only by a handful, out of which few are active and mere fewer are non-admins. --QEDK (後 ☕ 桜) 19:50, 4 September 2018 (UTC)
  • If I wanted to, I could give myself EFM right now. I have no desire or need for it, so I don’t, but appealing to EFM as saying it is better than this proposal ignores the fact that this proposal is stricter than the EFM process for admins. TonyBallioni (talk) 20:04, 4 September 2018 (UTC)
    • My point was simply, it's more sensitive then EFM, so we should regulate it as such. Whether the process is of relatively more or less strict that how EFM is managed is of no relevance to what I said. You should have read into more of the point where I stated about how few of them are active and closely guarded EFM is among admins. With thanks. --QEDK (後 ☕ 桜) 20:10, 4 September 2018 (UTC)
      • I’m sorry, and I’m not trying to be rude, but I’m having a lot of trouble parsing your syntax in both posts. What the first post seems to say is that this is a security risk, so it should be regulated like EFM is (which is not at all for admins). I’m not sure what you are trying to say in your reply after the first sentence. TonyBallioni (talk) 21:22, 4 September 2018 (UTC)
        • @QEDK: Gadget scripts ought to be stable, but gadget maintainers need to be able to respond quickly if an upstream change breaks their gadget. If we revoke IA after only two months of not editing interface scripts, it will prevent IAs from responding quickly to requests, or worse, create a perverse incentive for IAs to keep changing their gadgets in order to keep their IA rights. Deryck C. 09:32, 5 September 2018 (UTC)
          • If someone is not making such changes for a period of 2 months, there is absolutely no need of holding such a right till that point either. If upstream changes break a gadget and you aren't an active maintainer, you probably should hand it off to someone more active. @Tony, I didn't mean to say as regulated as well, I'm simply clarify again, that if self-granted, most of them stay as-is over a period, without the right actually coming of use, and non-admins getting the right are even more regulated so their contribution is absolutely miniscule. --QEDK (後 ☕ 桜) 09:46, 5 September 2018 (UTC)
            • @QEDK: I'm afraid you misunderstood my point: many gadgets do not require any edits to their scripts for many months at a time. If we remove IA after two months of not editing sitewide script pages, most gadgets will have IA permission stripped from all their maintainers and therefore nobody to respond to an upstream change when one happens. Deryck C. 10:57, 5 September 2018 (UTC)
• Support seems like an acceptable compromise. ^Semi_Hypercube ✎ 20:48, 4 September 2018 (UTC)
• Support, this looks good to me. The interface admin right was created so that admins who didn't need this right but who's accounts became compromised would be less of a risk. As far as I can tell, it was never intended to be a separate, higher, vetting process (RFA 2.0). Admins are entrusted by the community to use these tools responsibly, if they have need, there is no reason why the 'crats can't just grant it on request. — Insertcleverphrasehere ^{(or here)} 00:34, 5 September 2018 (UTC)
• Oppose, almost there. This proposal is actually a nice compromise, minus that it does not require a demonstrated need, for what is the most sensitive user right available. I'd like to see that in the print, however fine it may be. Interface admin is not for hat collecting. We need to see a good reason as to why they want to use it, and some evidence they'd know how to. I also would prefer 3 or 4-day waiting period. 48 hours would cover only a weekend, when many people are away from the wiki. A week long process (from the first RfC above) indeed is rather long -- that I agree with. — MusikAnimal ^talk 04:16, 5 September 2018 (UTC)
  • EFM does not require a demonstrated need as well and is also very sensitive. The reason IA was created was, from all that was written, to reduce security risks by limiting the pool of users who actually have it. But the underlying assumption of this proposal is that admins are already trusted users (and almost all of them had this right for years without problem) and thus can and should be relied upon not to request this right if they do not plan to use it (again similar to WP:EFM). Imho, if there really are admins who request this right solely for "hat collecting", they are not suitable to be admins, IA or not and should be dealt with based on this. Adding a "need" requirement also might make it seem like that admins cannot be inherently trusted to do that. As for waiting period, this proposal authorizes crats to grant the right after the period. It does not force them to. If there are any reasons to wait longer, we can rely on their judgment to just do so. Even on the weekends we can usually expect someone to say something within 48 hours if there are concerns (plus, admins can be resysoped after 24 hours and that is not problematic either). Regards SoWhy 07:22, 5 September 2018 (UTC)
    • EFM I don't think is a good example, as it pales in comparison to why you can do with interface admin. Powerful, yes, but a matter of security? No. Anyway, all I'm asking is to explicitly say you should have a "demonstrated need". Some vetting of technical competency may be appropriate, but this is less important. I just don't want to give the impression that this right is easily attainable upon request, and can be used for one-off purposes when it would take less time and effort to simply ask existing interface admins to do it for you. Again, I'm not talking about trust -- admins already proved that with their RfA (in general :) — MusikAnimal ^talk 16:41, 5 September 2018 (UTC)
• Oppose per MusikAnimal, will change to support if a requirement for demonstrated need is added. Enterprisey (talk!) 04:19, 5 September 2018 (UTC)
• Support There's no need for demonstration of need. As Tony points out, the basic philosophy here should be equivalent to the one while granting the EFM bit. Admins are expected to have the sense to apply only if they wish to contribute. If an admin applies to get this bit purely for show, then the 2 month/ 6 month delimiter is enough to ensure their redundant bit is removed. Lourdes 06:08, 5 September 2018 (UTC)
• Support. Better than all the previous proposals. Deryck C. 09:33, 5 September 2018 (UTC)
• I would prefer the waiting period to be a maximum of 24 hours, but this is a good compromise, so I Support this proposal. I am absolutely opposed to using any sort of process similar to RFA to grant this permission to admins. We should not be modeling anything after that fetid cesspit. I get why this was implemented, and on smaller projects with looser rules for granting +sysop, and less eyes - it makes a lot of sense. SQL^{Query me!} 12:12, 5 September 2018 (UTC)
• Comment This is basically the same as directly above. However, I don't understand why we need a waiting period. If I am technically capable, and I have not screwed up parts of the interface before (or someone else's css) then if there is need to edit, there is 'need' to edit now. If I have to wait for 2 days, I would suggest the edit and add a {{editprotect}} (the iadmin equivalent of that) and forget about the whole thing. If this involves a gadget I maintain, and due to unforeseen changes in the MediaWiki software the gadget needs a code-tweak, then waiting 2 days annoys the heck out of all of the editors that use the gadget. I can see the requirement for demonstrated need (within reason, again, an editprotect request is an answer to every instance of demonstrated need, unless there are at a certain moment no iadmins at all), but not the waiting time. --Dirk Beetstra ^{T C} 14:44, 5 September 2018 (UTC)
  • A waiting period is required to give administrators time to recognize that their accounts have been compromised before an attacker is able to be granted this userright. --Ahecht (TALK
    PAGE) 16:42, 5 September 2018 (UTC)
    • Waiting period is not needed, showingneed is. And as most editors who edit sitewide .cs/.css do that so occasional (onceevery month at most) that a fast expiry (order of days) is better for maintaining site security. Hence Oppose. --Dirk Beetstra ^{T C} 16:51, 6 September 2018 (UTC)
• Support. Nobody needs to volunteer their work here, and all that having additional permissions does is make it easier to help. Also, SQL says very wise things: we should at all costs avoid creating any process that could become similar to RFA. —Kusma (t·c) 19:58, 5 September 2018 (UTC)
• Support, secure enough without making the whole thing a bunch of unnecessary bunch of hoops to jump through. As Kusma says, we're asking people to volunteer their time here—let's not make it needlessly hard for them to actually do that! Seraphimblade ^{Talk to me} 04:27, 7 September 2018 (UTC)
• Oppose per MusikAnimal. A need for the user right has to be explicitly stated for assigning rights per principle of least privilege. —Gazoth (talk) 10:51, 7 September 2018 (UTC)
• Support, I think the 48 hours waiting period is a bit much but it's simple enough. I trust admins not to request the permission on a whim, and bureaucrats to expedite the process if there's an urgent need and no one to act. -- Luk ^talk 12:47, 7 September 2018 (UTC)
• Support. This is the most restrictive policy I'd be willing to accept. ~ Rob₁₃^Talk 13:33, 7 September 2018 (UTC)
• Oppose per MA, although rather than "demonstrated need" I'd say something like "demonstrated use and understanding." ~ Amory (u • t • c) 16:13, 7 September 2018 (UTC)
  • Just comment at the BN post if you don’t think someone has the need for it. There is a 48 hour hold for a reason. If we didn’t have it, I could see opposing for this reason making sense, but right now it seems like such language can’t gain consensus (see below) and that this proposal is the compromise that has the best chance of passing. TonyBallioni (talk) 19:34, 7 September 2018 (UTC)
  • What is the reason for the 48 hour hold? The proposed policy only says that Bureaucrats are authorized to grant the permission to any administrator asking for it after that hold, but does not give any guidance as to what should be disqualifying, it doesn't even reference there being a community discussion. It does reference the policy at Wikipedia:Administrators#Restoration of adminship, which is very clear (nearly to the point of being repetitive) about the instructions for Bureaucrats regarding community discussion and granting conditions, especially the negative conditions. This gives no such explanation; at the very least, I think the implicit should be made explicit. ~ Amory (u • t • c) 20:01, 7 September 2018 (UTC)
    • I think it is overall save enough to leave it to the judgement of the Bureaucrats. If THEY see an active editor acting regular, there is no need for the 48 hour. (if an editor is quietly waiting for his RfA to finish, then Bureacrats are not waiting for 48 hoursto seewhether maybe the account got hacked JUST before theend of the RfA ...). If they are off andon, not editing as regular, then an out-of-the-blue request may warrant a return question or waiting. I mean that we can leave that to their discretion. --Dirk Beetstra ^{T C} 20:41, 7 September 2018 (UTC)
    • It is at their discretion, and I highly doubt if there is a consensus amongst users who are knowledgeable in this subject area that someone should not have the rights, they would grant (or more likely, the person would just self-withdraw.) TonyBallioni (talk) 23:33, 7 September 2018 (UTC)
• Oppose I am a new user and wasn't aware of this right before spotting this page on my watchlist but it sounds like a very dangerous ability to be giving out like sweets at Halloween. Wikipedia is listed as fifth most popular website with 495 million unique vistors a month, so it is a prime candidate for hack attacks. The ability to inject attack code into 495 million computers is not something to ever be taken lightly. As others on this page have said the right is only used a handful of times a year, I am shocked that such lax protocols are even being considered. To grant this right you are not only trusting the individual (and their ability to use the tools correctly) but also the strength of their password, firewall and virus protection among other security interface points. The threat is minimal with only a handful of users with the right at any one time but it grows exponentially as more users are added. This right should be locked down to as few people as possible. I'd propose adding a cap to the number of users that can hold this right at any one time. The cap will stop people requesting access as just a status symbol and strong rules on usage levels will constantly reduce numbers below the cap for someone new to request access when needed. From Hill To Shore (talk) 12:10, 8 September 2018 (UTC)
  • @From Hill To Shore: and what if the right would just expire after a couple of hours or days? --Dirk Beetstra ^{T C} 14:54, 8 September 2018 (UTC)
    • I suspect that a very short expiration would be difficult to administer. In my view it is the maximum number of people with the access right that is the issue, and the expiry is purely a mechanism to keep the numbers within the cap. Another way to look at it would be to only prune the access list when a new request would take you over the cap. The access list is reviewed and those who haven't used the right in a set time are removed. This would reduce administration as you only clean the list when you hit the cap (or an account loses its admin access), not at fixed points in time. From Hill To Shore (talk) 15:46, 8 September 2018 (UTC)
  • @From Hill To Shore: Hi (and Welcome!), when every administrator had the ability to edit these page until earlier this year, there were no incident that I can recall. While I agree with you that this may seem dangerous to let individuals edit the site without hard scrutiny, having protocols that are too strict will impede the ability to undo an erroneous or malicious edit quickly. If something bad happens, we will be able to review this process but I think we need to balance reducing the risk of something bad happening and keeping in mind that people here are volunteers, acting in good faith, that are not expected to be on call at any time. -- Luk ^talk 15:23, 8 September 2018 (UTC)
    • I believe that the number should be capped. However, if there is agreement with this principle, it would be for the community to set the level of the cap. Consensus would have to find a balance between having enough people available to make emergency edits and limiting the number of avenues for a hacker to get in. From Hill To Shore (talk) 15:46, 8 September 2018 (UTC)
      • @From Hill To Shore: bits can behanded out with expiry, no further action needed. Only if editors keep asking and asking longer periods are warranted. But the most 'need' that I haveseen until now is a couple of hours every 2 weeks. Others 'need' it one hour every 6 months. Advantage is that targetting the right account to hack is difficult, if you have the bit for a year, a hacker has a year to hack your account. --Dirk Beetstra ^{T C} 17:10, 8 September 2018 (UTC)

Alternative proposal, with 'indication of need'

;Process for requesting Administrators who wish to request this permission may make a new request at Wikipedia:Bureaucrats' noticeboard (WP:BN). Bureaucrats are authorized to grant the permission to any administrator who can, within reason, show need for the permission. Bureaucrats are encouraged to hand out the access for a limited time, sufficient to complete the intended tasks, and to only hand out long periods to administrators who have repeatedly shown need and use for the permission.

Removal of permissions

Permission should be removed by bureaucrats in the following circumstances:

1. Voluntary request by the interface administrator at the bureaucrats' noticeboard.
2. After misuse of the access by consensus (e.g. at Wikipedia:Administrators' noticeboard).
3. Upon removal of administrator access, for any reason.
4. By request of the Arbitration Committee.

And with 'limited time', I mean up to a week. (and with this, one could even hand this out for a day to a non-admin). --Dirk Beetstra ^{T C} 15:01, 5 September 2018 (UTC)

Comment: I have ran this query. In the last 3 months only 40 .js/.css pages in the MediaWiki namespace were edited. Spot check on some of them for edits in that period: vector.css got 1 edit, timeless.css got 2 edits in 1 day, RefToolbarLegacy.js 2 edits 1 month apart. That hardly seems to warrant anyone getting 'permanent' access to iadmin. For most actions a couple of hours is more than enough. If security is a big deal, no-one should have access, and only request short-term access when they need it (and there it should be given fast).

• Support as proposer. An added benefit of an ever-moving pool of iadmins would be that it limits the time a hacker would have to get access to the account. --Dirk Beetstra ^{T C} 15:01, 5 September 2018 (UTC)
• Oppose there needs to be a waiting period to ensure that the requesting account hasn't been compromised. Since you have no limit on minimum recent activity, this period needs to be quite long (some less active admins could easily go a week without checking Wikipedia). Having a 1-week waiting period for a permission that is only granted for a week is absurd. --Ahecht (TALK
  PAGE) 16:40, 5 September 2018 (UTC)

  Sure. You hack a reasonably unused admin account. Do some regular editing, request permission, wait two days with some regular editing and get permission. Or do you expect a hacker to compromise an account of an admin and run the risk to be exposed by the real owner? A waiting period does not accomplish a lot. --Dirk Beetstra ^{T C} 18:18, 5 September 2018 (UTC)

  If you want to ensure an account is unlikely hacked, then do a CU before assigning. --Dirk Beetstra ^{T C} 18:20, 5 September 2018 (UTC)

• Oppose Complicated and broad; one can't rely on the personal judgement of individual bureaucrats for such an assessment. Lourdes 07:41, 6 September 2018 (UTC)
  • @Lourdes: it is intentionally broad, and there is not much to judge. The request could be 'I want to tweak something in this and this js, I need about 2-3 days'. And it is easy to check whether the editor kept to their request during that time or afterwards. For years nothing broke with every admin having access, and now the world is falling if someone asks access for 2-3 days for a specific need in good faith? --Dirk Beetstra ^{T C} 08:08, 6 September 2018 (UTC)
• Support. Slightly less cautious and therefore less restrictive than the proposal above. On balance, I am happy to have either of them become policy. Deryck C. 09:35, 6 September 2018 (UTC)
• Oppose I prefer the option directly above. SQL^{Query me!} 13:09, 7 September 2018 (UTC)
• Oppose prefer above for simplicity. People are free to raise issues of need during the holding period BN. TonyBallioni (talk) 13:16, 7 September 2018 (UTC)
• Oppose as overly bureaucratic. Can we really not trust admins to identify when they need this tool? ~ Rob₁₃^Talk 13:34, 7 September 2018 (UTC)

  No. Enterprisey (talk!) 15:42, 7 September 2018 (UTC) - Struck, and apologies to Beetstra for casting aspersions. Enterprisey (talk!) 18:48, 7 September 2018 (UTC)

  @BU Rob13 and Enterprisey: I'm not sure whether Enterprisey is being sarcastic here, but Beestra's case did not demonstrate anything about trusting admins to self-identify need, but rather a disagreement over the level of caution the granting of this right should entail. Beestra has demonstrated that IA will be useful for what he's doing, but was told to go the inconvenient way round because some members of the community want to avoid giving out IA at all costs. We have a full spectrum of opinions in this page ranging from every admin should be able to get it, to only admins with a recurring problem that doesn't have an alternative solution can hold it temporarily. Deryck C. 18:04, 7 September 2018 (UTC)

  A trusted user needing it to implement their bot sounds like demonstrated need to me. Our bot policy actually explicitly prohibits doing it the way the community has apparently told him to. ~ Rob₁₃^Talk 18:09, 7 September 2018 (UTC)

  @BU Rob13: indeed, it baffles me that users who use this 2-3 times in a year have 'a demonstrated need', whereas I, with this causing me massive inconvenience (and many admins with me to follow), do not. This whole situation is clearly about status and trust, not 'need'. I doubt that any ofthe now granted iabits have ANY continued need, with the frequency that.css and .js is being edited in mainspace (and we should NEVER edit s.o. elses .js or.css, that needs to be done through a sandbox so a user always has control over their own .js/.css so they are aware of the risks there). Call my recent edits a massive WP:POINT violation on my side, but people should look at themselves first then. Calling causing inconvenience to a, so it is said, trusted editor, is a WP:POINT violation in itself. --Dirk Beetstra ^{T C} 18:28, 7 September 2018 (UTC)

  @Beetstra: wasn't the primary emphasis for your ask explicitly that you wanted to edit "s.o. elses .js or.css"? This is not meant to evaluate the validity of your request, fwiw I think it seemed like a reasonable request. — xaosflux ^Talk 19:24, 7 September 2018 (UTC)

  @Xaosflux: touché, though most are really my socks (except one, which technically is not). --Dirk Beetstra ^{T C} 20:15, 7 September 2018 (UTC) (p.s. with less than 20 edits to side-wide css/js over the last year, do you need permanent access to this bit?). --Dirk Beetstra ^{T C} 20:22, 7 September 2018 (UTC)

  How did the many non-sysop users deal with such pages in their bot account's userspace? I would have thought the logging in/logging out game to be par for the course. ~ Amory (u • t • c) 20:04, 7 September 2018 (UTC)

  @Amorymeltzer: First, I am one of the few with on-wiki config files (allowing a lot of control to other editors). I think that only other addmin bot operators have this. For a non-admin bot-operator this level of control on-wiki is near impossible (except if you downgrade your trust to a levelthat you can attain, e.g. template-editors or confirmed users). Otherwise, you can only do it through off-wiki settings, hidden to everyone. Note that I was going to implement either regular sysop-protected files (notsure if json or regular pages) for my bots. I wanted to pull my pages out of the system where they are difficult to access for any admin at the moment, but for now it is too much work for me to get it done (it requires several actions on multiple wikis). --Dirk Beetstra ^{T C} 20:15, 7 September 2018 (UTC)

  Yeah, bots aren't usually implemented this way. And the bot policy explicitly forbids non-bot edits from the bot account. Actually, I'm going to be slightly POINTy myself and warn you as a BAG member not to edit from your bot account again except for an approved bot task, Beetstra. Please do take this in the spirit it's intended, which is mostly so you can point to the warning you got from a BAG member not to engage in bot policy violations in your next request for the user right. ~ Rob₁₃^Talk 22:34, 7 September 2018 (UTC)

  @BU Rob13: and @Beetstra: to be clear, see Wikipedia:BOTUSERSPACE, where bots editing their own pages are explicitly allowed - this is also getting QUITE off topic, if you seriously want to discuss this bot's operations and issue BAG "warnings" for policy violations, please take it up at WP:BOTN. — xaosflux ^Talk 01:55, 8 September 2018 (UTC)

  @BU Rob13: sorry, but just what we needed here. Overly bureaucratic. I would just throw WP:IAR back at you, as I see (saw) giving back control over the bots back to admins as an improvement for the encyclopedia (but actually, the bots work perfectly fine as they are ...).

  (@all) how about the security risk of having (elite?) editors who edit the interface once every 2-3 weeks (if not several months) .. those accounts spend most of their time staring in the headlights of an incoming hacker (it seems that we agree that editing .js/.css in other editors userspace is not needed ...). --Dirk Beetstra ^{T C} 05:07, 8 September 2018 (UTC)

@Xaosflux: This is neither a test edit nor a bot process, so that section does not apply. Only those two types of edits are allowed by bot accounts in their own userspace. @Beetstra: To be very clear, my comment was meant for you to use to demonstrate "need" in a future request for IA. In a very real sense, what you were told to do when you applied for IA above is a policy violation, which the editors in that discussion did not understand. That is sufficient to get the right. ~ Rob₁₃^Talk 11:44, 8 September 2018 (UTC)

@BU Rob13: if you truly think the spirit of Wikipedia:Bot_policy#Valid_operations_without_approval prohibits using a bot flagged account to manually edit its own configuration page hosted in its own userspace, to make a Small change, for example to fix problems or improve the operation of a particular task as in changing from User:Bot/config1.css to User:Bot/config1.json let's follow this up at WP:BOTN or WT:BOTBOL. This is certainly the wrong venue for this discussion. — xaosflux ^Talk 16:07, 8 September 2018 (UTC)

@BU Rob13: We should not need to 'demonstrate need', use is enough (I should reword my proposal). That is the problem. The elitarian 'do it in a different way' by editors who themselves have hardly any reason to use more than once every two weeks.

@Xaosflux: I still think that that type of editing falls under IAR. I can hardly see it as controversial to improve Wikipedia in this way, and would call enforcing that as policy overly bureaucratic. Seems to go around here, bureaucracy. --Dirk Beetstra ^{T C} 17:01, 8 September 2018 (UTC)

Starting another one later, and workshopping

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.

---

There are quite a few proposals on this page, and none look like they have very strong consensus. We should try to workshop a granting process (or a bunch of processes) that could then each be options in a well-advertised RfC later on (in a week or two). As a general note, there seems to be no community appetite for any process that has a lengthy discussion with bolded !votes, or for one with participation restricted (e.g. to only admins). Anyone can suggest more options in this thread, or suggest changes to existing ones. I also appreciate everyone's patience on this page so far during the policy-writing process. Pinging several people who've started proposals on this page: Ajraddatz, xaosflux, WJBscribe, Mz7, Deryck Chan, Cyberpower678, SoWhy, and Beetstra. Enterprisey (talk!) 03:21, 7 September 2018 (UTC)

• I'll start it off with one proposed option: SoWhy's 4 Sept proposal, with the "demonstrated need" clause from Dirk Beetstra's 5 Sept proposal. Enterprisey (talk!) 03:21, 7 September 2018 (UTC)
  • We probably shouldn't try to shut down discussion just yet while SoWhy's proposal appears to be gaining traction. I understand that it isn't your preferred result, but we should allow the community an opportunity to comment. SQL^{Query me!} 13:14, 7 September 2018 (UTC)

    Yes, I agree. My goal isn't to preempt the existing discussions, and since none has obvious, near-unanimous support, I figured we could try to work out a proposal that would get that. Enterprisey (talk!) 16:28, 7 September 2018 (UTC)

• I think it might be helpful if, as I mentioned above, we agreed on what risks should be mitigated and their relative priority. For example, if reducing the attack surface is paramount, then time-limited grants of the interface admin privilege may be the best way to go. isaacl (talk) 04:37, 7 September 2018 (UTC)
• Oppose and if this is adopted I support BU Rob13's previous position at BN that this should be handed out on request until there is consensus otherwise. The fact that en.wiki has not been able to pass something on this yet is ridiculous. Any option is a a decrease in the attack surface, and we need to stop letting the perfect be the enemy of the good. TonyBallioni (talk) 13:21, 7 September 2018 (UTC)

  What are you opposing? There's no proposal in the first post. Enterprisey (talk!) 15:39, 7 September 2018 (UTC)

  The attempt to shut down a proposal that is gaining consensus because technical contributors don’t like it, and I don’t think we are going to be able to reach something with unanimous support: the people who already have this right/who are very involved with the technical side of the project appear to want a higher standard than the community as a whole. Finding something that can get a rough consensus is the goal, and we look to be heading there. TonyBallioni (talk) 19:29, 7 September 2018 (UTC)

• IMO, being one who is closely, and silently, watching this discussion, the individual proposals may not have much traction, but everyone seems to be heading towards a common viewpoint. All the proposals put together are creating a "process", so I will continue to watch this RfC, and hopefully close it in favor of something in due time.—CYBERPOWER (Chat) 23:17, 7 September 2018 (UTC)
• I think SoWhy's second alternative proposal—the one with the 48-hour hold—has the highest likelihood of achieving consensus. We may not have to completely start over yet. Mz7 (talk) 23:27, 7 September 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.

Closed subproposals

Moving these "subproposals" outside of the main discussion area to reduce clutter. Mz7 (talk) 23:02, 7 September 2018 (UTC)
The following discussion has been closed. Please do not modify it.
Sub-proposal 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. There are currently open temporary requests for the permission further up. Given that this proposal on implementing a process to request this but falls in line with how the current requests are formatted, I propose extending the open requests an extra 4 days to make it a full week and make the requests for permanent access, this making those requests fall in line with the requirements laid out in this proposal. It would save time and bureaucracy. All new requests will use the proposed method of requesting.—CYBERPOWER (Chat) 18:02, 2 September 2018 (UTC) Straw poll on sub-proposal (open temp requests) Oppose per notes below, also this is presumptuous that the new proposal has already passed while it is being discussed. — xaosflux Talk 18:07, 2 September 2018 (UTC) Oppose agree with Xaos, can have a single discussion to make all of these permanent Galobtter (pingó mió) 18:50, 2 September 2018 (UTC) Yes, make all temps permanent once the process is approved. — JFG talk 21:36, 2 September 2018 (UTC) While I trust these users, at least two of them are really only interested in the role because of Geonotices. For those users I would not want to have permanent IAdmin (one, with self-described "occasional" use for extra-user JS/CSS, doesn't strike me as showing a need for the tool beyond the stopgap period; nor does the other show any need whatsoever). Of course, I don't have an issue with these users having the role temporarily extended until Geonotices is a JSON page rather than a Javascript page. I otherwise oppose this poll on the subproposal per Xaos. --Izno (talk) 19:20, 2 September 2018 (UTC) Yeah, there's that too. Once geonotice becomes JSON we'll have to reevaluate. Galobtter (pingó mió) 19:39, 2 September 2018 (UTC) Just to be clear also, I think we should close both of these subproposals (I said so below but I suspect my comment there may be missed) or make them separate discussion points (without being attached to the RFC) so that we can talk them over appropriately. --Izno (talk) 20:04, 2 September 2018 (UTC) Discuss I'd rather not delay those editors any longer, however: As soon as this process goes live I think adding a single request to covert all the exiting temporary holders to permanent (as opposed to ~9 individual requests) could be done. — xaosflux Talk 18:07, 2 September 2018 (UTC) Yeah, I had the thought about including some kind of grandfather clause in the proposal (those who already have the permission temporarily can keep it), but I forgot about it at the time I published the RfC. I agree it should be a fairly trivial matter to make the temporary permissions permanent. Mz7 (talk) 19:37, 2 September 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. Another sub-proposal 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. In addition to the methods outlined above, new RfA candidates may request having interface admin bundled in with the RfA by answering the 4th standard question, to be added, for all RfA candidates asking the candidate if they intend on contributing to interface pages on Wikipedia and would like the added right. Candidates answering yes, to the question are required to answer the same questions as laid out in the proposals above.—CYBERPOWER (Chat) 18:08, 2 September 2018 (UTC) Straw poll on sub-proposal (bundle perm in at RfA) I'd rather we didn't — one advantage of this change is that while the potential for a sysop to abuse their tools against a given user or page remains, the ability of any given sysop (or, more rightly, a sysop's account) to massively disrupt the entire project and make headlines is dramatically reduced. RfA has plenty of problems, but removing edit(site|user)(js|css) lowers the risks of advancing at RfA and can only help. No need to re-complicate RfA, especially since most sysops won't be making use of this. If rights were structured like this from the beginning, it'd be like introducing CU or OS into RfA. ~ Amory (u • t • c) 18:32, 2 September 2018 (UTC) I've been convinced by much of the discussion on this page that mixing this in with RFA directly is a Bad Idea. Using RFA as a proxy of social trust is one obvious way to meet one of the two criteria for having this tool (the other criterion is technical trust), but directly at RFA? No thank you. As for both of these subproposals, I would suggest closing them and letting the dust settle on the main proposal. We can work on other things later, including variants of these. --Izno (talk) 19:23, 2 September 2018 (UTC) Not advisable. Very few of the people expressing an opinion at RfA have the depth of expertise required to pass judgment on the constraints and risks of a highly sensitive technical permission. Instead, let's make it very easy for a freshly promoted admin to request the extra bit in a smaller forum. — JFG talk 21:39, 2 September 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.