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)

• Note, I will continue to process these until a policy is created, although there has been a lot of talk below, we have had 10 grants so far, and 1 withdrawn request - I expect this group will continue to grow, but it really is niche for how much contention there has been so far; if you are in need of this while the discussion is pending please feel free to request below. — xaosflux ^Talk 12:36, 10 September 2018 (UTC)
• I have grown a bit frustrated with the recent change. I would request that the temporary status not be an arbitrary 60 days, when we would just have to ask for it again, but until such time as regular admins can edit geonotices again.--Pharos (talk) 14:10, 18 September 2018 (UTC)

  @Pharos: how long should it take get the discussion below closed? I'd love for a stable system to be in place, if you can help move this towards any consensus closure that would be awesome! Feel free to request access for yourself below for stop-gap. If anyone has the programming skills to fix the "geonotice problem" (that "data" is having to be managed directly in program code, see phab:T198758) that would also be ideal not just for enwiki but for all projects. — xaosflux ^Talk 14:43, 18 September 2018 (UTC)

  I've made a request at Wikipedia:Interface administrators' noticeboard, which seemed the most appropriate place. There doesn't seem to be a strong consensus on this page yet for the long-term policy, perhaps it will be clearer once the geonotce issue is better resolved.--Pharos (talk) 15:32, 18 September 2018 (UTC)

  I suggest you apply below like everyone else did (see example here) - another 'crat may IAR process your request on that other page, but I won't. — xaosflux ^Talk 15:36, 18 September 2018 (UTC)

• As it was already moved, will process below - but getting this moved to a normal process is certainly important; assuming there is approval for non-expiring grants I imagine most of the stop-gap users will be requesting it, perhaps in bulk. — xaosflux ^Talk 18:09, 18 September 2018 (UTC)

 Done As the criteria have been met. Regarding creating gadgets, please be sure to review and follow the gadget guidelines — xaosflux ^Talk 14:46, 30 September 2018 (UTC)

Earliest closure has started. (refresh)

Ritchie333 (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've been trying out User:Enterprisey/reply-link, and in one instance (Tamarastuchlak (talk · contribs)), I've been communicating with them off-wiki because they don't have confidence to navigate talk page discussions. Hopefully installing this gadget will be a step in the right direction for them and make the site more usable. While I realise the script is still rough around the edges, it seems to work well enough for a lot of people already and I'm bound to run into other instances where it would help putting this on new users' pages so they can navigate our rather byzantine discussion system. (Sorry, I'm confused as to which dramaboards I should post this to, can somebody in the know do the necessary?) In terms of technical / programming stuff, I've written a large open-source project in PHP / JavaScript (credits here) which, while not the greatest code in the world (it was written in my spare time), it seems to work well enough. Ritchie333 ^{(talk) (cont)} 13:33, 26 September 2018 (UTC)

AN and VPT notifications left. — xaosflux ^Talk 13:39, 26 September 2018 (UTC)

• Support, of course. Also, about the script thing, Ritchie333, I'm putting together a tool that lets users add scripts to their own userpage without having to edit JS code (checkbox-style interface) which should help with this sort of problem. Enterprisey (talk!) 14:27, 26 September 2018 (UTC)

  Struck per Musik's comment below; apparently no edits to MW-space JS, which I didn't check at first. Enterprisey (talk!) 00:42, 27 September 2018 (UTC)

Well it's true that I've never edited JavaScript outside my own userspace on this site. However, I have done a little bit of coding here. Or check out https://www.sabre-roads.org.uk/wiki/index.php?title=A11 which is an example of using MediaWiki with custom PHP and JavaScript extensions that I have written myself including single login integration with phpBB (though the site is now using a third-party tool, albeit one I have fixed bugs on), or https://github.com/Ritchie333 which includes more of my open-source coding. So, while there's not much public evidence, I have done some programming! Also, I would like Enterprisey to have these rights, but he can't because he's not an admin. Somebody nominate him, please - it worked here. Ritchie333 ^{(talk) (cont)} 12:08, 27 September 2018 (UTC)

Just wanted to say I agree that Enterprisey should be an admin :) In regards to my opposition, it's not about technical competence either (though that's certainly a rough requirement, obviously). I was pointing out you've never made such edits here on Wikipedia, so it would stand to reason you could get by requesting such edits given you'd make them so rarely. I don't mean to introduce such bureaucracy. I'm just trying to push the "reducing attack surface" mentality, which is the point of why int-admin was introduced. But I don't think adding reply-link to new user's JS is such a great idea either, given it's very much beta (alpha even), and user JS should probably be left to the user, barring technical corrections. What do you expect them to do when reply-link fails? To me it would seem out of line to force any script on users -- they should decide that for themselves, no? — MusikAnimal ^talk 18:53, 27 September 2018 (UTC)

Yeah, I see where you're coming from - less people with the right = less people whose accounts can be hacked / stolen to abuse the right (although you only need to crack 1 of 1,000+ admin accounts to delete the main page and indef Jimbo Wales....) I just think reply-link actually goes far more towards the problem that Liquid Threads and Flow was supposed to solve but never did. I don't see us ever getting rid of the text based system; we just need smarter code and UI to manage it. I'm definitely not planning on going around every new user with a Teahouse invite and slapping reply-link on their common.js - people can generally add it themselves if push comes to shove. (Although have you tried editing common.js on a smartphone?) But not everyone wants to invest the same emotional time and effort on Wikipedia as we do, and if we can offer to reduce the barriers to entry, then at least it's an option. eg: "By the way we've got a new experimental message system that you can use on your smartphone to make discussions a bit more like Facebook / Twitter / WhatsApp - you can install it by editing Special:MyPage/common.js and adding the line blah blah.js, or if you'd prefer, I can install it for you". And yes, I can ask a UI tech admin to do it for me, but I'm the sort of person who likes to roll up my sleeves and just do it myself (which is why I've ended up doing lots of editing here instead of sitting around hoping articles will magically get better by themselves). Anyway, that's basically my motivation for all of this.

As for Enterprisey, I have to say I was crestfallen when he ran at WP:ORCP recently and got a whole bunch of 2.5 "No need for the tools" comments. When this has all blown over, we can revisit that. Ritchie333 ^{(talk) (cont)} 20:19, 27 September 2018 (UTC)

I would definitely support Enterprisey for admin as well.--SkyGazer 512 ^{Oh no, what did I do this time?} 19:18, 27 September 2018 (UTC)

• Support. Hasn't destroyed the wiki yet.--SkyGazer 512 ^{Oh no, what did I do this time?} 14:33, 26 September 2018 (UTC)
• Support, no problem--Ymblanter (talk) 14:37, 26 September 2018 (UTC)
• I haven't seen anything to suggest that non admins can't chime in, so I support this request because Ritchie333 is an extremely trustworthy admin who's never shown the slightest indication that they would misuse this, even unwittingly. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 14:43, 26 September 2018 (UTC)
• Sure TonyBallioni (talk) 15:47, 26 September 2018 (UTC)
• Didn't misuse the tool before when they had access. I don't see why not. SQL^{Query me!} 16:27, 26 September 2018 (UTC)
• Support as well. Also @Enterprisey: don't we already have User:Equazcion/ScriptInstaller for that? — AfroThundr ^{(u · t · c)} 18:00, 26 September 2018 (UTC)

  The idea is new users shouldn't have to touch JS at all; installing ScriptInstaller itself requires manipulating JS, if even a little. Enterprisey (talk!) 18:32, 26 September 2018 (UTC)

• Weak oppose Not compelling rationale, in my mind. I trust Ritchie immensely, but again, this is not about trust, which some of the above !votes seem to think it is. Of course Ritchie isn't going to burn down Wikipedia. We know that. Int-admin is about reducing the attack surface, so I prefer to see a compelling, regular need for the rights. Maybe Ritchie desires to help users with JS/CSS in general, but it would appear there is no record of this (though we can't always go by numbers, since admins can no longer edit such pages).

  In regards to this use-case specifically, an editor who is unable to communicate should not rely on assistive scripts, they should be taught how to communicate, or given links to resources so they can learn on their own. I agree the whole talk page system is awful... but I don't see how you'll ever grow as an editor without learning it. As amazing as reply-link is, it is not a replacement, but a supplement (all respect to Enterprisey and his fantastic work, I know it's still beta-ish, but it failed on the last 2 comments I tried to make here). You should be able to give the user the code to enable the script anyway, no? Edit, paste code, hit save.

  Sorry for being a hard-ass! Don't take my opposition personally :) More security breaches have gone down as of late. The need to limit access to editing JS/CSS is real and has proven itself many times over. Let's not forget how serious this is. If you can get away with asking an int-admin to do a few one-off tasks for you, is that so hard? — MusikAnimal ^talk 21:05, 26 September 2018 (UTC)

  Also, once reply-link is more stable, we should turn it into a gadget. That would make it easier for newbies to enable it, and frankly we might even consider making it on by default. I doubt it will ever be perfect though -- not because Enterprisey can't do it (he's among the best JS programmers we have!), but because of the non-structured, unpredictable format of talk pages. The day we fix talk pages is most likely the same day we get rid of wikitext — MusikAnimal ^talk 21:23, 26 September 2018 (UTC)

• Oppose I trust MusikAnimal eyes and per his comments Hhkohh (talk) 21:13, 26 September 2018 (UTC)
• (edit conflict)Support per SkyGazer 512. ^Semi_Hypercube ✎ 21:15, 26 September 2018 (UTC)
• Oppose I trust Ritchie333 not to break anything (but this is NOT about trust in the first place), but I oppose as this is not a true need for the bit. Almost anything in userspace .js/.css can be edited by the user itself (except if the 'owning' user is not active anymore, in which case I would argue that the script be adopted by s.o. else and that would be a one-off case to replace the original script with a redirect, and urging all users to use the copy now). Any improvements there can, and probably should, be done through edit requests or sandboxing, and being implemented by the 'owning' user. In my opinion, not even int-admin users should edit in other user's .js/.css, but strictly do that through sandboxing/edit-requests. --Dirk Beetstra ^{T C} 05:37, 27 September 2018 (UTC)
• Support, he managed not to destroy Wikipedia when all admins had this access, this isn't RFA so saying "no need for the tools" is even more of a meh non-reason than when people say it at RFA. Fish+Karate 09:03, 27 September 2018 (UTC)
• Support. If we're so paranoid about attacks form compromised accounts that we can't even give the tool to someone who has an actual need for it, we may as well give up and say only WMF techies can make these changes. But Ritchie please take extra precaution with regard to securing your accounts while you have the permission, don't leave your account logged in on an unsecured phone or computer etc.  — Amakuru (talk) 09:11, 27 September 2018 (UTC)

  "Actual need" is arguable (I was unable to make this comment with reply-link, too!). Ritchie has never used these rights before, and the use-case is questionable at best. Requesting a rare edit to user JS isn't so hard, but frankly that should be left to the user, as it's not hard for them to do it themselves, and I think they should be the ones making these decisions. You're almost on to something with your second point. Not restricting edits to WMF, but enforcing some sort of code review system. I think that's probably where we'll end up, but int-admin is as good as it gets right now. Anyway I'm not trying to shoot down Ritchie's request, or pretend it's an RfA. We have very good reason to be paranoid about security, so I'm trying to push the mentality of maintaining a minimum attack surface. It doesn't look so great because I'm an int-admin myself, but I promise this isn't about me or establishing an elitist group. People seem confused and think int-admin is about trust and technical competence (not you, necessarily). It's a social problem that I take will not be solved, but A for effort, I hope :/ — MusikAnimal ^talk 19:22, 27 September 2018 (UTC)

  Weird. Worked for me. I think it has something to do with browser compat issues. Enterprisey (talk!) 19:38, 27 September 2018 (UTC)

Just to follow up on Amakuru's comments, I have two-factor authentication enabled and never leave myself logged in anywhere. Actually, I think that should be a requirement of all Interface Admins, regardless. Ritchie333 ^{(talk) (cont)} 20:19, 27 September 2018 (UTC)

• Sure, don't see why not. Trust and technical competence seem to be there in the requisite quantities. Boing! said Zebedee (talk) 11:39, 27 September 2018 (UTC)
• Support - This overly bureaucratic process is embarrassing. Nothing in his history would lead anyone to believe granting him a right, which he had previously, would lead to any trouble. Nihlus 12:21, 27 September 2018 (UTC)
• Support he had access to it before, nothing went wrong. Also per Amakuru, and per Ritchie's reply to Enterprisey. —usernamekiran(talk) 18:16, 27 September 2018 (UTC)
• Support per Nihlus, "overly bureaucratic process" - TNT ^💖 20:58, 27 September 2018 (UTC)
• Support Hawkeye7 (discuss) 05:53, 28 September 2018 (UTC)

As that page is widely edited, and it is basically a 'settings' page (not true script), would it not be worth to turn that into a regular MediaWiki page so it can be edited by all admins again? The current situation with that particular page is rather disruptive, and many editors basically now need the bit solely to edit that page. --Dirk Beetstra ^{T C} 14:50, 18 September 2018 (UTC)

Is this technically possible? I had thought that something more involved was necessary (phab:T198758), but if not we should just do it. I don't think anyone in this discussion has objected to admins using geonotice as before.--Pharos (talk) 15:10, 18 September 2018 (UTC)

There is a text on the notices page that states 'Currently, MediaWiki:Gadgets-definition specifies the geonotices to be listed at MediaWiki:Gadget-geonotice-list.js.' I have to parse this gadget better, but I have the feeling that there is a JSON parse of that .js. Movi g the .js to a .json andpointing the script there may be sufficient. .json is freely editable (by admins). --Dirk Beetstra ^{T C} 15:29, 18 September 2018 (UTC)

So, one option is having a bot regularly (~5 minutes) copy the text of some fully-protected page into MediaWiki:Gadget-geonotice-list.js. This isn't optimal from a security standpoint, but at least we could block the bot instantly if it edits any other page. Enterprisey (talk!) 21:16, 18 September 2018 (UTC)

The advantage to JS here is that it is behind ResourceLoader, which wouldn't be the case for JSON. We might want to give phab:T198758#4473145 a try, just to see if that works (using something other than geonotice for testing!). I'm confused how wikitext is any better than JSON, as it would seem we'd have to source it on every page load, too? I'll ask Tgr about it. If that doesn't work, then Enterprisey's idea to use a syncing bot seems like a viable alternative, at least until the core issue is resolved. I would be happy to help with that. — MusikAnimal ^talk 22:08, 18 September 2018 (UTC)

Wikitext has transclusion; but ResourceLoader loads the source, not the rendered version, so of course that didn't work. The bot is not a bad approach security-wise, as long as it actually verifies that the content is JSON (and it is set up safely). --Tgr (talk) 00:33, 19 September 2018 (UTC)

I don't think it would be too bad to IAR our way through a intadmin-bot BRFA, but we should have a VPPR discussion about it first. I don't think waiting for the current granting-process discussions to conclude would be necessary, either, as this is a somewhat different issue. Enterprisey (talk!) 08:00, 19 September 2018 (UTC)

Proposal: Bot-synced geonotices

As a temporary measure until T198758 is fixed, a new fully-protected page will be created at Wikipedia:Geonotice/list.json, and a bot with the intadmin permission will copy the text of that page to MediaWiki:Gadget-geonotice-list.js every five minutes. This means all admins will be able to update geonotices again. The bot will verify that the text has only JSON and that it won't cause issues when copied; the bot will still have to go through a BRFA. Enterprisey (talk!) 19:03, 22 September 2018 (UTC)

• Support as proposer. This is safe because we can instantly block the bot on sight if it ever performs any other action besides regular updates. A supervisor bot can be written to ping AN and IRC in that event. Also, I have notified AN, VPPR, and VPT of this discussion. Enterprisey (talk!) 19:03, 22 September 2018 (UTC)
• @Enterprisey: do you mean something like Wikipedia:Geonotice/list.json not Wikipedia:Geonotice/list.js? Is there an existing iadmin (or at least an admin) that is offering to run this bot (c.f. Wikipedia:Bot_policy#Bots_with_administrative_rights) ? — xaosflux ^Talk 19:49, 22 September 2018 (UTC)

  Yes, and Musik said he was interested. Enterprisey (talk!) 19:59, 22 September 2018 (UTC)

  It would be pretty trivial to write. Instead of a block, you could also use a go/no go page (I use this for a lot of mine). SQL^{Query me!} 19:59, 22 September 2018 (UTC)

  Yes, that may also work. What I'm concerned about is someone else taking over the account; I imagine they wouldn't care very much for the go/no go page in that case. Enterprisey (talk!) 20:01, 22 September 2018 (UTC)

  Bot "go" pages can easily be admin edit protected as well. — xaosflux ^Talk 02:40, 23 September 2018 (UTC)

  Completely agreed. (I was saying if someone took over the bot account, they would of course disregard the go/no go page and a block would be necessary. It makes perfect sense to fully protect the go/no go page.) Enterprisey (talk!) 03:18, 23 September 2018 (UTC)

• Support. The point of a separate interface-admin permission is to protect the wiki from sneaky or overwhelmingly obvious scripting vandalism. It's not meant to prevent admins from editing geonotices, so we ought to find a way around that if possible, and this is an easy route. Just make sure the bot isn't a normal admin (if that's possible) so that the account couldn't unblock itself if a rogue human got control of it. Nyttend (talk) 03:25, 23 September 2018 (UTC)

• PS, Enterprisey pointed me to Special:ListGroupRights#interface-admin, which notes that the interface administrator user group doesn't have any general admin rights except editing MediaWiki pages; interface admins can't unblock themselves unless they're also administrators. Nyttend (talk) 04:04, 23 September 2018 (UTC)

• Support I think this is a smart way to restore some abilities to admin while safe guarding the broader intadmin permissions. Best, Barkeep49 (talk) 03:59, 23 September 2018 (UTC)
• Support only until T198758 is fixed, as a nice temporary measure that should however never have been required, and that is a short-term solution for a problem that eventually must be fixed via a MediaWiki software update. ~ ToBeFree (talk) 04:09, 23 September 2018 (UTC)
• Support until json can be used by sitewide scripts. --Dirk Beetstra ^{T C} 04:21, 23 September 2018 (UTC)
  • Thought: for additional security on the bot-account (though I expect it to be excessive), we could use an edit-filter to make sure that the bot can only edit only the specific page it is supposed to edit, blocking all other edits (in case there are editors not willing to grant the bit for security reasons). --Dirk Beetstra ^{T C} 06:23, 25 September 2018 (UTC)
• Support as most sensible interim solution. — AfroThundr ^{(u · t · c)} 06:00, 23 September 2018 (UTC)
• Sounds like a sensible solution - and it introduces error handling to a page that is easy to break, I've got a few ideas that would belong at a BRFA - so will look for one to be open. This process should/can be tested up on testwiki as well to make sure it works good before bringing here. — xaosflux ^Talk 15:02, 23 September 2018 (UTC)

  To echo what some others have said, this should be a temporary solution, it is far from ideal and could break down at anytime. — xaosflux ^Talk 04:34, 30 September 2018 (UTC)

• Support as a convenient workaround until we have a better system. I indeed am interested in authoring such a bot. It should be fairly straightforward — MusikAnimal ^talk 01:26, 24 September 2018 (UTC)

  @MusikAnimal: feel free to open a BRFA - you know they can be open for a long time! - to field any task specific questions. — xaosflux ^Talk 02:22, 24 September 2018 (UTC)

• Support. A viable workaround for the meantime. –Ammarpad (talk) 08:39, 24 September 2018 (UTC)
• Support Sounds like it should work. ^Semi_Hypercube ✎ 23:07, 24 September 2018 (UTC)
• Support It is very valuable that geonotice is in the hands of a relatively broad group, like it has been in the past..--Pharos (talk) 02:24, 25 September 2018 (UTC)
• Support. This is a sensible solution, though we should keep IAdmin access for a few geonotice maintainers in case the bot stops. Deryck C. 10:37, 25 September 2018 (UTC)
• Support - It's obviously not ideal to have to resort to such a workaround in the first place, but this will definitely work until T198758 is resolved. ~Oshwah~^{(talk) (contribs)} 11:25, 26 September 2018 (UTC)
• No objection —TheDJ (talk • contribs) 09:47, 27 September 2018 (UTC)
• Support. Certainly seems like a good idea and don't see why not.--SkyGazer 512 ^{Oh no, what did I do this time?} 19:29, 27 September 2018 (UTC)

• So, I supported above, so would someone else review and close this. Note, this will not result in an access change directly - but will be used to show community support for this use case in Wikipedia:Bots/Requests for approval/MusikBot II 2. — xaosflux ^Talk 04:32, 30 September 2018 (UTC)