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.
When does this go live, i.e. on what date will admins lose the ability to edit pages now covered by the interface admin permission? I am concerned that there doesn't seem to be much of a consensus above as to who will be granted this and how. Will we need an interim stopgap to allow the permission to be granted those who need it while discussions about applicable policy going forwards continue? WJBscribe(talk)10:18, 10 August 2018 (UTC)
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.
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.
sitewide CSS, JavaScript and JSON pages (pages such as MediaWiki:Common.js or MediaWiki:Vector.css, or the gadget pages listed on Special:Gadgets), CSS/JS/JSON pages in another user's userspace, and pages in the MediaWiki namespace
sitewide CSS/JS pages (pages such as MediaWiki:Common.js or MediaWiki:Vector.css, or the gadget pages listed on Special:Gadgets)...(they can also edit all other pages in the MediaWiki namespace)
The "..." does not mention CSS/JS/JSON in another user's userspace or MediaWiki namespace in general. The "they can also edit..." parenthetical seems to amplify that this is adding MW:*.js and MW:*css rather than allowing edit of only these MW and not others. But it does not seem to imply that this right is required to edit the whole MW: namespace, only the js/css subset.
The formal changes that will be made on the 27th are here. The actual code that assigns permissions (presumably the version that will be deployed) is here. It explicitly gives intadmins the "editinterface", "editsite*", and "edituser*" perms, where * means css, js, or json. Enterprisey (talk!) 21:12, 21 August 2018 (UTC)
In summary, the new access already exists - we are talking above about how to give it out. The next change is about removing existing access form sysops. — xaosfluxTalk22:19, 21 August 2018 (UTC)
According to that deployment plan, the relevant code changes are gerrit:421124 and gerrit:421125, which only remove editsitecss, editsitejs, editusercss, edituserjs but not editinterface and not editsitejson or edituserjson. I guess MW is taking it step by step. DMacks (talk) 07:04, 22 August 2018 (UTC)
There's no plan to remove editinterface, editsitejson, or edituserjson from the groups that currently have it, as far as I know. Anomie⚔12:32, 22 August 2018 (UTC)
It still looks like something should be done with the phrase "and pages in the MediaWiki namespace" here, if other administrators will still be able to edit non-CSS/JS/JSON interface pages in the MediaWiki space. Dekimasuよ!18:40, 24 August 2018 (UTC)
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.
Removal of permissons
A few comments on the proposed - It seems reasonable to have a higher activity requirement for the interface administrator permission than just sysop - 3 months without editing should be enough to remove the permission, although one could go to the step of requiring at-least one JS/CSS edit in the past 3/12 months. Something along the lines of allowing requesting back at WP:BN as long as two years haven't passed without activity seems reasonable to me too.
On the removal of permissions for misuse, while for emergency situations it is fine for crats to remove the permission, IMO in general ARBCOM should decide as with any other advanced permission Galobtter (pingó mió) 16:38, 30 July 2018 (UTC)
12 months is our standard in general, and I can foresee having people who are sysops on this project but don't edit that often because they are more involved on other projects needing it (i.e. they happen to be en.wiki sysops, but they are much more active as a MediaWiki developer, on meta, etc.) TonyBallioni (talk) 16:44, 30 July 2018 (UTC)
My feeling is that this should definitely have a higher activity requirement than regular sysop, especially as the process for granting is much easier (and re-granting even more so), and the whole point of having this as a separate right is for security etc. One edit to JS/CSS every 12 months could handle that case I think. Galobtter (pingó mió) 16:58, 30 July 2018 (UTC)
Oppose requiring ArbCom for non-emergency removal - Pretty sure EFM can be revoked by consensus at AN. Techadmin should be similar, especially if the granting process required the same level of noticeboard-discussion-consensus. Of course if sysop is a prerequisite for techadmin, any actual misuse will surely lead to an Arbcom desysop anyways. But I could think of a situation where a sysop and techadmin is being maybe lightly disruptive, unhelpful, toxic, battlegroundy, etc. around techadmin discussions which might warrant community removal of techadmin flag but not necessarily an ArbCom desysop. Neutral on any specific inactivity removal/reinstatement thresholds, whatever works and isn't controversial can be implemented for now and can be refined later if need be. Ben · Salvidrim!✉16:47, 30 July 2018 (UTC)
Consensus at AN for removal seems reasonable to me too. Wasn't able to really think of many cases where you would remove techadmin but not admin, though that you posit is certainly possible. Galobtter (pingó mió) 16:58, 30 July 2018 (UTC)
Regarding a requirement for recent Javascript or CSS edits, I don't believe there is a lot of churn on the global pages: the last fifty edits of MediaWiki:Common.js goes back to 2014, and the last fifty edits of MediaWiki:Vector.css goes back to 2013. So I think we'd largely restrict the pool of potential interface administrators to those engaging in active gadget development, which may not be desirable. Regarding a requirement for recent activity in general (3 months), I'm not sure if this is really needed, either. isaacl (talk) 17:04, 30 July 2018 (UTC)
On the other hand, it would be good to have an inactivity requirement tied to actual JS/CSS activity so someone who has moved on to other areas of the project doesn't unnecessarily keep the dangerous rights. Anomie⚔13:16, 5 August 2018 (UTC)
To put it another way, I suspect there may not be enough changes on the site-wide Javascript and CSS files to keep more than one person active at a time, which means a potential bottleneck should important changes need to be implemented quickly. If the risk of undetected compromise is deemed extremely critical to manage, perhaps the process should be turned around: identify a pool of qualified editors, but only assign the interface administration privilege for the period of time when they are making an edit, and remove it immediately afterwards. isaacl (talk) 13:32, 5 August 2018 (UTC)
Yeah, I've been thinking toward something like only granting the permission for 1 year at a time and each editor using it needs to actively reapply to keep it. --Izno (talk) 14:14, 5 August 2018 (UTC)
The question is what risk are we trying to guard against? If we want to ensure that the editors are regularly logging in so they might detect a compromised account, then an inactivity criterion may be useful. If it's a question of having current Javascript and CSS skills, maybe it's easier to just have the current group of interface administrators regularly vet each other. If it's trying to absolutely minimize the risk of undetected changes, then just assigning the privilege for the period of time to make the edit and then removing it again would be safest. (This would be in parallel with whatever process is in place to determine who is in the pool of qualified editors.) isaacl (talk) 14:40, 5 August 2018 (UTC)
An inactivity requirement is surely needed, and should be more strict than adminship. 3 months sounds fine to me. We'd go off of any logged action, not inactivity of editing site JS/CSS, because not many edits are made there as it is. Misuse can be discussed at WP:BN or the like. Emergency removal would happen only if the account is compromised, but in that case the account would be locked anyway — MusikAnimaltalk01:13, 31 July 2018 (UTC)
Would the intent of having an activity frequency be to ensure the interface administrator was regularly logging in, so they could check for any apparent security break-ins? Or is there some reason why regular logged administrator actions is desired? isaacl (talk) 01:38, 31 July 2018 (UTC)
I think MA was using it because we can't detect when a user last viewed the project unless they do something. A logged action or edit would suffice to show they had actively done something. ~ Amory(u • t • c)01:49, 31 July 2018 (UTC)
Yes, an edit would indicate activity. Perhaps I misunderstood "any logged action" as referring to logged administrative actions? isaacl (talk) 02:22, 31 July 2018 (UTC)
Sorry for the confusion. When I said "logged action", I meant any sign of activity. This would include edits, administrative actions, marking a page as patrolled, abuse filter modifications, etc. — MusikAnimaltalk02:37, 31 July 2018 (UTC)
“Permission should be removed by local bureaucrats” - Support: at present, this has to be done by a steward. —MBq (talk) 09:54, 1 August 2018 (UTC)
@MBq: our bureaucrats are able to add and remove this access. On wikis with crats being able to remove sysop this was maintained. — xaosfluxTalk10:55, 1 August 2018 (UTC)
Stop-gap users nominated
There is a clear consensus here that all these admins (TheDJ, MusikAnimal, MSGJ, Xaosflux, Mr. Stradivarius and Amorymeltzer) should be given temporary access to the new user right. As such, I have implemented the new user right on each. WormTT(talk) 17:23, 26 August 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
We are up against the -sysop access rollout in just over 5 days. I'd like to nominate myself and the rest of This, that and the other's list to have this access added for 60 days to give the rest of this page time to complete. Users requested (who may of course decline if they don't want it). I think this group of editors will be available, are technically adept, and will make non controversial edits and logged actions relating to this access. For anyone worrying, lets bind to a control similar to GIE's: Any English Wikipedia bureaucrat can revoke access if what they deem to be misuse occurs, either individually or by community request. Such a decision by a bureaucrat can be appealed at WP:BN. Assuming this RFC's get completed, the users selected below will need to apply using the normal process to maintain access. This comment period to run until 26 August 2018 at midnight. — xaosfluxTalk02:35, 22 August 2018 (UTC)
Support Already implicitly trusted by the community. There'd be real harm to the site if there were any lapse in DJ's ability to edit these pages. ~ Amory(u • t • c)10:12, 22 August 2018 (UTC)
Support Already implicitly trusted by the community. There'd be real harm to the site if there were any lapse in MA's ability to edit these pages. ~ Amory(u • t • c)10:12, 22 August 2018 (UTC)
I support this general stopgap, and specifically all these through Amorymeltzer. Noting for the record the scan for activity does not address MW: namespace, though the long-range plan for interface-admins apparently includes the editinterface right. DMacks (talk) 07:06, 22 August 2018 (UTC)
That was discussed a bit above: it was noted that there are just so few edits to that namespace that requiring intadmins to make them to keep the user right wouldn't be realistic. Enterprisey (talk!) 07:20, 22 August 2018 (UTC)
Now I'm confused. Are deferring action on the full MW: until the editinterface mode is flipped from the admin set to the interface-admin set? Or are we going to have those who we give .css/.js now as the starting set for the full MW: when the time comes? Or we are not going to flip that at all? DMacks (talk) 07:34, 22 August 2018 (UTC)
I do not believe editinterface will be removed from the admin rights. I thought you were talking about the activity requirements discussion above. Enterprisey (talk!) 07:39, 22 August 2018 (UTC)
Sorry for confusing you about my confusion! This all started from #Clarify scope of affected pages and other proposals, where I had gotten the impression that the full MW: was in scope to be removed from admin, not just added to interface-admin. DMacks (talk) 07:57, 22 August 2018 (UTC)
Hope this makes sense now? Administrators will still be able to edit the MediaWiki namespace in general (e.g. messages, things like the title blacklist, spam blacklist, etc) - just not the pages ending in .js/.css — xaosfluxTalk10:29, 22 August 2018 (UTC)
And yes, non-admin IA's will be able to edit the mediawiki namespace, though sysops can override this on a per-page basis with admin-only protection. — xaosfluxTalk11:05, 22 August 2018 (UTC)
Of course the people who do the work should be continued to allow to do the work. Too lazy to comment on individuals. Go for it. —Kusma (t·c) 10:17, 22 August 2018 (UTC)
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.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The necessity for this group is expected to go live in one month. As our RFC's here can tend to take a long time to settle, I propose a stop-gap process: authorize our bureaucrats to issue interface administrator access to any current administrator requesting access at WP:BN but with a 60 day expiration. Requests will remain open for at least 24 hours, if any 2 administrators object it will be declined. Access to be removed if a desysop occurs, upon self-request, per a WP:AN consensus, or per ArbCom. This option to expire upon the creation of the more formalized process being discussed above. — xaosfluxTalk13:30, 31 July 2018 (UTC)
Or, to stop beating around the bush, just grant it to TheDJ, MusikAnimal, Mr. Stradivarius, MSGJ, Krinkle, and perhaps yourself until we've settled on a fully-fledged policy. With the exception of a few one-offs, they are currently doing the lion's share of maintaining these pages, so the community already implicitly and explicitly trusts them. There is unlikely to be any reasonable opposition to that list when the time comes. ~ Amory(u • t • c)16:39, 31 July 2018 (UTC)
Yeah, I'm fine with that as well, though it seems like we have a rough consensus for something like what Xaosflux was proposing above, so I'm going to update the page accordingly and see if we can get an RfC together that will let it go through. @Xaosflux and Amorymeltzer: since the list of people who are likely to be approved under this process is pretty limited and we could count them on our fingers, I think the 60 days thing is just creating more work, so would suggest we not have the expiration at first so we don't have to go through the process of the same people who will get it having to apply again through any new process. Thoughts on this? TonyBallioni (talk) 19:35, 31 July 2018 (UTC)
@TonyBallioni: my only point of this section was to have something in case the RFC above was going to go long so we didn't run in to a maintenance gap and have to come up with "emergency plans", as us 'crat critters like to have a clear community mandate for our actions. If you think the issue will be solved above well in time this won't be needed. — xaosfluxTalk19:39, 31 July 2018 (UTC)
I think the community could get behind an initial process like you described so the crat critters will have something to follow, and then can make adjustments as needed after that, which could include a more formalized process. The big thing with most of the new user rights and other proposals is getting something together that people can !vote on, and then changes can be made as needed after there is a starting point. TonyBallioni (talk) 19:44, 31 July 2018 (UTC)
Yeah, I'd agree that I don't really think we'll have an issue meeting the deadline. But if my (only slightly tongue-in-cheek) suggestion goes forward, the deadline won't be an issue at all, since those editors are the ones making most of the edits anyway. There's some consensus developing above for the "only sysop" option, and it seems more are fine with the overall picture of receiving the rights. It shouldn't be too hard to hash out the contours (required questions or statement, 24/48/72 hours, 2/3 opposes, etc.) in a timely manner, and get a few more folks in there. ~ Amory(u • t • c)22:53, 31 July 2018 (UTC)
IMO this proposal is too loose, since as written it says any admin, even someone who never edited JS before, can have it for the asking as long as no one happens to object. I like Amorymeltzer's better: give it to the few people currently using it until we have a full policy decided. Anomie⚔18:50, 1 August 2018 (UTC)
@Anomie: these admins currently have this access - so I was only proposing a temporary stop gap in case this goes long, the existing "active" editors on this should be able to keep up with any protected-edit-requests as well. Speaking of which ... would you mind adding integration to User:AnomieBOT/PERTable or a similar page - I know I find those reports to be extremely useful. Thank you! — xaosfluxTalk20:42, 1 August 2018 (UTC)
It looks like you already have special highlighting for that, probally best to leave on the PROT report that is watched then to split to an IPROT report anyway. — xaosfluxTalk00:56, 2 August 2018 (UTC)
Support, with the addendum. Lots of people edit the geonotices, and I am unconvinced that we need fewer volunteers there. Making geonotices fixes go through an editprotected queue has no advantages I can think of. —Kusma (t·c) 14:09, 6 August 2018 (UTC)
Support any of these options as a temporary approach. Amorymeltzer's proposal might be my first choice, but Kaldari's broader approach is good, too. (Does anyone know whether any gadgets/popular user scripts are maintained outside of the main maintainer's userspace, but which wouldn't get picked up in that query? I'd add those editors, too.) WhatamIdoing (talk) 04:05, 8 August 2018 (UTC)
I'm OK with any of these stopgap measures. Worth noting that Krinkle and Isarra are global interface editors and not local admins, who would not need to be added to the group to retain access. Though that might suggest that there are cases where non-admins might want to help out... ;-) -- Ajraddatz (talk) 16:54, 8 August 2018 (UTC)
I support stopgap proposals to allow administrators to receive this right for 60 days after a request at BN. The specific details are not extremely important to me. Kevin (aka L235·t·c) 06:39, 12 August 2018 (UTC)
I support in order, Kaldari's counter-proposal (all admins who've edited sitewide JS/CSS in the past year as stopgap), then the basic 60-day-by-application stopgap. I think either way the broader community should take its time to decide on a more permanent policy, so that gives me pause on Tony's proposal, despite not strictly objecting to it. Since it's relevant: I'm one of the admins listed in the "past year" query, and will apply for this permission if not given it as part of the initial rollout. {{Nihiltres |talk |edits}}22:16, 20 August 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The page currently says: (choosing strong unique passwords, not getting infected by malware, preferably using two-factor authentication). I made it a little more clear that it was talking about the interfaceadmin's own account, is that sufficient? If, as it seems likely, all interfaceadmins are current sysops, the PSRs will apply. ~ Amory(u • t • c)19:33, 4 August 2018 (UTC)
If this right should have the same password and security requirements as admins, then I would prefer a more descriptive section that is similar to WP:ADMIN#Security, rather than the two sentences that was essentially copied from Meta:Interface administrators. (e.g. there should be stronger language like: Because editing CSS/JS executed in other users' browsers is very powerful and potentially dangerous in the hands of a malicious user, a compromised account will be blocked and its privileges removed on grounds of site security.) Zzyzx11 (talk) 01:32, 6 August 2018 (UTC)
Just to follow-up on this, interfaceadmins have the same strong password requirements as sysops and bureaucrats, that's coded in. ~ Amory(u • t • c)19:49, 7 August 2018 (UTC)
WMF raises connection between this user right and Superprotect
The obvious solution for this is to split Javascript editing into a separate, dedicated user group, take away the right from all other user groups (sysop, interface-editor/engineer/templateeditor on some wikis), clearly document the risks of handing out that user group, and set higher expectations for membership (e.g. use of two-factor authentication). There is some paranoia around this issue (some people an attempt to revive Superprotect behind anything that changes Javascript editing workflows) but it is unlikely that many editors will be concerned as long as it is made clear that the power to assign Javascript editing capabilities is left with the local communities.
The WMF became particularly interested in creating this user right during the Superprotect incident. Since that time I have repeatedly asked the WMF for any kind of dispute resolution plan for handling a WMF-Community disagreement in the future. They have been unwilling or unable to provide any meaningful answer. This is not an idle concern:
The WMF has been making efforts to "deprecate wiki syntax as the primary input method" since 2011.[1] In Phabricator T102398[2] I noticed that the WMF planned to switch wikis from giving users two EDIT links (one for Wikitext editor and one VE), and instead providing users only one EDIT link. I asked: Jdforrester-WMF, could you please clarify? It's very possible I'm misreading this, but it sounds like you just declared an unconditional force over of all wikis to a VE-default as part of the single-edit-tab project.[3] I was assured: ...Obviously we're not going to just do it without talking to the wikis first.[4] When the software was deployed, it removed the Wikitext EDIT link and did in fact default the only remaining edit link to VE. I, and other editors, spent over a week trying to contact the WMF. We were unable to get any response. I had to take the issue to the WMF Executive Director. We were then told that the VE default was a bug, and assured that all issues would be addressed. After a weak with no action the manager then said his original plan was to set VE as the default, and that he was now unwilling fix it. One of us then wrote (but did not deploy) a Javascript bugfix from our end. (The WMF explicitly said it was a bug!) The WMF then reluctantly agreed to fix the bug from their end.
With this new user right the WMF can prohibit us from fixing issues by revoking Interface permissions, which is merely redeployment of Superprotect under another name!
To re-quote: it is unlikely that many editors will be concerned as long as it is made clear that the power to assign Javascript editing capabilities is left with the local communities. Nope. That does not address my concerns at all. The concern is revoking the user right. If the WMF has no intention of revoking this user right for Superprotect-purposes, perhaps we can negotiate sufficiently strong assurances that it will never be used in such a fashion. Do other editors share my concern that exceptional assurances are necessary? Or should I drop the topic? Alsee (talk) 15:48, 1 August 2018 (UTC)
The WMF has no control over the assigning or removing of these permissions, so I don't think there is anything it worry about. This change also was not mandated by WMF leadership, so it is unlikely to be some backdoor effort to take control of the interface away from the community. I changed my earlier comment because it wasn't as nice/effective as I hoped it would be. -- Ajraddatz (talk) 16:01, 1 August 2018 (UTC)
WMF can change any user groups by office action, so could remove all interface admins unsympathetic to it. This separation, while good for promoting security, thus also allows the WMF to prevent community JS interventions in the name of security, in a more PR-friendly way than reinstating superprotect. The key for the community is to not allow the interface admins to become a tiny clique dominated by, for want of a better phrase, WMF sympathisers. BethNaught (talk) 16:34, 1 August 2018 (UTC)
Which doesn't change under interface-administrator-dom. They could have done just the same with the administrator user right. This looks like a conspiracy theory to me. --Izno (talk) 16:41, 1 August 2018 (UTC)
Izno, currently if the WMF wants to war against a consensus Javascript edit, they have to threaten to revoke any and all admins who would follow consensus. Revoking admins would be a shitstorm. With this change they could be far more tempted to revoke *just* the interface permission, hoping to get away with a smaller backlash. Note: Even if this is a misguided conspiracy theory, if the WMF would never use this new page-protection to win an edit dispute by force, it costs them nothing to give strong assurances that they won't use it this way. Alsee (talk) 18:10, 1 August 2018 (UTC)
At what level does an organization get to refuse to address misguided conspiracy theories? Do we need the WMF to give strong assurances that they aren't being run by Lizard People too? --Ahecht (TALK PAGE) 18:21, 1 August 2018 (UTC)
It would also cost them nothing to say one thing and then do something else. There would be no precedent for the WMF to remove interface-admins on a wiki (they can remove CUs because they govern access to non-public info), and even if they did, stewards and global-interface-admins would still be able to implement changes requested by the community. This isn't an area of WMF control, and superprotect is a thing of the past. The comments about superprotect above were, ironically, probably intended to recognize this potential concern from the community.
And a little note on being a WMF sympathizer: I find that the further up you go on the community "hierarchy" for lack of a better term, the more your view on the WMF changes. Undoubtedly there have been things that they've done wrong in the past, but the WMF exists to support the community - not the other way around. The WMF provides direct support to the steward team, handling cases that we don't have the capacity or scope to, and providing technical support to develop new tools for the community to use and resolve security issues. I know I won't convince any of the WMF-is-evil crowd, but please take a walk outside and ponder how we might not live in a world where one side is totally good and one exists only to torment the other. We're all complex humans trying to work towards the same goal. We will accomplish more by having mature conversations than demanding assurances and taking things out of proportion, like I think this discussion is doing. -- Ajraddatz (talk) 18:22, 1 August 2018 (UTC)
I never said that the WMF is evil, or that it exists only to torment the community, and I do not believe those things. However, it is uncontrovertible that some senior staffers have acted disingenuously with regard to past deployments, and that community JS interventions were and remain an important check and balance on WMF technical power. Therefore the community should be careful to retain a good number of users able and willing to implement such interventions. Also, as I noted, "sympathisers" is a poor phrase; but I would not want to end up in a situation where all or most of the interface admins have links with the WMF strong enough to prevent them implementing a community intervention or to induce them to actively prevent such. BethNaught (talk) 18:52, 1 August 2018 (UTC)
Yes, there have been negative actions from them in the past. I would argue that office actions have not and would not be used in that way. First of all, WMF-mandated removal of advanced permissions requires approval right up the WMF chain of command, so it's unlikely that an office action could be done quickly enough to remove community control or be done by a few rogue agents trying to implement technical control. Second, all office actions as they relate to permissions removal are overseen by stewards (and I assume local arbcoms too), in that we are informed of the rationale for them and when they will occur. Of course, it's possible for the WMF to ignore all existing processes if they wanted to restrict community control, but if they really wanted to then they just would. They have no need to go through back channels like this, when they have complete control of the servers and could just mandate that change whenever they wanted to. The point I was trying to make above is that their goal isn't to restrict community control, it's to empower the community. We're on the same side. And until the WMF actually takes action to remove community control, there isn't much need for us to be concerned with it. Because we won't be able to do anything but complain either way. -- Ajraddatz (talk) 19:02, 1 August 2018 (UTC)
Please do not derail this important process with fairy tales about big bad WMF. They don't need an evil new group to do whatever they want. There really is a need to protect the project against the likelihood of an attacker getting access to an admin account in order to spread malware via scripting. Johnuniq (talk) 00:50, 2 August 2018 (UTC)
The WMF did not have the ability to do whatever it wants. Superprotect did not actually prevent admins from editing JS, because the software is built around admins being trusted. Preventing admins from having absolute control over the interface without wrecking the site would require putting in extensive engineering work over a long period of time, which is what they're doing now, ostensibly without the last step of actually removing community control. We're not dealing with "fairy tales"; the WMF has, in the past, unambiguously denied the validity of the community veto over all aspects of the interface. Things have changed since then, but there's no guarantee that it won't change again. Previously, they could not remove community control. Now they can. This matters. --Yair rand (talk) 01:16, 2 August 2018 (UTC)
I'll withold my judgment of the WMF ih this instance. I have more than enough direct experience with them to know that while they may not be evil, their motivations are clearly and provenly not always the best for the projects and/or the volunteer communities who build and maintain them. I'll just repeat my earlier caveat that this CSS/js maintenance has been carried out discretely for years by a small group of reliable users, and the creation of a new user group will cause a stampede of hat collectors if not managed with discretion. Kudpung กุดผึ้ง (talk) 01:29, 2 August 2018 (UTC)
WMF Paranoia--I'm not a much fan of WMF's approach as to the liaosoning between their devs and the editorial community,which often leads to stupidity,all around.But, it's hardly fair to view everything through the same shades and generate conspiracy theories,at will.∯WBGconverse05:53, 2 August 2018 (UTC)
Proposed access requirements
My suggestion here is to make it an RfA/RfBAG type process, but that's only my thoughts as someone who cares about how user rights are implemented. I'm assuming this would be easier than a list of technical requirements, since people who are interested and care about it will follow the page. Thoughts would be welcome. TonyBallioni (talk) 15:23, 30 July 2018 (UTC)
I agree on not having a particular fixed requirement. I think we should make sure it isn't too bureaucratic/and or too time consuming. Something closer to how EFM/EFMs are given to non-admins seems reasonable to me, where the right is given after 7 days of discussion assuming a demonstrated need and expertise and no significant opposition. Most cases should be uncontroversial so I don't see the need for something as large or bureaucratic as an RfA. Galobtter (pingó mió) 15:33, 30 July 2018 (UTC)
I personally hope there's a whole lot more scrutiny than a BAG application, but yes, some wide community scrutiny should be required. -- zzuuzz(talk)15:40, 30 July 2018 (UTC)
IMO that scrutiny already happened in the RfA - admins are already trusted a lot not to deliberately harm the website (with, even without JS/CSS access, they have significant power to do so), and since the main "bigdeal" of techadmin is deliberate misuse, there should be very little need for any sort of large scrutiny, beyond making sure they have a need and a minimum of ability. Galobtter (pingó mió) 15:48, 30 July 2018 (UTC)
I'm a fan of the RFBAG process for granting access to these rights. Do we want to have different standards for sysops/non-sysops? On Meta we're considering allowing existing admins to pass a request in two days without objection, and everyone else in a week (or an admin in a week if there are objections). -- Ajraddatz (talk) 15:47, 30 July 2018 (UTC)
I think what I was getting at would be a public vetting is needed. I generally think meta has a good process for according these sorts of things, and it might be good to mirror their requirements. TonyBallioni (talk) 15:53, 30 July 2018 (UTC)
Having say a 3 day process if there are no objections seems reasonable to me for sysops. Non-admins should definitely have a different process (if consensus is even there for allowing non-admins to become techadmins..) Galobtter (pingó mió) 15:54, 30 July 2018 (UTC)
I also said upfront that I viewed this as more of an EFM-like thing. Both EFMs and techadmins can basically break an entire wiki so it makes sense for both user-right requests to be reviewed by existing right holders and experienced in the chosen area. As long as both are gated behind "must already be admin" I don't see how a second RFA-like process is helpful. Ben · Salvidrim!✉15:56, 30 July 2018 (UTC)
One of the big problems with introducing a new user right like this is that whether new rights holders are needed or not, people will clamber for it. They always do. Perhaps put a cap on the numbers like they do at CU and OS. I would say a simple request at WP:BN with at least two 'crats agreeing. There's no need to make this a big public RfA-style thing or even like PERM which is also too public.. This kind of editing is not an activity that is often required and the 6 or 7 competent people doing this already can be grandfathered. Otherwise, admins only. Kudpung กุดผึ้ง (talk) 22:07, 30 July 2018 (UTC)
I concur with Kudpung and Salvidrim. Please, we do not need another RfA process. This is a strictly technical user group. The broader community is not going to be able to vet someone's competence in this area. They community does, however, need to be convinced the user can be trusted, and that can be satisfied by the sysop as a requirement. A discussion right here on this page I think is fine, or WP:BN if you think that's better. It should be similar to what we do for WP:EFM at WP:EFN, only with a longer discussion period and stricter requirements. Overall, I stand by my belief that if this "interface admin" user group is a success, there will be very, very few requests for it. Editing MediaWiki JS/CSS is rare. The fewer interface admins, the better (but enough to fulfill protected edit requests, obviously). That's the intent, anyway. — MusikAnimaltalk00:57, 31 July 2018 (UTC)
To put in perspective, in the past year, there have been 485 edits made by 27 users (some are global-interface-editors who are making WMF staff edits). I don't think we need many more interface admins than that. That query does include edits to MediaWiki:Gadget-geonotice-list.js, which are done by some non-techy admins. For the time being they'll have to request changes from interface admins, but at some point we will be able to grab data from JSON pages behind ResourceLoader (phab:T198758), so they will be able to manage central notices on their own. At any rate, I think the volume of edits can be satisfied with maybe 20 or so interface admins, roughly the same number of admins who edit site JS/CSS currently. — MusikAnimaltalk02:04, 31 July 2018 (UTC)
Agree with MusikAnimal. Very few folks need or would even make use of the ability to edit site-wide JS or CSS, so this doesn't need to be onerous. I think we can manage a smooth process with few but important roadblocks; the process for WP:EFM is a good model. A little statement to demonstrate need and ability, I wouldn't say no to two of the three CUOS appointment questions (i.e., Please describe any relevant on-Wiki experience you have for this role. and Please outline, without breaching your personal privacy, what off-Wiki experience or technical expertise you have for this role.). Basically, anything that requires the handful of usuals to wait is a bad process. ~ Amory(u • t • c)01:43, 31 July 2018 (UTC)
Crats - I'm unsure what my non-admin desired process would be, but I think that Kudpung's suggestion of 2 'Crats agreeing is sufficient for any Admins. Probably a 3 day waiting period, rather than just immediately after 2 agree. Nosebagbear (talk)
Expert Opinions - after the initial wave is through, it would probably be logical to ask the interface admins, formally, what their judgement was on new applicants for the rights, since while the 'Crats/Community might determine trustworthiness, we are probably less apt to determine capability. Nosebagbear (talk) 17:04, 3 August 2018 (UTC)
Not sure what to think on this precise issue, but we absolutely must have a local policy saying that you may lose your rights immediately if you revert someone who's enforcing community consensus (barring misclicks, good-faith misunderstandings, etc.), and that if you make such a reversion and lose your rights, someone else may restore your edit without discussion. Given past history, I question whether this is really a matter of good-faith site security: obviously most people here are handling it that way, and that's fine, but we need to have a policy-based reason for removing your rights immediately, like the German Wikipedia did, if you're complicit in another superprotect situation. Nyttend (talk) 11:36, 6 August 2018 (UTC)
Are you really targeting de:Special:Diff/132931713 here? That's the only edit I see there that would really be affected by the policy you propose here. WMF staff could have done their changes in other ways, if they had needed to.
It's a close call, but after carefully considering the arguments, at this time, this right can only be given to admins at this time. Since there was little comments on the venue of such a request, admins may request it at WP:BN as they would a resysop request. Bureaucrats cannot assign this right to themselves and must be granted by another 'crat. Because this was a weakly established consensus. This discussion can be re-opened in 6 months to establish a stronger consensus.—CYBERPOWER(Chat)16:51, 2 September 2018 (UTC)
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 is some disagreement above, so let's ask the question: Should this right be restricted to admins? Some possible models:
Only admins are allowed to be granted the right, either through a selection process or a request to bureaucrats.
Admins and non-admins can be granted the right, but admins go through a reduced selection process because they have already been evaluated on the "trust" angle.
The right is completely separated from admin, and all users must undergo a selection process specific to the right.
I think option 2 makes the most sense myself. We have the potential to open these rights up to non-admins, as with EFM, and I think we should take that opportunity. At the same time, existing admins can be trusted with access to the right, but their technical competence in the area hasn't necessarily been evaluated. -- Ajraddatz (talk) 16:06, 30 July 2018 (UTC)
Thinking more about option 2: it's worth noting that at least three non-admins have contributed to .css and .js pages through membership in the global interface editors group. It was originally my thought that there may be some local users who could help out in this area, but who aren't admins and wouldn't want to be added to the global group. However, there still remains very little ongoing need to modify the css.js files, and with an RfA-like selection process there may be limited interest in non-admins applying for a permission that they would only use once or twice a year on average. Demonstrating a "need" for the permission would likewise be difficult. For simplicity's sake, I could support option 1 with a request to bureaucrats and a small holding period (48 - 74 hours), and maybe expanding to option 2 with later consensus if there are interested non-admins. -- Ajraddatz (talk) 15:43, 31 July 2018 (UTC)
Sort of the point I made elsewhere, but I there's a difference between "are there non-sysop users who could be helpful with interfaceadmin?" and "should this right be restricted to admins?" The former is certainly true, but it's orthogonal to the second question. I'm sure there will be many users who can be trusted and have the knowledge to be techadmins, but won't. That's okay! As long as we've got enough active editors to maintain the pages and respond reasonably quickly to edit requests, there's no harm. The more people who have this, the greater the security risk. ~ Amory(u • t • c)16:24, 31 July 2018 (UTC)
Fair point; non-admins can always request changes on relevant talk pages, and given how few of these requests there are it shouldn't be a burden on either the requestee or the actioner. I am thinking of this in terms of engaging volunteers, but the security argument is probably a better one to be using here. -- Ajraddatz (talk) 17:03, 31 July 2018 (UTC)
No opinion on non-admins, but for admins, I think a request at BN subject to a 72 hour (or other reasonable period) hold for comments makes sense. TonyBallioni (talk) 16:08, 30 July 2018 (UTC)
Per Kudpung above, I’d say support option 1 and like I said above, a simple post at BN with a waiting period to comment should do. I’ll also add this has a huge practical benefit: there seems to be agreement that this should be fairly simple for competent admins who work in this area to get. Having this as the initial requirement would likely get easy consensus without having to create a standard for non-admins. Once this becomes a local policy, we can change it as needed, but getting a policy together before this is implemented is ideal. TonyBallioni (talk) 23:24, 30 July 2018 (UTC)
Support Option 1 for now because I can't think of a situation where a non-admin would ever be granted this, but I'm not necessarily opposed to Option 2 as analoguous to EFM -- not strictly forbidden by policy, but "highly-restricted" (to quote WP:EFM). Ben · Salvidrim!✉16:42, 30 July 2018 (UTC)
Support 3 because the two permissions exist for different reasons and have different purposes. Admin is essentially a social function and a sound understanding of policy and practice are essential. Interface admin prioritizes technical skill and security, a fair difference to admin. Jo-Jo Eumerus (talk, contributions) 20:23, 30 July 2018 (UTC)
Support 2, altho I'm not sure it (or option 3) are technically possible. I could see some technically saavy non-admins wanting to help with things like the spam blacklist. SQLQuery me!21:16, 30 July 2018 (UTC)
Both are technically possible, as the relevant rights will be completely removed from the sysop group come the end of August. We are able to decide who is in the new group and how they are selected. -- Ajraddatz (talk) 21:54, 30 July 2018 (UTC)
Actually "interface admin" let's you edit anywhere in the MediaWiki namespace, so never mind! Now I understand why they changed it from "tech admin" to "interface admin" — MusikAnimaltalk20:28, 31 July 2018 (UTC)
Note however, interface admins can not edit through protection, so if there is a mediawiki page that admins don't want non-admin techadmins to edit they can apply admin protection on top of the namesapce protection. — xaosfluxTalk21:36, 31 July 2018 (UTC)
Support 1 because the number of users who have edited these pages is is very small, most of them are admins, and one of the non admins has retired anyway. Grandfather the rest. And there is no hurry.Kudpung กุดผึ้ง (talk) 21:57, 30 July 2018 (UTC)
Support 1 This is the only one that in my opinion makes any sense. Editing site-wide JS/CSS is the most sensitive thing you can do here. All users who are able to do this should also be able (and strongly encouraged) to have two-factor authentication turned on. Allowing non-admins to edit JS/CSS this code, regardless of their experience and trust, is a security risk.— MusikAnimaltalk01:03, 31 July 2018 (UTC)
@MusikAnimal:--Umm....Non-admins can easily request for 2FA at Steward's Noticeboard over Meta:) So, that's hardly a reason to debar competent non-admins from a technical task.∯WBGconverse05:14, 31 July 2018 (UTC)
Yeah and actually, interface editors themselves will surely be able to enable 2FA. It doesn't make sense to allow people to edit site JS/CSS and not secure their account like sysops can (which, in this case, is the less sensitive user group). I still !vote for option 1 because that would reduce bureaucracy -- first having the users be evaluated by the community through a separate process (RfA), which then means the only barrier is demonstrating need and competency, which other interface admins will be able to do. If there were more people who actually edited site JS/CSS, then it would be different. If we have 20-25 interface admins, I suspect we'd be getting by just fine and satisfying the intent here, which is reducing the number of accounts that have this ability. I don't think making protected edit requests is that much of a pain, especially when they will be rare (based on the volume of edits we see now) — MusikAnimaltalk20:39, 31 July 2018 (UTC)
Option 1 No other option is reasonable. RfA is, for better or for worse, our mechanism for establishing a general baseline community-wide trustworthiness. For anyone to justify having techadmin they'd need to meet those requirements. They should. ~ Amory(u • t • c)01:46, 31 July 2018 (UTC)
Support 1 Anyone who edits sidewide javascript could use it to hijack admin accounts and perform admin actions on their behalf (including accessing sensitive deleted content). Any community vetting process would have to be at least as strict as RfA, so at that point it makes more sense to just have them go through RfA. --Ahecht (TALK PAGE) 01:47, 31 July 2018 (UTC)
Support 3 I don't think sysop needs to be a requirement, but there does need to be a strong consensus process for granting the permission. I don't see much need at first glance for a "reduced" process for people who pass RfA after the changeover; while they've already gotten a position of trust, it doesn't seem worth having a special process instead of just allowing the discussion to naturally take trust as assumed (or not). OTOH, we probably should have some sort of grandfathering for existing admins who've already used the ability to edit JS and CSS to bootstrap things. Anomie⚔02:01, 31 July 2018 (UTC)
Option 1 to start with. There may be exceptional circumstances in the future where a non-admin might find this useful, without additionally having to go through an unnecessary RfA. I can't easily imagine such a situation, but I hope we can revisit this topic and implement option 2 through an RfA-style process if it ever happens. -- zzuuzz(talk)06:26, 31 July 2018 (UTC)
Support 1 with crats empowered to grant the bit upon request. Anyone who already went through RFA can be considered trustworthy enough not to do anything bad when they get the right. Current experience shows that this is the case (cf. EFM right). Regards SoWhy07:56, 31 July 2018 (UTC)
Support 2 - With 2 'Crats sufficient to authorise admins. Non-admins need consideration as strenuous as actual admins, but in an extremely narrow field (i.e. more than BAG). WOSlinker makes the correct note that 'Crats obviously shouldn't self-grant.Nosebagbear (talk) 18:23, 31 July 2018 (UTC)
Option 1. Also, bureaucrats should not grant the option to themselves and should go through the process and well and get another bureaucrat to grant them the right if they need it. -- WOSlinker (talk) 21:44, 31 July 2018 (UTC)
Option 3 per Principle of least privilege and Anomie. My concern is not so much malicious admins as it is compromised accounts, we have many admins who by virtue of making one edit a year keep the bit and represent a massive security vulnerability if any of them get compromised due to weak/reused passwords or phishing. Even slightly more active admins could be compromised and request the right before they even know. It seems from the above discussion that css and javascript changes are incredibly rare and so I don't think there's any need to hand this out readily or on an expidited basis to anyone, especially given the harm it could cause (see, for example, Anomie's cryptocurrency mining example below). The fewer people able to access or easily access this bit the better. I like some suggestions above about capping the number of users with the bit, and I think there may be some value in giving a default expiry time for anyone with the bit. I am very wary of this right. Wugapodes[thɔk][ˈkan.ˌʧɻɪbz]22:31, 31 July 2018 (UTC)
Note, if we allow non-admins access it will allow these users to also update mediawiki pages such as the MediaWiki:Titleblacklist, MediaWiki:Spam-blacklist etc - this access can be overridden by admins by apply admin-only protection on top of the namespace protection. General editing guidelines for non-admins in these spaces may need some consideration. — xaosfluxTalk03:24, 2 August 2018 (UTC)
Yeah, that sounds off to me. A more reasonable design would be to make the permission to edit the MediaWiki.css and MediaWiki.js pages a wholly separate permission than the general MediaWiki namespace editing permission. Jo-Jo Eumerus (talk, contributions) 12:15, 3 August 2018 (UTC)
Option 1 is the safe way to proceed. If non-admins would like to do this, they need the trust of the community, and so should undergo RFA prior. There should be some more criteria, other than just a request though. Graeme Bartlett (talk) 08:48, 3 August 2018 (UTC)
Option 1 and/or 3. I think everyone should have to be vetted before they're given this role, even if they're admin. Given the importance of the privileges this role bestows, a community consensus would be better than a few 'crats being unable to find fault (not to say I don't trust them, of course). Cheers, Anarchyte (work | talk)08:56, 3 August 2018 (UTC)
Option 1 for two reasons. The first is that RfA gives a baseline indication of the trust the community has in an editor, to have non-admins able to granted this right, they should IMHO go through an RFA-like process to establish that community trust. As people have said above, we don't need another process like RFA. Secondly, given that an interface admin would be able to edit any MediaWiki page (spam and title blacklists, block reasons) the expectation that they be an admin and have been vetted by the community to make these decisions is important and necessary. Callanecc (talk • contribs • logs) 00:03, 5 August 2018 (UTC)
Support 2 or 3. Interface administrators need to have two qualities: Trust and technical ability. RFA deals with the first of these but not the second, but also includes a lot of focus on things that are irrelevant this role. Thryduulf (talk) 08:17, 5 August 2018 (UTC)
Support option 1, granted upon request, removed fairly quickly if not used? I don't think a process more complicated than "post to WP:BN" (like our resysop process) is necessary for a right that used to be part of "sysop". —Kusma (t·c) 14:22, 5 August 2018 (UTC)
Possibly also immediately grant to all sysops that have ever edited any of the pages affected by the new group, or anything similar. —Kusma (t·c) 14:30, 5 August 2018 (UTC)
2 or 3 - I can think of a plausible set of circumstances where I'd support someone for technical admin, but oppose them for vanilla sysop. There are a number of criteria (civility, Knowledge of protection, knowledge about blocking) that all admins need to There are two criteria for interface adin - trustworthiness and competence. RFA proves the first, and is irrelevant to the second. — Preceding unsigned comment added by Tazerdadog (talk • contribs) 20:17, 5 August 2018 (UTC)
1 as per the section below without admin access: interface admins would not be able to delete pages they make; and non-interface editor admins would not be able to delete them either. Same goes for cleaning / repairing of user css/user js pages. — xaosfluxTalk21:24, 5 August 2018 (UTC)
Option 2 Admins should be expected to establish need, non admins should undergo a very thorough review, and I would expect very few non-admins to get approved. Monty84503:00, 6 August 2018 (UTC)
Support 2 or 3 per Tazerdadog. I don't really think the criteria for admin and interface administrator should be the same. They are significantly different roles. Kaldari (talk) 18:11, 7 August 2018 (UTC)
Oppose 1, support 2 or 3 I don't think that we should make this work contingent upon agreeing to undergo RFA or hold sysop rights. There are competent, trustworthy technical editors whom I'd be happy to see in this role, and who might be willing to do this work (or at least to do it for a specified project), but who have no interest in delete or block buttons. If some editors with both sysop and iadmin rights decided not to bother with sysop stuff any longer, then I'd be sorry to automatically lose their help in this area. While I expect that – similar to ArbCom – nearly every editor with this right will also be a sysop, I would be sorry if it was made a formal requirement. There are a lot of scripts around here, and sometimes a change in MediaWiki requires updating a lot of them at once. This isn't about the design of the Main Page. Think about what would happen if popular gadgets like Twinkle or WikEd or the watchlist formatting gadgets broke (again). Let's make this available to competent, trustworthy editors, even if they don't choose to become normal sysops. WhatamIdoing (talk) 03:57, 8 August 2018 (UTC)
Support 2 or 3. Several posts above note that RfA "gives a baseline indication of the trust the community has in an editor" (to quote Callanecc); I agree with that. However, RfA is a higher bar than just trust: it requires editors to demonstrate interest & competence in some non-technical areas that are irrelevant to the main uses of this permission. I would probably seek intadmin myself to continue the gadget work I'm already doing; requiring RfA would, in my opinion, be an unnecessarily high barrier. I agree strongly with what WhatamIdoing said above, as well. Enterprisey (talk!) 03:52, 9 August 2018 (UTC)
Support Option 2 While administrators already have (but soon will not, due to this new right) the ability to edit site-wide JS/CSS, a non-admin could be trusted with this right. (As mentioned, this is similar to the edit filter manager group, where most, but not all, members are also admins.) SemiHypercube✎21:03, 12 August 2018 (UTC)
Support 2. The tasks expected of administrators and interface administrators are different enough to be placed into separate scopes. With option 2, interested editors are evaluated solely on the privileges they are requesting, which is a model that has been shown to work in WP:PERM. Option 2 also takes into account the need for community trust in both of these roles, and reduces the amount of bureaucracy needed to have the community assess this trust. — Newslingertalk22:27, 12 August 2018 (UTC)
Oppose 1, support 2 or 3. For example, my homewiki is Russian, I don't edit much here. But I'm planning to edit MediaWiki:Gadget-popups.js . Some of my request for edits already accepted, but it would be much easier to be able to edit directly. Alexei Kopylov (talk) 02:51, 31 August 2018 (UTC)
Support 1 It was an admin toolset so keep it in the hands of admin especially with the "high risk scenarios". And for option 2, it's hard to demonstrate the need for them if you are a non-admin and not able to edit those pages in the first place. OhanaUnitedTalk page15:13, 1 September 2018 (UTC)
OhanaUnited, it is possible to demonstrate the need for these tools by acting as the maintainer of various gadgets, and by submitting numerous edit requests to MW-space JS/CSS pages. (Example: me.) Enterprisey (talk!) 02:45, 2 September 2018 (UTC)
I only edited Geonotice which is only for admins to edit (I had a few edits to .js but they were odds and ends). That's what I base my decision on. OhanaUnitedTalk page03:05, 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.
This is a bigger deal than you seem to think
An admin (after the rights change is completed) or an edit filter manager can temporarily break editing on a wiki, possibly add some vandalism or scare away some editors. That's not good, of course. But someone with this right can steal accounts, install bitcoin cryptocurrency mining JS that runs for every page view, install trackers that violate the privacy policy, and so on. That's a lot worse, and is why this rights split is being done by Wikimedia. IMO we probably should have something akin to an RfA process for this right, with two aspects: evaluate the trust that they won't do the above kind of stuff, and evaluate the technical skill of the applicant that they actually know what they're doing. The exiting RfA process doesn't generally look for the latter. Anomie⚔02:03, 31 July 2018 (UTC)
And there should be a demonstrated need: the person has either done it before or can show what they would do if granted the right. Johnuniq (talk) 05:50, 31 July 2018 (UTC)
Is the bitcoin mining thing actually a concern? I'm pretty sure that the commercial value of dumping a full-screen ad on the main page (or all articles via widely-used template or interface message) dwarfs that of having JS mining cryptocurrency. --Yair rand (talk) 06:40, 31 July 2018 (UTC)
The issue is that a rogue or compromised account could install JavaScript that would be executed by almost every person visiting or editing Wikipedia. One of the least damaging results might be that computers belonging to readers and editors run more slowly because they are running mining software. There are a lot worse things that could result from malicious script. There is also the possibility of an interface admin being coerced into handing over their password. I believe there was a case where that happened: reminder anyone? Johnuniq (talk) 07:18, 31 July 2018 (UTC)
A full-page ad would be a lot more obvious to end users and get removed more quickly than something subtle like a mining script. --Ahecht (TALK PAGE) 13:33, 31 July 2018 (UTC)
Part of why I think this is a bigger deal than WP:EFM is that while EFM can affect a large number of edits, it principally only affects the encyclopedia. Abuse of the edit filter can cause quite a mess, to be sure, but it is one that we can fix ourselves. However site-wide javascript is code executed by a reader's computer and a malicious/compromised TechAdmin account can use known (or currently unknown) javascript exploits to install malware on readers computers without their consent or use Wikipedia to create a botnet. For example, since 2016 we've known of a ransomware application written in 100% javascript: IT Pro Portal. If compromised javascript infects a user's machine, we cannot fix that by reverting like we can most admin and edit filter abuse. A reader's files can be encrypted and lost or be forced to pay money to retrieve them, their financial passwords can be taken, corporate or governmental intranets broken into, the list of dangers of toying with client side code goes on and on. This poses a serious security threat beyond the encyclopedia, and is far weightier than EFM or even most admin tools. We should take a lesson from Facebook's ongoing data breach fallout before we disregard the potential issues of this beyond whether we trust the bit holder or not. Wugapodes[thɔk][ˈkan.ˌʧɻɪbz]23:15, 31 July 2018 (UTC)
Technical skill
I would just like to point out that not all regular edits to MediaWiki:***.js actually need any knowledge of javascript. Updating of geonotices being a good example. -- KTC (talk) 08:18, 6 August 2018 (UTC)
That will eventually be moved to JSON pages, which they non-interface admins will be able to edit. See phab:T198758. Any other JS pages that only involve simple key/value pairs should follow suit. For the time being, handing out interface admin rights to some of these people is probably okay, but not in the long-term. — MusikAnimaltalk18:55, 7 August 2018 (UTC)
A simple proposal
The ability to edit site-wide CSS/Javascript or help individual users with it is one that has historically been entrusted to administrators. I haven't often used it, but I have in a couple cases to help users who had borked Javascript in their personal .js files. So, how about a simple proposal:
Any administrator may request access to this user group, and absent reasonable objection or suspicion of account compromise, will be granted it. We've been able to do it for years, and I really don't know of any instance of an admin doing something malicious with it. If we can't trust even our admins to not do something harmful to the project, we may as well pack it in and go home right now.
Any non-admin wanting access to the group must be carefully vetted. Generally speaking, such access should require an RfA-like level of trust, because of the implications of having access to such a powerful interface. I would generally want to see someone with such access show community trust at RfA. It isn't like template editor, this right is even more powerful and even more dangerous. There may be a rare circumstance in which a non-admin would have such permissions, but such an instance should be very much an exception.
Comment I'd like to support this, as it makes sense to me. I really do not see the need for an RFA-type process, as most users are not qualified to judge the technical requirements. That said, two points hold me back: if the approval process is lightweight, we should have a similarly quick removal process; and IAdmins should be required to have 2FA enabled. Vanamonde (talk) 05:18, 5 August 2018 (UTC)
There have been several recent instances of an attacker managing to compromise an admin account and using the ability to edit site JS to expand their access. Giving the new group to every admin ("suspicion of account compromise" seems pointless since that should result in emergency desysop anyway) on request would defeat the purpose, which is to reduce the attack surface by only giving the right to people who actually use it. Anomie⚔13:09, 5 August 2018 (UTC)
Oppose +1 to Anomie. This proposal is fine in theory but it would defeat the purpose. We've discussed this above, but I'll toss in my thoughts here, too: I really don't know of any instance of an admin doing something malicious with it It has happened and it can happen again. So, we are trying to reduce the number of accounts (attack surface) for which it can happen. The admins who actually edit site JS/CSS are few and far between, so if this is handed out as intended, most admins will go their entire wiki career without noticing they don't have this ability. If we can't trust even our admins to not do something harmful to the project Indeed, most admins will never do intentional wrong. But many have poor account security, and rare as it may be, an admin gone rogue can't really cause permanent far-reaching damage, except through JS/CSS. Any non-admin wanting access This is what #Sysop as requirement is about. You may wish to !vote there accordingly. Kind regards — MusikAnimaltalk17:07, 5 August 2018 (UTC)
Support, absent reasonable objection or suspicion of account compromise indicates a vetting process, just one done at WP:BN. I see no reason to assume that having a second RfA will result in a more useful process. However, I see zero reasons to admit non-admins to this group, and everybody trustworthy enough to be in this group should be given +sysop. —Kusma (t·c) 14:05, 6 August 2018 (UTC)
Oppose the non-admins portion at this time as it creates a situation where they can create pages that normal admins can't delete, and they can also not delete. — xaosfluxTalk14:12, 6 August 2018 (UTC)
Not sure that's a huge concern. Global interface editors can do this already, and there are a few of them active here over the years. So this is already a "problem", but obviously it hasn't been an actual problem over the years. The only concern would be if we only had non-admin intadmins, because then there would be no local users who could delete. -- Ajraddatz (talk) 16:51, 8 August 2018 (UTC)
@Ajraddatz: not huge, just don't think its a good idea. GIE's can not currently create pages that our admins can't delete (please provide an example if I'm missing something). — xaosfluxTalk00:25, 9 August 2018 (UTC)
Overall / Per-admin stats
It took a little while (and a lot of tinkering) to generate - but I've come up on stats based on actual use for js/css including outside-of-the-admin's-own-userspace (which I don't think I've seen anyone present to date: User:SQL/Admin_CSS-JS_Editing. One thing that can inflate stats a bit is going to be renames. SQLQuery me!00:47, 6 August 2018 (UTC)
What do the numbers look like for the past year/three years of edits? RHaworth, for example, has one edit in general userspace outside his user space to a JS/CSS page (that's User:Cyberpower678/RunI.js) within the past year or two. --Izno (talk) 00:57, 6 August 2018 (UTC)
Soooo, MusikAnimal points out - I wasn't grabbing edits, but **pages edited** due to a distinct from single-user testing making it thru. Once the current run is done, I can have it do those too. SQLQuery me!01:03, 6 August 2018 (UTC)
Permissions question about dealing with inappropriate user JS/CSS
Will regular administrators still have the ability to modify/delete individual users' JS/CSS pages? We had some problems at MfD a couple months ago where a couple of users had copy/pasted copyrighted code into their personal JS pages (or were using their personal JS pages to webhost JS code they were retaining copyrights over; it was unclear which), and I'm slightly concerned that if only a dozen or so people can delete pages like that, it might become difficult to deal with them. I'm concerned this might develop into a similar situation to the edit filter managers, where I need to ping specific EFMs to false positive reports requiring their attention because none of them ever bother to check the page, and legitimate false positives just went unaddressed. —Compassionate727(T·C)17:00, 4 August 2018 (UTC)
Wait, really? In general? When did that happen? I distinctly recall during the superprotect crisis that admins were still able to delete Common.js even after it being superprotected, which incidentally also would remove protection, because there's never been a thing about practically restraining admins. If the devs specifically changed this also, and the interface admin business is part of a broader set of changes about setting up effective restraints against what admins can do, this is starting to sound a lot more dangerous. --Yair rand (talk) 17:38, 5 August 2018 (UTC)
That happened in August 2014 when it was noticed that someone with permission to delete and undelete a page but not to edit or unprotect it could "unprotect" the page by deleting and then undeleting it. Wikimedia wikis don't generally have any groups that can delete but not edit (although the "eliminator" group on jawiki, ptwiki, urwiki, and viwiki might), but other non-Wikimedia wikis might have more hierarchical levels of protection. Anomie⚔21:53, 5 August 2018 (UTC)
Left several questions on the phab ticket, including a possible bigger problem for oversighters and global renamers.. — xaosfluxTalk19:50, 5 August 2018 (UTC)
The global renaming ones don't need to be tested, since it's built in already. I can test the sysop and oversight ones though. -- Ajraddatz (talk) 20:26, 5 August 2018 (UTC)
Done testing. It is not currently possible for a user with the delete permission to delete a CSS or JS page without also holding editsitecss and editsitejs respectively. The page also cannot be suppressed by a user without the appropriate editing permissions. I didn't test revision deletion. -- Ajraddatz (talk) 20:35, 5 August 2018 (UTC)
I can confirm I cannot delete pages I cannot edit: 07:08, 4 August 2018 Cynko (talk | contribs | block) protected Arturo Vidal [Edit=Dozwolone tylko dla redaktorów] (expires 07:08, 7 August 2018) [Move=Dozwolone tylko dla redaktorów] (expires 07:08, 7 August 2018) (do czasu ewentualnej zmiany klubu) (hist | change) (thank) - stewards don't have that edit permissions and I don't see delete buttons unlike this page. — regards, Revi06:33, 6 August 2018 (UTC)
That's weird. The 'protect' permission is supposed to give access to all subordinate protection levels. They must have accidentally set up their own superprotect when they requested the config change. -- Ajraddatz (talk) 07:15, 6 August 2018 (UTC)
It's not weird at all. The 'protect' userright has never given access to all "subordinate" protection levels as far as I know (it might have worked that way in 2005, I haven't looked). For that matter, MediaWiki doesn't even have a concept of "subordinate" protection levels.
Here's how it actually works: Each protection level is a separate userright. If you have that right, you have the ability to edit pages protected with that right. If you also have the 'protect' right, you can apply and remove protection for any protection level for which you have the corresponding userright. Anomie⚔14:00, 6 August 2018 (UTC)
You don't seem to have actually asked a question here. But in general, membership in the new group will be required to edit another user's JS or CSS subpages. Anomie⚔14:00, 6 August 2018 (UTC)
Well, that will be no longer possible but whatever 'help' a user needs on their CSS/JS page, the new Interface administrators will provide that. This is simple, unless if I didn't understand what you mean even after you changed it to question. –Ammarpad (talk) 07:19, 10 August 2018 (UTC)
Help could also be provided by regular admins, or indeed any competent editor, who can instruct the user who asks for help as to how to edit their CSS/JS page to fix an issue. WJBscribe(talk)10:21, 10 August 2018 (UTC)
Someone else could probably walk them through turning off JS (via extension or browser preferences), and then from there blanking their common.js. I'm also writing a tool to allow nontechnical users to manage their JS files, and it would be pretty easy to add an option to blank their common.js as well. Enterprisey (talk!) 02:40, 15 August 2018 (UTC)
Since we're limited on time, I've adapted Xaosflux's proposal with my addendum as suggested above (i.e. we don't make people go through this every 60 days.) The community would be free to change this as needed, but this will at least get us to a policy for the 'crats. The proposal being discussed is this version of the page. TonyBallioni (talk) 13:19, 13 August 2018 (UTC)
Comment with this "temporary" measure assuming it will be replaced with a better proposal, I'd like to see an expiration kept - maybe 6 months? I think the stable implementation should be indefinite though. As for the temporary solution: if gaining access is tied to current sysop, removal should include "Upon removal of administrator access for any reason". This may change in the stable release if these are uncoupled. — xaosfluxTalk13:26, 13 August 2018 (UTC)
and if any two administrators object, the request will be declined. is inappropriate. Either make it community members or loosen the objection requirement to straight "bureaucrat discretion" or similar. --Izno (talk) 15:45, 13 August 2018 (UTC)
Just to be clear, I oppose that section as written and would oppose any attempt to make that the policy/guideline. --Izno (talk) 15:36, 15 August 2018 (UTC)
Comment - the proposal should also oblige (rather than prefer) any admin granted the rights to enable 2FA. Since this whole shebang is to increase security, it makes sense that those given the rights take security of their accounts seriously. This is not an endorsement of the rest of the proposal, I need to think on that. Nosebagbear (talk) 20:45, 13 August 2018 (UTC)
I don't think we can require 2FA, technically. But "...preferably using two-factor authentication" as the policy page currently is written, is surely an understatement. The interface admins will be publicly identifiable at Special:ListUsers, and these will be the accounts that are targeted. — MusikAnimaltalk01:09, 15 August 2018 (UTC)
Oppose Requiring some sort of "demonstrated need" would be nice. Otherwise you'll get admins who just want another hat (yes it happens), because this one seemingly is easy to get. They'll apply, we all concur they can be trusted. Great, they can be trusted, but the attack surface is still that much larger. If they don't edit JS/CSS currently, and don't exemplify some necessity for it moving forward, they can get by with consulting existing interface admins as needed. "Just asking" for the rights doesn't seem appropriate if you wish to be consistent with why this user group is being introduced. I for one don't want to have to monitor WP:BN. Franky I think requests should happen right here on this page, where JS/CSS people and existing interface admins can assess. I understand we want to get some policy out the door, but filling up all the interface admin roles with people who won't use it isn't the answer. If you hand out the user group to people who would use it, currently, then we'll have enough interface admins to handle requests, and give us more time to refine the policy around it. — MusikAnimaltalk00:27, 15 August 2018 (UTC)
I'll remind you again that interface admin is above checkuser, oversight, etc. One day of consultation doesn't seem like enough — MusikAnimaltalk00:29, 15 August 2018 (UTC)
@MusikAnimal: I don't see interface admin being "above checkuser". Sure, if a bad guy has interface admin and introduces the right malicious code in the right places, they could possibly escalate their privileges. But to say "interface admin is above checkuser, oversight, etc." actually means that you say currently "admin is above checkuser, oversight, etc." because admins hold all of the rights interface admins are supposed to hold in the future. Please refrain from unnecessary hyperbole. —Kusma (t·c) 09:56, 15 August 2018 (UTC)
That is correct, admins can currently do more damage than a checkuser or oversighter. This has already proven itself. It's a loophole that was known but not given enough attention until recently. I don't think it's a hyperbole, rather we have just been lucky that enwiki has not fallen victim.
Support. Once the technical feature is introduced, we need some policy to deal with it, and we could just try this and see if it works. I don't actually see how any process will come to substantially better results than "be an admin, say why you can be an interface admin and ask nicely". If we turn this into a vote, should I oppose everyone who I think shouldn't have oversight rights?? —Kusma (t·c) 09:59, 15 August 2018 (UTC)
Oppose right now the process for getting rights is too short. I would suggest a 1 or 2 week waiting period after which the user is granted the right at bureaucrat's discretion, as well as emailing the user so they have time to react if their account was compromised and a hacker made the request. --Danski454 (talk) 15:46, 15 August 2018 (UTC)
Oppose, for a few reasons: this page would be better than BN, requests should be open for at least a week, admins shouldn't be the only people who can object, and we shouldn't be rejecting requests based on the number of people who object - rather it should be on the strength of the arguments given. I think the uncontroversial list idea is slightly better. Enterprisey (talk!) 04:01, 17 August 2018 (UTC)
I'd rather see requests either on RFx or BN, or even possibly PERM then here, it really depends on what the "discussion" / "vote" / whatever process will be. — xaosfluxTalk14:27, 19 August 2018 (UTC)
I wouldn't favor using this page, I don't think it'd get enough eyes. Likewise with PERM, which is also a place for sysops to grant requests for permissions. A RfIA page might get enough eyes, but after the first flurry likely wouldn't be used much. BN makes the most sense to me — it's bureaucrat related, has plenty of eyes, and won't go stale. What's your aversion to it? ~ Amory(u • t • c)21:17, 19 August 2018 (UTC)
BN doesn't naturally seem to me like the place for discussions for adding permissions. It does host discussions generally related to permissions (i.e. mop renewals/removals), but no new requests for permissions. Both of the two similar user groups (EFM & BAG) have discussions on their own pages as well. If we wish to benefit from BN's watchers, we can always put a notice on BN for new discussions whenever they start. Enterprisey (talk!) 19:07, 20 August 2018 (UTC)
That's reasonable. I had thought BN could absorb it, but perhaps we should create Wikipedia:Interface Administrators' noticeboard where 1. requests and hearings for the perm could be made and 2. folks could request edits by IAs. The latter seems decentralized, as those discussions should happen on the talk pages of the relevant page (and we'll likely have a edit request template/category), but I suppose it'd still be useful in the absence of those posts. Another thought (which I don't agree with) is that if the "declined if 2 sysops oppose" thing is implemented, then WP:AN would be an option (repeat: this is a bad idea). ~ Amory(u • t • c)19:17, 20 August 2018 (UTC)
I also like the noticeboard idea, for the reasons stated above. I see this as tantamount to WP:EFN, which is a venue to seek help regarding filter implementation, express concerns on filters, and request related user rights (requesting filters is actually done at WP:EF/R, but that has a high volume of requests unlike what'd we see for site JS/CSS). WT:EF meanwhile is for modifications/concerns with the guideline. The interface admin noticeboard and this talk page could serve a similar purpose. — MusikAnimaltalk21:31, 20 August 2018 (UTC)
Note to closer since this was proposed, the page has been edited in ways that change the meaning of the policy. If this is accepted, changes since then would need to be merged with the proposal, provided they do not change its meaning. --Danski454 (talk) 21:37, 21 August 2018 (UTC)
Weak oppose: I think this is OK as a stopgap if we have literally nothing else, but it's not a good permanent solution. The two-admin veto and 24-hour discussion are both undesirably small amounts, and it does literally nothing to select against needless "hat collection" or for, uh, competence. I would weakly support this if it were framed explicitly as a temporary measure, with a reconfirmation or something for extant IA permissions once we settle on something better. {{Nihiltres |talk |edits}}21:35, 24 August 2018 (UTC)
I have removed the RfC template that was added to the top of this section, as it's fairly clear there's no consensus to implement this version of the proposal. It's not clear to me whether the rfc template was meant to encompass just this proposal or any of the alternative proposals submitted below. I would hold off on a formal RfC until the main Wikipedia:Interface administrators is workshopped into something that we like. Enterprisey's proposal below (#Yet another proposed granting process) seems like the most promising solution so far. Mz7 (talk) 07:23, 25 August 2018 (UTC)
Yep, I agree with that. I left some holes in the proposal below, and we can resolve them in a discussion that'll be tagged with the RfC template. In particular, three questions have yet to be conclusively settled: who's allowed to have the right, where requests are made, and who can comment on requests. The first is being discussed above, where the "keep it to admins"/Option 1 camp have a slight lead, and I don't think we need to have another discussion on it. The second can be debated at a later time. As for the third, I put it in there (even though not too many people mention it on this page) because I thought people may want to discuss it. After someone closes the "Sysop as requirement" discussion and my "Yet another..." proposal, we can start talking about the remaining couple of questions (after a possible break so people don't get sick of talking on here?) and hopefully after that we'll have a complete granting process. Enterprisey (talk!) 07:33, 25 August 2018 (UTC)
Would it be possible to come up with an uncontroversial list of say 10-20 users who do this work already who can be given access in the first instance? Or we could do it on the basis of giving access to everyone who already has more than X edits to pages that will require interface admin going forwards? WJBscribe(talk)14:46, 15 August 2018 (UTC)
And also this has no impact on editing your OWN js/css pages that appear to be included in that other dump. Also for users editing their own alt account's js/css pages (e.g. bot accounts); they can just log on as those accounts. — xaosfluxTalk15:28, 15 August 2018 (UTC)
Let's get accurate stats then. No one has provided actual stats which take into account: editors of Mediawiki, editors of Mediawiki JS/CSS, editors of non-personal-userspace JS/CSS (excluding renames). SQL's is what we have for the last bucket. --Izno (talk) 15:40, 15 August 2018 (UTC)
Having just talked to another user on this, I think it’s worth pointing out that even if we had as lax a criteria as “Any admin gets it automatically upon request” we likely wouldn’t be looking at more than 20 users, including hat collectors who wouldn’t use it. That’s a more than 98% reduction from the current system. I get the security concerns (or rather, I don’t but I understand they are very significant) but getting a policy in place that results in an over 90% reduction in this risk can’t be classified as anything but good. I don’t really care what that policy is, I won’t be using this, but I do care that we have something. TonyBallioni (talk) 15:50, 15 August 2018 (UTC)
Ocaasi hasn't edited in three months, which (by a couple of editors above me, with whom I agree) would already count as inactive.
Ragesoss & Ocaasi, as far as I can see, only edit configuration files (in particular Guided Tour files), which are practically JSON anyway. Moreover, Ocaasi made most of his edits to those files in 2013. I'm not saying these two editors should definitely not get intadmin, since we don't have a strong consensus on requirements for granting yet - but maybe not in the first "wave".
There'sNoTime has made edits to three MW JS pages, two of which were single edits because a Teahouse page was moved. The other was a Guided Tour config page, to which 22 edits were made. Same comments as for Ragesoss & Ocaasi.
Important note: I'm not saying anything about the JS abilities of the latter three editors - I just wrote my observations about their MW-space edits. In particular, There'sNoTime has written a number of offwiki tools that probably indicate a high level of JS ability. Enterprisey (talk!) 19:28, 20 August 2018 (UTC)
I think it'd be worth outright asking for self-nominations for the initial list, and to actively prompt all active administrators who have edits to pages with titles matching the regex ^MediaWiki:.*\.(j|cs)s$ to apply. I'm biased: assuming I'm not part of this notional initial group, I will apply for the permission. :) {{Nihiltres |talk |edits}}21:57, 20 August 2018 (UTC)
Just to note, my retirement has only ever been a "soft" retirement - while my editing rate has been significantly reduced compared to when I was active, I've never actually stopped editing altogether, I've just moved the focus of my editing to other wikis. I can understand if this is still enough to disqualify me, though. 「ディノ奴千？！」? · ☎ Dinoguy100017:43, 21 August 2018 (UTC)
I would support giving this right to TheDJ, MusikAnimal, MSGJ, Xaosflux, Mr. Stradivarius and Amorymeltzer as an interim measure. However, it's worth bearing in mind that these are volunteers, and it would be incumbent on the community to sort out the situation quickly so that these users don't feel any additional pressure. (Although such additional pressure is likely to be minimal, given the status quo already sees these users updating most of our CSS and JS.) — This, that and the other (talk)02:44, 21 August 2018 (UTC)
Discussion proceeds for a week, and is closed by a crat who evaluates the consensus, if one exists.
Users who apply are encouraged to answer two questions: "Please describe any relevant on-Wiki experience you have for this role" and "Please outline, without breaching your personal privacy, any off-Wiki experience or technical expertise you may have for this role".
Community notices will be posted to relevant noticeboards, including AN and VPT.
This proposal says nothing about whether only admins are allowed to make requests, whether only intadmins/sysops can participate in the discussion, or where we talk about this; we can decide those questions later. It's similar to the EFM process, taking some ideas from previous posts on this page (in particular Amory's proposed questions from CUOS). Enterprisey (talk!) 04:06, 21 August 2018 (UTC)
Amorymeltzer has created the (blank) noticeboard. Looking at this from the POV of the folks who will end up with this user right, I suspect that they would be perfectly happy to have it redirected to WP:VPT. "Please get this right, do this work – oh, and you won't mind if we sometimes post technical requests at VPT, and sometimes at this new noticeboard, will you?" doesn't sound like quite as attractive an offer as we could make. WhatamIdoing (talk) 15:38, 21 August 2018 (UTC)
WhatamIdoing, I think it's mostly about signal-to-noise ratio: if I become an intadmin, probably a low percentage of village-pump posts will be interesting to me; by contrast, I'll definitely read everything in the new noticeboard. Enterprisey (talk!) 18:14, 21 August 2018 (UTC)
Per the above, ideally all requests for edits would be discussed on the respective talkpages, as is done now. A centralized board could be used to discuss the granting of the permission, in particular by other intadmins, as well as some broader discussion and coordination about edits, such as more complex or wide-ranging or temporary edits (might've made transitioning to templatestyles smother?) or for broader input on more complicated measures. Presumably, all of these would be fairly uncommon. ~ Amory(u • t • c)19:00, 21 August 2018 (UTC)
My guess is that the main candidates for this are already reading VPT, and that most requests for edits will naturally appear at VPT or on the relevant talk page. So I think that creating a special board will spread the discussions out (three "correct" places, rather than the current two), without saving them any effort. WhatamIdoing (talk) 19:47, 21 August 2018 (UTC)
Minor Tweak - "Please outline, without breaching your personal privacy, what off-Wiki experience or technical expertise you have for this role" should be tweaked to "what, if any," - It's perfectly possible that someone would satisfy the requirements without off-Wiki experience (or at least, any they'd want to mention) so the question shouldn't be phrased in a sense that either assumes they would, or implies they should. I'm positive that this wasn't intended, but I feel it is how it reads. Nosebagbear (talk) 18:20, 21 August 2018 (UTC)
+1, with Nosebagbear's suggested tweak or just "...privacy, any off-Wiki..." I'd also say "encouraged to answer" rather than "allowed to answer" but YMMV. A week seems overlong, but I was concerned about eyeballs elsewhere, so I don't think I can nitpick it both ways. ~ Amory(u • t • c)19:00, 21 August 2018 (UTC)
With this being "more dangerous then ....(everything?)" I think whatever the request venue, a community notice of the discussion should be posted to to at least WP:AN. — xaosfluxTalk19:02, 21 August 2018 (UTC)
Weak support I think this is a better place to start than the previous proposal, but I think it may be a tad heavy handed. I would like anyone to be able to comment (not just flavors of admin) but I do not want this to turn into an RFA clone. This is a better stop gap, but my ideal would be something in between the two proposals so far. Wugapodes[thɔk][ˈkan.ˌʧɻɪbz]22:39, 21 August 2018 (UTC)
Wugapodes, I appreciate the comment. Do you think it would help if we suggested, to any editors commenting on each request, that they keep their comments limited to the candidate's level of trust and their technical ability? Enterprisey (talk!) 07:04, 22 August 2018 (UTC)
Well, that's a valid concern. It's very likely related to who we allow to request the permission: if it's going to be admins only, we probably won't have all the same discussion again, whereas if we allow non-admins to apply, trust questions will start being asked.
Regardless, as I said to Wugapodes above, limiting the scope of comments in the discussion is one possible solution to this. I'm not completely convinced that "turning into RfA" is an unavoidable problem with the current proposal. Enterprisey (talk!) 07:12, 22 August 2018 (UTC)
Clone Thoughts - so I'd actively suggest it isn't watchlist notified, which brings everyone and their goat. I think it could work if comments are limited to literally two things (as mooted by Enterprisey): Trust and technical ability. If all other !votes were not considered when judging consensus, I think it will keep it reasonably well on track. — Preceding unsigned comment added by Nosebagbear (talk • contribs) 08:49, 22 August 2018 (UTC)
Thought bubble: The noticeboard could be WP:AN where there are plenty of admins who would rein in disruptive commentary, if only because they wouldn't want a lot of crap on that page. Johnuniq (talk) 09:26, 22 August 2018 (UTC)
VPT should be enough for the noms and discussions for intadmin, I guess... Otherwise LGTM, +1. — regards, Revi11:07, 22 August 2018 (UTC)
I would really rather WP:AN not be the location for discussion, the tone of discussion (including from the admins) is rather more curt and lacking AGF then I think is beneficial. VPT seems a better option. Nosebagbear (talk) 13:12, 22 August 2018 (UTC)
Support—this seems sensible. I'd suggest lumping in the requests with RfAs/RfBs (i.e. our existing system for "advanced" permissions), but really, the colour of the shed doesn't matter much. {{Nihiltres |talk |edits}}21:43, 24 August 2018 (UTC)
Support, without the consensus of bureaucrats language below. This really shouldn't be a big deal - just "are they likely not to break the encyclopedia". --SarekOfVulcan (talk)17:25, 30 August 2018 (UTC)
*Longer Access Wait - Given the delay in getting all those interested into the most important discussion, coupled with the paucity of people who could tell us if the person was technically qualified I would suggest a minimum wait of 48 hours before a 'Crat can close and judge. Nosebagbear (talk) 21:07, 30 August 2018 (UTC)
Nosebagbear, Enterprisey's proposal states Discussion proceeds for a week, and is closed by a crat who evaluates the consensus, if one exists. Unless I'm misunderstanding something, your proposed 48-hour wait is actually a shorter time frame than the one proposed. Mz7 (talk) 23:12, 30 August 2018 (UTC)
Too many proposals! - sorry, was commenting on the proposal that is currently on the project page (which wants 24 hours) - 1 week is fine by me, I don't want it shorter! Nosebagbear (talk) 11:00, 31 August 2018 (UTC)
Support - I'm sufficiently happy with Enterprisey's proposal. It's rare enough to use that I suspect it would be handled fairly carefully anyway. Nosebagbear (talk) 11:00, 31 August 2018 (UTC)
"Consensus of bureaucrats" amendment
I think the above may lead to another RfA-like process, which I think should be avoided at all cost considering how broken it became. How about this? As above ("Yet another proposed granting process") but instead of:
Discussion proceeds for a week, and is closed by a crat who evaluates the consensus, if one exists.
we replace it with:
A consensus of bureaucrats will decide if a candidate is successful . Non-bureaucrats will be allowed a week (or some other time period) to make comments that may be helpful to the bureaucrats, but will not take part in the actual decision.
The decision making of the bureaucrats would be similar to present day 'crat chats, but instead of assessing consensus of other editors they will be entrusted with making their own decision. Non-'crats would only allowed to make comments on the candidate without actually !voting.
I feel this is preferable in avoiding all the "assume bad faith" and wiki-drama that seems to be attached to RfX-like processes. Also bureaucrats are highly trusted users who are probably under-used, and could be trusted with the decision without the need to go down the RfX-like route. Since 'crats are only ones who could grant/remove this permission, it makes sense to make them the ones to decide who gets the permission. Any comments on this? --Jules(Mrjulesd)18:42, 25 August 2018 (UTC)
I have enough qualms about the crat chat process - I don't think it adds any value to have a bunch of random people who were elected a decade ago get together and vote on whether the nebulous concept of consensus exists in a discussion without any defined criteria for what would constitute a consensus in that situation. Permanently adding that to all requests for intadmin doesn't seem like a good idea to me. -- Ajraddatz (talk) 19:11, 25 August 2018 (UTC)
But look at the way RfA has degraded over the years, very few are coming forward to it and even fewer are passing. Another RfX process is very likely to end up the same way. The reason why very few new 'crats are coming forward is very probably connected with the failure of RfX processes on Wikipedia. 'Crats are the only ones who can actually bestow this permission anyway, so they are trusted to this extent. --Jules(Mrjulesd)20:10, 25 August 2018 (UTC)
By nature, we don't want many intadmins. We're doing fine even if we only get one or two new ones per year (or less depending on need). And if the goal of your proposal is to encourage people to come forward, how would the double vote actually do that? -- Ajraddatz (talk) 20:14, 25 August 2018 (UTC)
My concern is that it would still be a vote. There would still be people saying oppose or support, and bureaucrats would still end up counting "comments" when making their decision. RfA here is a broken process, but not everywhere. On projects where RfA is a smaller deal, candidates are still willing to come forward and a proportionally acceptable rate. If we can use an intadmin selection process similar to EFM, then we should be able to avoid the massive stage of RfA and keep things more focused on evaluating useful metrics relevant to the position, and thus not dissuade people from applying. -- Ajraddatz (talk) 21:56, 25 August 2018 (UTC)
Not really a concern. "Opposes" or "Support" comments could be removed. Or else the 'crats could be allowed to ignore such comments.
For precedence, look at how the CheckUser or Oversight permissions are granted. Although all editors are allowed to voice their approval or disapproval, only ArbCom are allowed to !vote on who gains these permissions.
If we allow another RfX process on Wikipedia, it will only be time before it slumps to its last legs (RfA) or dies completely (RfB). --Jules(Mrjulesd)11:19, 26 August 2018 (UTC)
Oppose and I am a 'crat. I think granting of this access should be reviewed and approved by the community at large. I am supportive of giving a discretionary removal-for-cause power to the crats, so long as there is an appeal process. — xaosfluxTalk15:05, 26 August 2018 (UTC)
Userspace pages
The comments about editing script pages in other people's userspace raises an issue that I don't remember hearing about before: it sounds like normal admins can no longer edit other users' .js and .css pages. While not hugely common, it's not particularly rare that we'll have reason to do something with other people's pages, e.g. a user placed a cannot-log-in script (wikibreak enforcer) in his userspace and now he asks us to remove it, or a vandal puts problematic content in a .js page and it has to be deleted, or a user tires of a .js script and asks for it to be deleted. (Remember that you can't delete a page that you can't edit.) Since the general concept of interface administrators was introduced to facilitate site security, and since individuals' userspace script pages are completely different from site interface pages, I suspect that this is an oversight by someone, unless it's merely a misunderstanding by me.
So what is it? Are normal admins no longer able to edit other users' .js and .css pages? Am I just misunderstanding? Nyttend (talk) 01:23, 28 August 2018 (UTC)
You understand correctly. Only interface admins can change userspace Javascript and CSS, by design. You can compromise accounts the same way by targeting a specific user as you can by changing a global Javascript page. --Izno (talk) 01:50, 28 August 2018 (UTC)
(edit conflict)That is correct, sysops will no longer be able to edit other users' .js or .css pages; this was entirely intentional, as being able to execute javascript in someone else's browser is indeed a potential security risk. That being said, following phab:T200176 sysops will be able to delete user js and css pages should the need arise, which should take care of most usecases. Other issues should be rare enough that an intadmin could handle them. ~ Amory(u • t • c)01:54, 28 August 2018 (UTC)
Crazy decision: this is a reasonable idea for site security, but not for individual accounts' security. I trust the six new interface administrators, but I won't want to be them, with everyone else running to them for "help this person create a JS page", and I wouldn't want to be someone trying to set up a JS page for the first time and needing help, because we don't trust ordinary admins to touch a page that can only affect one other user. From a workload perspective, there's no way that any permission should be handed out to such a small group of people, aside from things that are used extremely rarely like editing the site's script pages, or hiding exceptionally bad content, or promoting admins and bots, unless you're talking intermediate stuff like template editor or manually confirmed, whose abilities are all shared with a bigger group. If plenty of people do something appropriately, plenty of users ought to have the ability to assist in that area. Nyttend (talk) 03:25, 28 August 2018 (UTC)
@Nyttend: the ultimate size of the group is yet to be determined - I was the "nominator" (and a recipient) of one of the '6' spots - but specifically asked this to be a very short term stop-gap pending a process getting promoted. As soon as consensus emerges here and a rights policy is enacted it can be expanded, I'd love to see this done within a month. As far wanting to help someone build something, you can always build something at say User:Nyttend/scriptforFoobar.js and they can just copy it in. — xaosfluxTalk03:42, 28 August 2018 (UTC)
I would say progress is being made in a few of those areas. I'm currently writing a tool that allows users to manage their own common.js files without being experienced in JS (so, a checkbox-based interface or something), and also offers the option to wipe their common.js. This would be complementary to the existing ?safemode=1 option discussed in that section I mentioned.
Question: Is the purpose of helping users with their JS/CSS a reason to grant intadmin access to an admin, considering intadmin isn't really needed for that (but is convenient, giving the ability to just make the fix instead of having to instruct the user and copy code around). --Pipetricker (talk) 22:01, 31 August 2018 (UTC)
At least one already-approved intadmin has voiced (on Phabricator) that he wouldn't do the work if he couldn't just do it himself. --Izno (talk) 22:10, 31 August 2018 (UTC)
There was opposition above to creating a separate noticeboard (Jo-Jo Eumerus & WhatamIdoing), so I didn't endorse it in my proposal above. I'm personally all for it, and the numerical consensus is there, I'm guessing, but we may want to discuss this a bit. Enterprisey (talk!) 20:28, 28 August 2018 (UTC)
As far as "where to place nominations"? I'm fairly open on this, and that noticeboard is fine with me, provided that any nominations get a required advertisement someone more watched, I suggest at least WP:AN and WP:VPT. I don't think T:CENT or MediaWiki:Watchlist-messages advertisements are necessary though. — xaosfluxTalk20:34, 28 August 2018 (UTC)
Per above, it hasn't been agreed upon. I made it as a placeholder/conversation starter and I've come around to it. What I think needs to happen is get a consensus on rough granting guidelines — it's a bit of a mess above, but sysop-only and Enterprisey's option seem to be the favorites — and then fill out the remaining topics. At least to me, given the infrequency of the need and that most conversations should take place on individual talk pages, having one place for granting and discussions about edits seems reasonable. ~ Amory(u • t • c)22:32, 28 August 2018 (UTC)
I've temporarily put it up on the page; we can see if it has any substantial objection during the eventual RfC to promote WP:INTADMIN to policy. Enterprisey (talk!) 04:15, 31 August 2018 (UTC)
Stop-gap two: Restore access to current administrators
Most administrators lost the right to edit the site-wide CSS, JS, JSON pages, and the MediaWiki namespace overnight, without participating in the process which led to this change.
I propose that any user who held administrator right as of 29 August 2018 may apply, through the bureaucrat's noticeboard, if they can demonstrate a need for the interface administrator right. Any bureaucrat may grant the request to a current administrator at their own discretion.
This stop-gap process should remain in force for six months, after which new regulations for granting interface administrator rights should hopefully be in force. Deryck C.13:19, 30 August 2018 (UTC)
Wait? I can’t edit geo-notices anymore? When did this happen? I wasn’t aware of this. Was there a watchlist notice discussing this?—CYBERPOWER(Chat)13:49, 30 August 2018 (UTC)
@Cyberpower678: Yes. Today. The vast majority of admins were in the dark until it happened. I participated in the Phabricator discussion which created this feature, but had no idea it would be rolled out so haphazardly. Deryck C.13:53, 30 August 2018 (UTC)
I may not be the most active user when it comes to JS pages, nor am I the most experienced, but I know enough to make changes to it, without blowing up Wikipedia in the process. I would kindly like to ask to have access back.—CYBERPOWER(Chat)14:01, 30 August 2018 (UTC)
For what it's worth, this was noticed on VPT in early July, was featured in multiple Tech News issues (here and here, posted at VPT), as well as both July and August issues of the Admin's newsletter, which is posted at AN as well as to subscribers. There were other posts as well that linked here, including the initial stopgap nomination. It was also referenced twice (here and here) in July's Signpost, which was linked to via a Watchlist notice for everybody. ~ Amory(u • t • c)14:19, 30 August 2018 (UTC)
And as a shameless plug, I'd like to take this opportunity to encourage all administrators to subscribe to Wikipedia:Administrators' newsletter (non-admins are welcome to subscribe as well). We try hard to include issues like this that affect administrators in the newsletter, which is sent out at the beginning of each month. Mz7 (talk) 20:23, 30 August 2018 (UTC)
The WP:Interface administrators page says "users who can edit sitewide CSS, JavaScript and JSON pages (pages such as MediaWiki:Common.js or MediaWiki:Vector.css, or the gadget pages listed on Special:Gadgets), CSS/JS/JSON pages in another user's userspace, and pages in the MediaWiki namespace." However, Special:UserGroupRights still says that normal admins can edit the interface. I'm a bit unclear on this. Does this mean currently that normal admins can edit pages in the MediaWiki namespace but not JS/CSS, but in the future we will restrict MediaWiki namespace-editing to interface admins only?--SkyGazer 512Oh no, what did I do this time?14:13, 30 August 2018 (UTC)
I have checked and can confirm that the MediaWiki namespace, including pages that aren't CSS, JS, or JSON, is no longer editable by sysops in general (though there may be exceptions). Deryck C.14:17, 30 August 2018 (UTC)
(edit conflict) Both the spam black- and whitelist were edited by a sysop in the past few hours, so I think it's working fine. ~ Amory(u • t • c)14:25, 30 August 2018 (UTC)
Self-redacting. My own test results were wrong. Most of the MediaWiki namespace remains editable by sysops. I think there was a temporary cookie or Wikitext2017 error which made me think they were uneditable. Deryck C.14:36, 30 August 2018 (UTC)
There are no current plans to remove MediaWiki: namespace access from admins. The 2 changes are:
The new interface administrators access group was created, and it can edit restricted things such as css and js pages, as well as the mediawiki namespace
The existing administrators group can no longer edit css/js pages (similar to how other editors can not)
I think I see now. So all administrators will still be able to edit normal pages (e.g. system messages) in the MediaWiki namespace. It's mentioned on this page that interface admins can edit MediaWiki messages, because if an interface admin is not a normal administrator, they will still be able to.--SkyGazer 512Oh no, what did I do this time?14:24, 30 August 2018 (UTC)
Maybe we should specify on the page, that normal admins can still edit gadgets and MediaWiki messages? Right now it makes it seem like that ability is only restricted to interface administrators, just based on the text within the nutshell template.--SkyGazer 512Oh no, what did I do this time?14:27, 30 August 2018 (UTC)
Well, even so, though I don't do it often, I do occasionally edit JS/CSS that isn't my own, be it the geo-notice, or fixing deprecated JS code if it was being requested of me. I would still like to retain access as technically competent user.—CYBERPOWER(Chat)14:56, 30 August 2018 (UTC)
(Responding because of ping.) I've paid attention to the (sudden) roll out of the new feature. Xaosflux has done a good job of trying to mitigate any damages. He's even proposed the Geonotice MediaWiki page be turned into a JSON format so that any admin can edit it, but there are some technical roadblocks to that right now. That said, even though I wasn't the most prolific editor of geonotices, it would be nice to continue to help there. Killiondude (talk) 16:28, 30 August 2018 (UTC)
I don't expect that the JSON fix will be quick, the fastest way to get this access expanded to other editors would be for the community to ratify a policy that the bureaucrats can follow. It doesn't have to be etched in stone, policies can change! There are at least 4 'crats (including myself) that will consider more temporary grants so that maintenance can continue unhindered - and if someone wants to make another section like Wikipedia_talk:Interface_administrators#Stop-gap_users_nominated above with similar constraints (e.g. temporary nature, revocation authorization, community support, at least 3 days discussion) and advertisement (to WP:AN, WP:VPT) that gains sufficient participation and consensus we can add more people editors while waiting for this policy to get completed. — xaosfluxTalk17:20, 30 August 2018 (UTC)
If anyone objects to me closing these, speak up now. While I would like to retain access to the interface pages, these proposals have no bearing on that end-goal except to begin to establish policy sooner than later, regardless of how they're closed. If no one objects I will close the #Sysop as requirement with option 1 being the consensus.—CYBERPOWER(Chat)17:52, 30 August 2018 (UTC)
Please just ensure that whatever gets approved includes under what situations 'crats may add and remove this access. — xaosfluxTalk18:50, 30 August 2018 (UTC)
Is that the consensus though? It's divided roughly in half between people who think it should be only sysops and people who don't think that (either because they think non-admins should be allowed, or because they see this as unrelated to adminship). I think you could very reasonably close this entire set of discussions with the following process for granting access: "Interface administrator permissions are granted by bureaucrats after a request on Wikipedia talk:Interface administrators. Candidates are almost always administrators, and should have experience in the technical areas that this permission deals with. Requests remain open for one week, during which the candidate is evaluated for their technical abilities and potential use of the permission, and candidates are encouraged to speak to both in their nominating statement." We can always modify the process or add more formal rules as time goes on. I haven't followed and don't really care about the mechanisms for removal, but that should be included in the close as well. -- Ajraddatz (talk) 18:59, 30 August 2018 (UTC)
I went through that section, and there does not seem to be a particularly strong consensus either way on the question "should this right be restricted to admins". A head-counting approach results in 13 for admins-only (2 of them "not opposed" to opening it up to non-admins at a later time), 15 for allowing non-admins, and 1 who supported either option. Of the former group, 3 argued that RfA provides a baseline measure of community trust; the relevance of RfA/the mop was argued against by 6 editors. Many observed that editing JS is very sensitive, although several said that non-admins could be trusted with this right as well. Several users noted that EFM is also sensitive, and currently held by nine non-admins.
Another discussion at a more popular venue might give us a better sense of the community consensus on that, but I feel like we've seen all the arguments for or against already. Enterprisey (talk!) 02:46, 31 August 2018 (UTC)
Congratulations
Congratulations everyone. It was pointed out that the new restrictions would negatively affect the abilities of admins who do the work of updating geonotices. The responses? Oh, it'll be seperated out, completely ignoring the fact that there's no clear timeline when that will happen. The list of stop-gap interface editors were selected by deliberately filtering out those whose .js edits were from geonotices. Suprise, suprise, admins that've been updating geonotices are now asking for the right to be able to edit Gadget-geonotice-core.js, but they can't because there's no approved process for crats to grant it. Well thought out roll out everyone. -- KTC (talk) 19:13, 30 August 2018 (UTC)
It's easy to get frustrated, I agree. The proponents of the change keep making arguments about the potential hazards to allowing any admin to edit the interface. However, this has been the case for nearly two decades and only one negative action (the bitcoin mining incident) has occurred, to my knowledge. It does seem like poor planning wrt a timeline either on the part of the community or the developers. Oh well, we'll make the best with what we have. Killiondude (talk) 19:38, 30 August 2018 (UTC)
I'm not sure I agree with how we handled this either. We have over 1,200 admins, all of which could previously edit any JS and CSS page (admittedly, many of them never did), and now none of them can except 6, and we won't allow anybody else to have the right at the current moment, regardless of how much need for this right they've demonstrated. But hopefully we'll come to a consensus soon. Just out of curiousity, Killiondude, what was this "bitcoin mining incident?"--SkyGazer 512Oh no, what did I do this time?19:43, 30 August 2018 (UTC)
From what I've read elsewhere, incidents periodically happen (it's unclear how often) where the sitewide JS is edited to contain malicious code, and these incidents are expunged at the database level so we can't tell how often this happens. Enterprisey (talk!) 20:08, 30 August 2018 (UTC)
Not sure if they are expunged, but there have been a number of incidents across Wikimedia in the last year that lead to the push for this change. -- Ajraddatz (talk) 20:12, 30 August 2018 (UTC)
I got a big smile about "level-1 desysop". I love enwiki. Makes the government that I work for look like an efficient organization. But to answer your question, most/all of the incidents in question were done using compromised accounts, so they were typically locked until returned to their owner (under section 3c, sub-paragraph a of the steward policy no doubt). -- Ajraddatz (talk) 20:24, 30 August 2018 (UTC)
Galobtter, we can have a bot parse the mediawiki-space page and generate suitable JS code. Of course this would require an intadmin bot, which we have absolutely no process for but I suppose we could IAR with a BAG crat if there's sufficient demand. ...Or we could just grant intadmin to users who frequently maintain geonotices, although since geonotices are basically data I agree that the JSON path is far and away the best solution. Enterprisey (talk!) 22:13, 30 August 2018 (UTC)
Hence my suggestion above - can we just let bureaucrats grant any admin the interface administrator at their own discretion, until such a time as the process to get Interface Administrator rights is formalized? Bureaucrats ought to take responsibility and take action in these stop-gap situations. Deryck C.22:03, 30 August 2018 (UTC)
Yes, the relevant policy in this situation is WP:IAR. Xaosflux below seems to be willing to apply his own discretion in the absence of established policy (#Additional temporary access requests).
I know this whole thing seems really disorganized, but I think once we update the main page with Enterprisey's proposed solution above (#Yet another proposed granting process), hammer down the fine details, and (if needed) hold a formal RfC to elevate the final product to policy, everything will be much smoother moving forward. We're almost there. Mz7 (talk) 23:20, 30 August 2018 (UTC)
Mz7, I'd be fine with having the RfC, making what we have now policy, then heading off to VPPR or something to have another discussion on opening it up to non-admins. Enterprisey (talk!) 03:04, 31 August 2018 (UTC)
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)
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)
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. — xaosfluxTalk18: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.
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. — JFGtalk21: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.
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)
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. SQLQuery 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)
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.
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.
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)
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 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)
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.
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.
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. 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)
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)
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.
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.
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)
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)
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.
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 BeetstraTC15: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 BeetstraTC14:27, 5 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. Lourdes18:43, 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)
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. — MusikAnimaltalk03: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. — MusikAnimaltalk16: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 BeetstraTC16:33, 5 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 BeetstraTC12: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 BeetstraTC13: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. — xaosfluxTalk14:19, 6 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The 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.
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.
I would like to request the right to edit geonotices until the technical limitation is solved. I have been the top editor by number of edits (the second-top editor by added text) to MediaWiki:Gadget-geonotice-list.js, using it continuously for 9.5 years, for both events in New York City that I help to organize, and for others, particularly in different local regions of the United States.--Pharos (talk) 15:30, 18 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.
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.
What would we consider the logical descriptor for interface administrators right be described as? I suggest the robo-mopNosebagbear (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)
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). SemiHypercube✎00:22, 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)
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)
@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)
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). SemiHypercube✎15:08, 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) SemiHypercube✎15:37, 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 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)
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) SemiHypercube✎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)
@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)
@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.--▸ épinetalk♬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)
Any of the first three, none of the latter three. Shield promotes the safety aspect too much, mop is too similar to the administrator topicon, and wizard is cute but informal. — Godsy (TALKCONT)06:06, 10 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.
