Wikipedia:Interface administrators' noticeboard

Welcome to the interface administrators' noticeboard

This is the interface administrator noticeboard, for discussion of interface administrators and coordination of edits to the interface.

Currently only interface administrators can undelete JS/CSS pages, if you have an uncontroversial undelete or deleted version retrieval request, please list it below.

Any administrator can delete JS/CSS/JSON pages, for speedy deletions just use a CSD template on the page or its talk page.

Individual requests for edits to interface or user JavaScript/CSS pages should continue be made on their respective talk pages.

Interface administrators'
noticeboard archives:
1 2 3 4 5 6 7 8 9 10
1 interface-protected edit request
Page Tagged since Protection level Last protection log entry
MediaWiki:Common.css (request) 2019-09-29 02:38 Site CSS page (log) Protected by Sam Korn on 2005-07-21: "As with all MW: pages, can't have vandals getting to the styles!"
Updated as needed. Last updated: 23:06, 21 October 2019 (UTC)

#p-pagetriage-enqueue on Main page[edit]

Hmm, WP:ITSTHURSDAY? Think this is new, and really it doesn't belong on this page - any suggestions for the 'best' way to remove this. Appears as pagetriage-enqueue in the "tools" section of the sidebar. — xaosflux Talk 16:16, 27 September 2019 (UTC)

And yes, I'm already thinking about Main_Page/styles.css or the like........ — xaosflux Talk 16:17, 27 September 2019 (UTC)
This is to allow loading of curation toolbar on "any" page. It really shouldn't show on mainpage, but no one thought of that on the phab task and when the code was merged. – Ammarpad (talk) 16:36, 27 September 2019 (UTC)
Do you have a link to the task where it's being discussed? ~ Amory (utc) 16:52, 27 September 2019 (UTC)
Hmm, phab:T207485 maybe. — xaosflux Talk 16:55, 27 September 2019 (UTC)
Yes, thanks Xaosflux. – Ammarpad (talk) 16:57, 27 September 2019 (UTC)
(edit conflict)Is adding the main page to the queue something we can prevent from taking place via edit filter? I'm not sure about it, but might that be cheaper? At least until it's dealt with in the software. It's only a brief amount of CSS, admittedly, but it does get an awful lot of views... It's not super urgent, so I might be inclined to let it lie for a bit since that phab seems pretty well watched. ~ Amory (utc) 16:56, 27 September 2019 (UTC)
Well, it's not like everybody is seeing the link. It's only visible to people with the right permission. – Ammarpad (talk) 16:59, 27 September 2019 (UTC)
Indeed my point — css would be loaded for everyone, it's not urgent, and folks who can and would use it are likely not going to do so for the main page. Should be removed/fixed/etc. but preferably (IMO) by the software itself. ~ Amory (utc) 17:02, 27 September 2019 (UTC)
@Amorymeltzer: patch filed DannyS712 (talk) 17:26, 27 September 2019 (UTC)
... +2 by MusikAnimal - should be deployed on wiki by Monday DannyS712 (talk) 18:01, 27 September 2019 (UTC)
Could use MediaWiki:Group-patroller.css and MediaWiki:Group-sysop.css to not load css for everyone. Galobtter (pingó mió) 23:05, 27 September 2019 (UTC)
Note, this seems to create a new dead-end workflow for an editor, if you unreview a page you authored, you can't undo your action. See phab:T234067. — xaosflux Talk 17:08, 27 September 2019 (UTC)
  • Hmm, If my analysis is correct, overall this change is probably problematic (or maybe I should say not well thought out). Theoretically, clicking the link will "unreview" the mainpage, and therefore noindexed until re-reviewed. I just tested it at Test (I use the page since it only loads on mainspace pages). I don't know how this feature will interact with what was described here. If it's true that after 90 days mainspace articles cannot be de-indexed, then a useless link is now being shown on >5 million pages, this is not ideal. If this new feature works as it says on the tin, then it's really problematic; because now (some) people have the power to de-index a 10-year old page, heck even the mainpage and it's 2001 contemporaries. I don't think the community approve of this. – Ammarpad (talk) 17:21, 27 September 2019 (UTC)

Hello, everyone. My name is Ilana, and I'm the product manager for the Community Tech. We're currently looking into the issue, and we plan to dig into it on Monday. In the meantime, here is some background information, as provided by the engineers: "We implemented the 'add to queue' functionality per request of the NPP community. But you are right; weighing things out, it seems like we need broader consensus, to say the least. The original request, by the way, was to simply be able to use Page Curation's tagging features on any page. This unfortunately isn't how it works; the page must be in the 'queue' for the Page Curation toolbar to be functional (it also has to do with scope, e.g. Page Curation is supposed to be only for 'new' pages). So the compromise was to introduce the workflow (a) add page to queue, (b) tag as desired, (c) re-review, or leave unreviewed at the reviewer's discretion. We can revert this change if you all feel it is necessary, but I don't think we can do any deploys until Monday." IFried (WMF) (talk) 20:59, 27 September 2019 (UTC)

Hey IFried (WMF), thanks for the update. If you want a further conversation on the (un)deployment of the tool itself, you'd probably be better off at WT:NPP or WT:NPP/R; this board won't garner the interested parties to opine or provide feedback on that. And as for I don't think we can do any deploys until Monday, it is Friday of course! ~ Amory (utc) 21:13, 27 September 2019 (UTC)
@IFried (WMF): this doesn't seem to be any "rush" situation (also why we are using this somewhat backwater technical coordination page to talk about it right now) - and I don't think anyone here sees a specific problem with what was trying to be accomplished, just with the unintended consequences - as well as making sure it is well documented and understood. Keep in mind the difference between "patrolled" and "reviewed" here, as well as what (or not what) impact is made against NOINDEX. — xaosflux Talk 21:27, 27 September 2019 (UTC)
Regarding "add to queue" is this also "un-mark as reviewed" / mark as "unreviewed"? — xaosflux Talk 02:13, 28 September 2019 (UTC)
If you click the link and confirm (which I believe is what you mean by "add to queue"), two log entries will be generated:
  1. 17:05, 27 September 2019 Ammarpad talk contribs marked Test as unreviewed (Tag: PageTriage)
  2. 17:05, 27 September 2019 Ammarpad talk contribs added Test to the New Pages Feed (Tag: PageTriage).
They inverted here, so the second log entry is what happens first, then followed by the first. – Ammarpad (talk) 05:23, 28 September 2019 (UTC)
Thanks @Ammarpad:, the NOINDEX notes refer to 'patrol' status not 'review' status, so that shouldn't change here. — xaosflux Talk 12:07, 28 September 2019 (UTC)
I admit these really confuse me. What does "review" do to a page then? – Ammarpad (talk) 03:55, 29 September 2019 (UTC)
@Ammarpad: see this log as an example. "Review" puts a page in to or out of the review queue, there is overlap though - since using the review tools will also cause a page to be "patrolled". It is possible to patrol a page alone as well - we have two systems that ride on top of each other, and the implementation at enwiki is different from most other projects. Currently you can mark a page "unreviewed" as well, but there is no way to "unpatrol" a page (and I don't think this is trying to create one). — xaosflux Talk 04:06, 29 September 2019 (UTC)

Update for everyone, including @Xaosflux, Ammarpad, and Amorymeltzer: We've investigated the issue and confirmed that adding old pages (>90 days) to the queue will not remove them from search results. However, we identified that our changes did introduce the ability to unreview the Main Page, which should never occur. For this reason, a fix (thanks to DannyS712) has been developed, and it should be on production tomorrow. Thanks for your assistance and flexibility as we looked into the issue! --IFried (WMF) (talk) 20:01, 2 October 2019 (UTC)

Thanks for the info. IFried (WMF). – Ammarpad (talk) 05:26, 4 October 2019 (UTC)

Gadgets sourcing user scripts[edit]

Following up from Special:Permalink/920644229#Gadgets with imports. There are numerous gadgets that source user scripts. This usually is done so that non-int-admin gadget maintainers can easily deploy updates. While there is a convenience factor, it is a security risk, and it undermines the whole point of having interface admins. Essentially non-admins are able to act as interface admins. This is not good. and identify some such gadgets, but there may be more. Some gadgets ultimately source user scripts on other wikis, too. Ideally everything will live in the MediaWiki namespace (either here or on the foreign wiki), and all updates will go through interface admins.

Should we proceed with migrating these to MW namespace? Should we prohibit this practice moving forward? Are there any exceptions?

My opinion is yes, migrate them all, prohibit this practice, with no exceptions. Even if the maintainer is an interface admin, that might not remain true. Keeping all site-wide JS in the MediaWiki namespace seems like the safest system. Thoughts? MusikAnimal talk 16:31, 11 October 2019 (UTC)

Pinging Xaosflux and Amorymeltzer, who participated in the discussion on my talk page. MusikAnimal talk 16:33, 11 October 2019 (UTC)
@MusikAnimal: in general I think we should avoid any userpage imports there. Any thoughts on cross-project imports? — xaosflux Talk 16:44, 11 October 2019 (UTC)
@Xaosflux: I think they are fine so long as they live in the MW namespace on whatever wiki they originate from. If it is a very simple gadget you might just copy it here, but otherwise it's nice to let the maintainers give us free updates. All wikis have the same interface admin restrictions so we should be safe in that regard. Of course, if the cross-wiki script originates in the userspace, then we should consult them to move it to the MW namespace, or host our own fork here. MusikAnimal talk 16:57, 11 October 2019 (UTC)
Agree with all of the above, that ideally MWspace should only load MWspace (and select items from wmflabs, perhaps, but that another issue). I'm not certain that everything should by default being in the MediaWiki-Gadget- pseudonamespace, but going back and forth there doesn't matter much. I do think it'd be good to migrate everything if we can, but I imagine there are going to be some major issues with long-term things like WikiEd or JWB. It might make sense to get a list of everything so we can audit potential issues and let that inform the next steps. I also think we should do a similar aduit for fully-protected WPspace scripts (I think I mentioned this on your talk a while ago, xf, while discussing cascading protection or something). ~ Amory (utc) 17:20, 11 October 2019 (UTC)

Here's the list I came up with based on and

The first several instances are very popular gadgets, and most of them are actively maintained. Perhaps we should see if the maintainers are content making edit requests moving forward? In my opinion this should be obligatory. MusikAnimal talk 17:54, 11 October 2019 (UTC)

Some quick thoughts:
  • Comments in local time is popular and has an active maintainer (as of April). At the time I went through the diffs to try to verify all the changes, but it thankfully hasn't needed too much active work. Probably worth asking Gary how he'd feel moving it to MWspace.
  • The google trans script is a prime candidate for moving IMO, especially since the maintainer isn't a sysop.
  • RTRC links to meta:User:Krinkle/RTRC.js which actually just imports mw:MediaWiki:Gadget-rtrc.js, so that's a super easy fix.
  • MediaWiki:Gadget-RegexMenuFramework.js has been hidden and is deprecated in favor of meta:TemplateScript. Per Special:GadgetUsage there are ~15,000 installations, although I'm not sure it even works. We should offer TemplateScript as a gadget, but at the very least we could import the script from tools (incidentally, this is my personal biggest concern for the coming CSP lockdown).
  • I think we can just have Enterprisey overwrite the subpages, there shouldn't be any issues right?
  • I'm going to delete the compare link script as it's hasn't been working since for 4.5 years, especially in light of the 2008 conversation leading to its move.
  • I can see the utility of mobile-sidebar for users, and it does still appear to be working fine enough vector, but it's a weird fit. I have a hard time imagining someone wanting it on 100% of the time, so I must think that the 4700 users are inactive, with some maybe enabling it temporarily now and then. If we're set on keeping something like it, we can just fork Brion's code and place it here, but I'd be in favor of deleting it. It really needs a portlet serving as a toggle to be useful IMO. See note below, there's a toggle, so we should just copy BV's code.
More urgently, I've only just now realized how huge of a risk WikiEd is. It imports a few dozen userspace js pages for translation stuff (search for wikEd.InitTranslations) and near the top in terms of users. ~ Amory (utc) 19:39, 11 October 2019 (UTC)
mobile-sidebar does have a toggle (next to the watch button). SD0001 (talk) 20:40, 11 October 2019 (UTC)
Word! Missed that, makes its potential usage much more reasonable. ~ Amory (utc) 20:49, 11 October 2019 (UTC)
Yeah, moving those WikEd translation js pages to mediawiki space is definitely a must. Galobtter (pingó mió) 05:13, 12 October 2019 (UTC)
Pursuant to my above comments, I've dealt with the easy/obvious/low-hanging fruit of RTRC, mobile-sidebar, and compare link. For RegexMenu I still think we should just replace it with TS as a potential stopgap at least (no less safe, at least); we can then unhide the gadget. ~ Amory (utc) 12:11, 12 October 2019 (UTC)
LinkFixr and (to a lesser degree) HighlightEditSection have some imports by some active folks. It's a finite number and shouldn't be too hard to change them since it's a simple fix. The great Magnus Manske is occasionally active, although those haven't been updated in ages. ~ Amory (utc) 14:54, 12 October 2019 (UTC)

This topic has been on my mind, following a similar, much-earlier, discussion. I agree firstly with a strict, "no tolerance" policy for user scripts being imported into gadgets, however useful they may be. I am also honestly concerned that we import cross-wiki gadgets, from users who will not have gone through our local process (RFA, for better or worse) for getting the interface admin role. I might even suggest that we should have a strict no-crosswiki scripts policy here as well, but I'm willing to put that one to an RFC. There is probably some middle-ground there to consider. (There's another can of worms that a compromised interface administrator could unilaterally push changes without review, but I know that's a bigger one and has a few phabricator epics attached to it.) --Izno (talk) 19:48, 11 October 2019 (UTC)

Disallowing cross-wiki gadget imports would be a very bad idea. Gadgets like HotCat are maintained at one place (commons in this case) and all wikis import from there. If every wiki were to keep a separate copy, do you expect the maintainers to update it (or make an edit request for update) on every single wiki, every time? SD0001 (talk) 20:14, 11 October 2019 (UTC)
I agree. I'm actually working on a new version of m:MoreMenu that is wiki-agnostic, and having the script in one place is the primary motivation. Interested wikis import one JS page and everything just "works", no configuration or translations necessary. I think x-wiki is fine, so long as the script in its entirety exists in the MW namespace. If we are importing a x-wiki gadget here, we essentially are entrusting the int-admins who control it. MusikAnimal talk 20:55, 11 October 2019 (UTC)

I disagree with your stand on user controlled gadget files on Wikipedia. I maintain GoogleTrans gadget quite well by having it sourced from a file in my user space. I think the current system works quite well, and your suggestion is a sign of the security at all costs mania of the US today. This is also a backdoor way to reduce the number of gadgets out there since any maintenance to the gadget is prevented by your suggestion. Endo999 (talk) 21:15, 11 October 2019 (UTC)

I'm not sure about a 100% prohibition - but perhaps we should add an extra warning to the descriptions page at least. — xaosflux Talk 22:51, 11 October 2019 (UTC)
Regarding RTRC, User:Krinkle is a GIE, so not having a trustiness type issue, but that one looks like it is bouncing back and forth across 3 projects to run? — xaosflux Talk 22:57, 11 October 2019 (UTC)
Just replace its contents with mw.loader.load(''). This is the ResourceLoader-minimised version that would load faster than the raw version at . SD0001 (talk) 04:01, 12 October 2019 (UTC)

Userspace, crosswiki, and toolforge imports[edit]

Scripts in userspace may not require special permissions or going through any community vetting process, but they expand the avenues of attack by exactly one user; and their script may have been picked precisely because they have demonstrated trustworthyness. I think these are actually the least risky.

Toolforge has no special requirements for access, does not require 2FA, access is approved by a single person after a superficial check for red flags, and there are no audit mechanisms once access has been granted. Changes there will not show up in any log or watchlist here, so any bad actor won't be caught until after we've all mined bitcoin for a while. I'm not actually convinced Gadgets here should ever import anything from Toolforge (asking it for data, sure, but not actually importing and executing code from there).

Other wikis—especially smaller ones—have vastly different policies and cultures. Admin and interface admin is assigned as a bit more or less for the asking, without checking for 2FA (which I don't mind because it's a dumb requirement, but…), and nobody is likely to notice any changes because smaller projects don't have the manpower for that kind of thing. Due to lack of manpower they tend to be averse to formal policy or rigid processes and anything smacking of bureauocracy: the very mechanisms that enable trust in security terms. Most smaller projects are badly pinched for people willing to swing the mop, not to mention technical work.

Foreign language projects may also have a majority of users subject to repressive regimes in the associated countries, regimes willing to exert various forms of pressure on its citizens for their goals. Or put another way, even Germany and the US have pre-emptive hacking in the toolbox that police are allowed to use for various purposes, and in large parts of the world use of such tools are not even subject to any checks and balances to speak of. Can you think of any regimes that might be interested in what its citizens are doing on Wikipedia? Or who might have a special interest in particular Wikipedia users?

On the other end of that scale is Commons: in the grand scheme both policy and culture there is pretty similar to here. Importing HotCat from there poses very little real risk.

I don't think flat out forbidding any particular kind of import is proportionate to the risk, but there's a rather large continuum of risks and attack vectors that needs to be recognized and handled. Maybe userspace imports to MW:-space should only be permitted from particular users subject to some kind of vetting (something "BAG Light"-esque maybe?)? And crosswiki from Commons subject to a one-time approval complemented by some kind of active cross-project coordination and agreement on policies? Maybe other cross-wiki imports should be forbidden unless some minimum standards for compatible policy and process are documented? --Xover (talk) 11:34, 12 October 2019 (UTC)

editToken --> csrfToken migration[edit]

There exist no lesser than 212 user scripts that have been rendered dysfunctional by the recent removal of editToken from the mw.user.tokens object in the JavaScript interface. (See phab:T234576.) It would be great if someone can fix all these in one go by using some automation to replace editToken with csrfToken, or to be precise, doing the regex replace mw\.user\.tokens\.get\( ?['"]editToken['"] ?\)mw.user.tokens.get('csrfToken') . This would be helpful since many of these scripts are probably written by inactive users. SD0001 (talk) 19:09, 14 October 2019 (UTC)

Probably better to reference phab:T235300 because it includes the more-correct way to deal with edit tokens. That said, Krinkle has a bot for the replacements; not sure how/why these didn't get taken care of. --Izno (talk) 21:44, 14 October 2019 (UTC)
I think he only looks at MWspace gadgets, not user scripts, and also only saves if it passes some other checks. I'm in favor of this sort of thing for this type of change, as it's quite amenable to a quick search and replace without touching much else, and the deprecation was felt sudden. I'm happy to try to take care of it later this week (wed, thurs, fri) if other folks think it'd be welcome. That being said, to the best of my knowledge we've had no good conversation about intadmins doing this sort of bulk work, and while I would consider it a net positive I imagine some folks might take issue. At least some of these are certainly actively used, though there's no perfect way to assess what's abandoned or what's worth doing, so we'd have to cover them all. ~ Amory (utc) 01:26, 15 October 2019 (UTC)
I'm not a big fan of trying to maintain broken personal user scripts without being asked by the owners. No issue with dropping a bulk TALK notice on them about this discussion in case the owners want to look after their scripts. — xaosflux Talk 02:35, 15 October 2019 (UTC)
^This, generally speaking. Writ Keeper  13:47, 15 October 2019 (UTC)
👍 ~ Amory (utc) 17:08, 17 October 2019 (UTC)
I can't understand what's the reluctance against making an unambiguously positive change to hundreds of scripts that will unbreak many of them. It is far-fetched to call this "trying to maintain broken personal user scripts" - when it's clearly a single maintenance edit that can be done en masse. The 150 or so scripts that remain (Krinkle has fixed the remaining ~60 since the time of the original post) can be fixed in <1 minute by writing some javascript that any iadmin could have written in <10 minutes:
mw.loader.getScript('/w/index.php?title=MediaWiki:Gadget-morebits.js&action=raw&ctype=text/javascript').then(function() { // morebits library loaded to use its Morebits.batchOperation class used for bulk api processing  var searchResultsPage = ''; var api = new mw.Api(); $.ajax(searchResultsPage).then(function(html) { var listOfPages = $(html).find(".mw-search-result-heading a").get().map(e => e.textContent); var bo = new Morebits.batchOperation(''); bo.setPageList(listOfPages); doForEachPage(page) { api.edit(page, function(rev) { return { text: rev.content.replace(/mw\.user\.tokens\.get\( ?['"]editToken['"] ?\)/g, "mw.user.tokens.get('csrfToken')"), summary: 'Update deprecated user.tokens key', watchlist: 'nochange' }; }).always(console.log); }); }); }); 
But instead, it looks like people want to play bureaucracy and/or show high-handedness given the exclusivity of iadmin powers. SD0001 (talk) 19:52, 17 October 2019 (UTC)
I support a bulk change. I can't think of any compelling reasons not to make it. xaosflux, why do you think any owners might object to this change? Enterprisey (talk!) 00:49, 18 October 2019 (UTC)
Enterprisey Mostly just because it is busy work, like cleaning up a lint error in someone's personal sandbox for someone that has left the project - only for these pages it should be even less useful as the page will be even less read by others. Administrators shouldn't have to dedicate resources to maintaining dead single-use personal pages. As the change doesn't seem in any way "dangerous" I'm not really opposed to someone working on it - just that of all the backlogs on the project the priority of this is very very low. — xaosflux Talk 00:59, 18 October 2019 (UTC)
Okay, cool, so you'd be fine with someone doing this. Writ Keeper and Amorymeltzer, since you commented below xaosflux's earlier comment, would you oppose someone actually making this change? Or were you just agreeing with the point that we shouldn't be continuously maintaining old, broken scripts? Enterprisey (talk!) 01:03, 18 October 2019 (UTC)
With my intadmin hat on, it's more the latter, but my strongest feelings are honestly with my userscript-writer hat on. I would much rather be asked to fix something and take responsibility to fix it myself than have someone else do it for me, for reasons similar to Wugapodes below, among others. Writ Keeper  01:52, 18 October 2019 (UTC)
Fine enough, for this specific change this time - but I don't think it's the "best" thing to do and would rather people self service their own pages. Things that could help that may include some wishlist items like: Have a notification if any of your current scripts have an error in them, have the script editor call out "broken" things in the editor. — xaosflux Talk 02:01, 18 October 2019 (UTC)
As I said above, I think this particular case is amenable given the straightforward find-and-replace nature of it, and I'm happy to do it, but in general I'm mixed on it. Intadmins were created for security purposes first and foremost, and I'm not certain there's consensus on-wiki for us to mass-edit userpages; we should be careful not to try to WP:OWN everything with a .js or .css suffix. There's a lot of junk that's quite outdated — I myself have an old script that I don't like and I'm not sure worked even before this change — and aside from pointless edits, I do think we'd be suggesting that broken things might be "fixed" even when they have other issues. When there are more complicated fixes, we don't want to be on the hook.
What might be worth doing is to create a list of "most imported" scripts and try to target those, although what we'd really want is "most imported by recently-active users" which is rather more involved. ~ Amory (utc) 10:17, 18 October 2019 (UTC)
we'd be suggesting that broken things might be "fixed" - I definitely understand your line of argument. I'm finding it hard to think of how we would be giving that impression, though - if a script was already broken, this change won't fix it, so all we're doing here is restoring functionality of scripts that broke recently.
I think most imported by recently-active users is certainly one solution, but given that there are fewer than 100 scripts with this issue (statistics from SD001's post above - I haven't checked) a more straightforward batch change would probably work as well. Enterprisey (talk!) 01:03, 19 October 2019 (UTC)
  • I think a bulk talk message would be the better option. I didn't know what the problem with WP:Capricorn was until I asked Amory if they were also having problems with the script. For editors who maintain scripts but aren't up to speed on the nitty gritty of mediawiki update, knowing that the process of getting tokens has been updated would probably be slightly more useful than just having it changed. Teach a man to fish and all that. Wug·a·po·des​ 01:42, 18 October 2019 (UTC)
    What about inactive script authors who probably won't fix their scripts? Enterprisey (talk!) 07:47, 18 October 2019 (UTC)
    If they are inactive they won't be using said broken scripts then will they? — xaosflux Talk 11:07, 18 October 2019 (UTC)
    What about active users importing those scripts? Scripts are hardly ever written for the author's sole use. SD0001 (talk) 12:14, 18 October 2019 (UTC)
    Really this is a caveat emptor problem. We really should be encouraging "popular" scripts to move in to gadget land so they can be more properly community-maintained. — xaosflux Talk 13:52, 18 October 2019 (UTC)
    Sure, I agree with that, but it might take a while. What about making the fix now? In my opinion this is a one-time issue that should be dealt with relatively soon, and only if this sort of thing becomes a pattern should we consider more long-term changes like that. Enterprisey (talk!) 01:00, 19 October 2019 (UTC)

Popular Personal Scripts[edit]

I'd really like to see popular personal scripts advance to Gadgets when possible, but for a stop gap any thoughts on getting script owners to explicitly opt-in to allowing edit requests on their scripts from others to be routinely processed by admins? — xaosflux Talk 23:38, 21 October 2019 (UTC)