Meta:Babel/Archives/2018-07

Add links
From Meta, a Wikimedia project coordination wiki

Watchlist issue on metawiki

Resolved. Reported was able to replace a 0-value entry in Special:Preferences#mw-prefsection-watchlist. — xaosflux Talk 00:56, 8 July 2018 (UTC)

As I reported at phab:T198961, my watchlist is not displaying any changes unless there is an explicit days= parameter in the URL (e.g. by pressing the "show" button. This is only happening on meta. user:AKlapper (WMF) notes there that they are unable to reproduce the problem - is anyone else experiencing this?

I'm also completely uncertain whether this is the right page to report this on, so please point me in the right direction if I'm wrong. Thryduulf (talk: meta · en.wp · wikidata) 21:29, 6 July 2018 (UTC)

@Thryduulf: Does it display if you are in safemode? — xaosflux Talk 22:31, 6 July 2018 (UTC)
No, safemode makes no difference at all. Afaik the only custom thing I have on here is user:Thryduulf/monobook.js which hasn't been touched since 2007, whereas this issue is new within the last 1-2 weeks. Thryduulf (talk: meta · en.wp · wikidata) 23:52, 6 July 2018 (UTC)
@Thryduulf: OK more questions: what skin are you using? In preferences what are your settings for: (Group changes by page in recent changes and watchlist); (Expand watchlist to show all changes, not just the most recent)? — xaosflux Talk 01:09, 7 July 2018 (UTC)
If you are using monobook skin then blank your monobook.js and try without it. Ruslik (talk) 07:30, 7 July 2018 (UTC)
@Xaosflux and Ruslik0: I'm using monobook skin, but I tried with ?useskin=vector and changing to vector in my preferences neither made any difference; blanking my monobook.js made no difference. "group changes by page in recent changes and watchlist" is off; "Expand watchlist to show all changes, not just the most recent result" is off. Thryduulf (talk: meta · en.wp · wikidata) 08:12, 7 July 2018 (UTC)
@Xaosflux: fixing ping. Thryduulf (talk: meta · en.wp · wikidata) 08:13, 7 July 2018 (UTC)
@Thryduulf: next two thing to try: (1) In Special:Preferences#mw-prefsection-watchlist, change your "Days to show in watchlist" to a new value (try 10). (2) Go to Special:EditWatchlist/raw and see if you have any pages using very unusual characters, especially as the first character (for example &'s, ='&, "spaces"). — xaosflux Talk 13:27, 7 July 2018 (UTC)
@Xaosflux: Changing the "Days to show in watchlist" to 10 has seemingly solved the issue - the previous value was 0. Quite how it got to be that I have no idea as before this troubleshooting I've not edited my preferences on meta since, afair, changing my signature circa December 2015. Thryduulf (talk: meta · en.wp · wikidata) 00:47, 8 July 2018 (UTC)
Are there any javascript errors in the browser console? Ruslik (talk) 18:36, 7 July 2018 (UTC)

See also Phab:T199049 to try and prevent this being an issue in future. Thryduulf (talk: meta · en.wp · wikidata) 11:00, 8 July 2018 (UTC)

This section was archived on a request by: —MarcoAurelio (talk) 17:56, 28 July 2018 (UTC)

Move page

Can someone move Grants talk:ХУЙ ФУФЛО back to Grants talk:IdeaLab/Identify and quantify toxic users. This seems to be an erroneous move. Note also the activity on Grants:IdeaLab/Identify and quantify toxic users. — Jeblad 15:18, 20 July 2018 (UTC)

The page Grants:Grants:IdeaLab/Identify and quantify toxic users has been given a repeated namespace… — Jeblad 15:31, 20 July 2018 (UTC)
Already corrected. ;) — Jeblad 15:32, 20 July 2018 (UTC)
Thanks for reporting here-- this looked like an attempt to vandalize a specific idea or disrupt the campaign generally. I JethroBT (WMF) (talk) 15:33, 20 July 2018 (UTC)
This section was archived on a request by: —MarcoAurelio (talk) 17:56, 28 July 2018 (UTC)

viewuseroptions access

Hi all, trying to brainstorm if there would be support/opposition for a new feature before shopping it around. Feature would be a new permission/grant for viewuseroptions that would allow the viewing of another user's preferences (but not their (privateinfo) (e.g. email address, real name) or watchlist data. Perhaps restrict this to sysops or some other group. A recurring theme is that it is hard to help people that are having a site issue and you have to go back and forth or try to get them in to irc to even get basic things answered. Thanks for your feedback! — xaosflux Talk 01:22, 7 July 2018 (UTC)

The EditUser interface allows for viewing and editing another user's preferences, so the basic functionality exists already (not used here). But yes, I think there's a case for it. – Ajraddatz (talk) 08:07, 7 July 2018 (UTC)
Thanks, I saw there were a few extensions, but none look strongly maintained - which could also be a reason to move this to core functionality. — xaosflux Talk 13:34, 7 July 2018 (UTC)
I could see that being beneficial. Killiondude (talk) 23:06, 8 July 2018 (UTC)
For anyone following this, a larger discussion is going on at w:en:Wikipedia:Village_pump_(technical)#viewuseroptions_access that helped identify some potential privacy issues but is re-framing this as a way to enable a user to export and share their settings instead that will still be useful. — xaosflux Talk 14:27, 25 July 2018 (UTC)
  • Note, due to the discussion above, I'm not asking for this to go forward, if we develop a usable self-service gadget over on enwiki porting it may be useful. Any feedback on that other discussion is still welcome! — xaosflux Talk 20:27, 27 July 2018 (UTC)
This section was archived on a request by: per my note above, will continue developing a user-side "export" as opposed to a "query" model. — xaosflux Talk 17:06, 30 July 2018 (UTC)

Enable template styles on Meta

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus achieved after several days. —MarcoAurelio (talk) 17:51, 28 July 2018 (UTC)
Tracked in Phabricator:
Task T200613 resolved

TemplateStyles has or is in the process of being deployed to a number of small and large wiki's including fr.wiki, de.wiki and en.wiki. It would really useful to have this enabled here. In favour? Seddon (talk) 11:28, 11 July 2018 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Deployed. —MarcoAurelio (talk) 10:11, 1 August 2018 (UTC)

This section was archived on a request by: —MarcoAurelio (talk) 10:11, 1 August 2018 (UTC)

Enabling responsive references on Meta

Tracked in Phabricator:
Task T200707 resolved

Hello. It looks like Meta doesn't have the nice, responsive, multi-column reference lists available on other Wikimedia wikis. Does anyone see a reason not to enable them here? This would mean enabling the $wgCiteResponsiveReferences option for this wiki. Guillaume (WMF) (talk) 20:47, 23 July 2018 (UTC)

Sounds fine. --MZMcBride (talk) 23:30, 23 July 2018 (UTC)
Do we have an example of what this does? A screenshot? Thanks! —MarcoAurelio (talk) 17:54, 28 July 2018 (UTC)
@MarcoAurelio: you can see it in action on many other wikis, for example at w:en:Pony#References. Compare the two columns for references (assuming a screen size large enough) compared to the single column for references on this wiki e.g. at Research:Codex/Roles of contributors#References. Guillaume (WMF) (talk) 03:11, 29 July 2018 (UTC)
Thanks, sounds good to me as well. Support. —MarcoAurelio (talk) 10:48, 29 July 2018 (UTC)
I've opened a ticket at phab:T200707. Guillaume (WMF) (talk) 17:04, 30 July 2018 (UTC)
Deployed. —MarcoAurelio (talk) 10:11, 1 August 2018 (UTC)
This section was archived on a request by: —MarcoAurelio (talk) 10:11, 1 August 2018 (UTC)

Tech Admins

So, its been decided by the dev team to move forward with the creation of separate user group for editing sitewide CSS/JS - and communities (including Meta) - will be able to self-manage via their bureaucrats. I suggest we just add a new section to our existing Meta:Requests for adminship page for those that need this access, and use the same activity policies we have in place for meta admins. Most of our admins will not need this and phab:T190015 suggests that CentralNotice management is exempt. Ping to our current 'crats for any insightful feedback: MF-Warburg, MarcoAurelio, and Matiia. — xaosflux Talk 20:26, 27 July 2018 (UTC)

Support Support - Rschen7754 02:04, 28 July 2018 (UTC)
How should we grant permissions (to existing admins who requests) during transitioning period? — regards, Revi 02:57, 28 July 2018 (UTC)
@-revi: the transition period should be long enough that we can just use the new process, in the last month there only appears to have been two volunteer admin edits to a .js/.css mediawiki page (assuming the foundation will take care of their staffers). With volume quite low and our rfa process only a week there should be time to add the access to those that need it before it is removed from +sysops. — xaosflux Talk 03:12, 28 July 2018 (UTC)
Makes sense, proposal fully supported. — regards, Revi 03:15, 28 July 2018 (UTC)

Meta has not decided to remove this right from existing administrators, so administrators should be able to grant the right to themselves. I don't think such a thing as "tech admin" will exist on Meta: there's barely anything here which can be done with "technical" considerations without "social" understanding of our community. --Nemo 06:34, 28 July 2018 (UTC)

Generally agree with this, though I think that the ability to add/remove this should still rest entirely with bureaucrats due to the security concerns. Admins can have it added or removed on request. – Ajraddatz (talk) 06:58, 28 July 2018 (UTC)
@Ajraddatz: I think its obvious that anyone that wants their access removed would have no issue and can just ask or post at RFH. For adding, I expect that the meta community will have little issue with existing admins getting this if they request - but would rather see a standard request process to document it then just something like pinging a 'crat on IRC. Our Meta:Requests for adminship page is fairly drama-free, not like the ordeal at enwiki or elsewhere. — xaosflux Talk 11:35, 28 July 2018 (UTC)
@Nemo bis: the access is being removed from all +sysop groups by the developers, that part is not a community choice. Managing membership is by stewards or by bureaucrats in communities that have them. We may set our own requirements (e.g. you must also be a meta admin; only 1 week grants; etc). I think the part about including it in GIE access (like you have) is still under some discussion with the dev team. Should it not be, I don't see issue with us having a path to enable the access for trusted users like you. — xaosflux Talk 11:35, 28 July 2018 (UTC)

Well, this is a security change. Making all administrators interface-admin's by default wholy defeats its purpose, moreover in this central Meta-Wiki where lots of global stuff is hosted and imported elsewhere. I however would like to see two different processes for getting the permission: one for existing admins (less bureaucratic, maybe even shorter in time?) and another one for non-admins willing to do interface-admin work (with the same requirements as stated to pass a regular RfA). No IRC requests. All requests must be documented somewhere on wiki IMHO, for this kind of big-deal permissions. —MarcoAurelio (talk) 17:49, 28 July 2018 (UTC)

I also won't be opposed to request at the same time both admin and interface-admin provided that it is clearly said in the RfX and that the community be allowed to support the whole pack or just one or the other; but for the sake of clarity maybe people interested in having both could open an RfA and a RfIA at the same time. —MarcoAurelio (talk) 18:02, 28 July 2018 (UTC)
Yes, it's a security change, but it's not that our admins can't be trusted with the right. We just need to reduce the access to those that need it. I think that allowing local admins to request it in some formal place without discussion should be sufficient, because we aren't assuming any loss of trust. If we do want a shortened request for existing admins, perhaps use the same formula for electing 'crats? Two "admin-endorses" and it can be closed early? – Ajraddatz (talk) 20:03, 28 July 2018 (UTC)
I'm OK with that. Still think it should be all in the same place, e.g. Meta:Requests_for_adminship#Requests_for_technical_adminship - but allowing an abbreviated (2-3 day?) closing process for existing admins seems fine. — xaosflux Talk 21:25, 28 July 2018 (UTC)
I can agree with that. Make it two days to mirror the bureaucrat process, if there are any serious objections then it requires a week and the usual consensus. Numerical requirements can be the same as admin, ~75% with some usual bureaucrat discretion. – Ajraddatz (talk) 15:55, 30 July 2018 (UTC)

Comment Comment I would prefer that any admin who requests the tech admin right, just be given the right, they can specify a reasonable period of time for which it is required, I would think that the duration of a week would be usual, though could be repeated or extended with explanation. If would be unusual for any admin to require unfettered and continuous access. Any 'crat who has serious security concerns, can broach them and hold the request. [Noting that meta admins have been through review processes twice, so have served a "probationary" period.] Non-admins seeking tech-admin status should have a standard process for rights.  — billinghurst sDrewth 01:11, 29 July 2018 (UTC)

I support simplified process for existing admins and a regular RfP for non-admins. I do not support adding self-grant ability for admins. I like this change and such configuration would kill the purpose. This change should have happened at least a decade ago. Neither I support the motion of having it granted only for short periods of time. Of course sometimes activities are planned, but sometimes you just see a useful gadget or script in other place and import it on spur of moment, sometimes you respond to a localisation request likewise. Having to request for the rights every time would discourage doing anything. --Base (talk) 04:24, 31 July 2018 (UTC)

I agree with Base. For current admins who feel needing rights can get it without expiring. For non-admins after RfP preferably for a reasonable period of time, with good reasons for longer time. Stryn (talk) 18:09, 31 July 2018 (UTC)
See quarry:query/28677 for the stats. In the past year, there were only 47 edits to site JS/CSS, from 18 users. Admins should not get this new right indefinitely by simply asking, that's defeating the purpose. It should only be for those who will use it. It's not that hard to make a protected edit request. If admins get the right temporarily on request, I think this is fine to do without any bureaucracy. I would be weary of granting this to non-admins who are not admins on other projects, or have not gone through sufficient community evaluation. The "interface admin" right is up there with CheckUser in terms of sensitivity. — MusikAnimal talk 19:03, 31 July 2018 (UTC)
@MusikAnimal: May I suggest that the default for these rights is that admins request and it is granted is a set period (be it a week, a month, ...) and there is a light review by 'crat. Any admin is able to suggest a longer, or shorter, period depending on their needs, and where it is longer, that the 'crat reviews that request and determines whether they want the community to authorise such a request. This allows for a permanent allocation, though one would think that a 'crat would be asking for a consensus of the community in that sense. So we have a tiered approach.  — billinghurst sDrewth 22:37, 31 July 2018 (UTC)
That doesn't sound so bad... but as I said below, I really don't think "temporary interface admin" is even needed. Why can't they just request edits be made on their behalf? If there is a use-case for continued, ongoing modifications, that'd be different. But data suggests this rarely happens — MusikAnimal talk 23:13, 31 July 2018 (UTC)
Actually checkuser rights are given for an indefinite period of time. Ruslik (talk) 20:11, 31 July 2018 (UTC)
But subject to procedural removal after some period inactivity, no? My point anyway is "just asking" for interface admin rights, and getting it, is making it out to be no-big-deal. It is a big deal. Especially here where there are so many active stewards (I won't elaborate per BEANS) — MusikAnimal talk 23:12, 31 July 2018 (UTC)
The purpose is supposedly to have more accountability (thanks to the userrights logs) and smaller attack surface.
Giving admins the possibility to self-add and remove the right would actually achieve the purpose better, because then they could grant themselves the right just for the few minutes they need it. This would make it very easy to follow the userrights logs (while there are no feeds for "accounts who plan to edit namespace 8 in the near future") and also to restrict the right in case of attacks. --Nemo 19:41, 31 July 2018 (UTC)
@Nemo bis: I believe that this is a security measure. If any admin can self-assign admin rights whenever they want, isn't that insecure? — The preceding unsigned comment was added by Billinghurst (talk)
Yes I agree, self-assignment probably doesn't help with security. Admins here may be different, but on enwiki we have many self-assigned edit filter managers that have never actually edited a filter. They mean no harm, but in the case of interface admin this wouldn't effectively be reducing the attack surface. Frankly the temporary interface admin isn't something we should be thinking too much about. Sure, ask for it if you really need it, but how often does that happen? 18 users edited site JS/CSS in the past year... most made no more than a few edits. Can't they just request the edits be made on their behalf? Doesn't seem like to much of a hurdle — MusikAnimal talk 23:07, 31 July 2018 (UTC)
Oppose Oppose - PlavorSeol | T | C 10:45, 7 August 2018 (UTC)

I suppose it makes sense to give this new group to sysops who request it, giving the reason why they need it, and to give it to other users upon a normal request on WM:RFP (1 week for comments etc.). It also makes sense to apply the sysop inactivity policy separately to this group, so that sysops who are active but don't use the interface editing rights lose them again, in line with the thinking which led to the creation of the group. --MF-W 11:01, 7 August 2018 (UTC)

@MF-Warburg: as one of the people that will be processing these requests how to you want to see them? I'm suggesting they all appear in once place, a section at Meta:Requests for adminship, but they could just go in Meta:Requests for help from a sysop or bureaucrat, or just an ad-hoc process. — xaosflux Talk 15:43, 8 August 2018 (UTC)
WM:RFP makes the most sense to me. --MF-W 16:50, 8 August 2018 (UTC)
@MF-Warburg: WM:RFP doesn't exist... do you mean WM:RFA ? — xaosflux Talk 17:04, 8 August 2018 (UTC)
Sure it does. Are you losing your mind? (;-) StevenJ81 (talk) 21:49, 8 August 2018 (UTC)
Ha! Thanks there StevenJ81 I was hoping this wasn't a punt to RFP!— xaosflux Talk 23:04, 8 August 2018 (UTC)
Of course. How peculiar. --MF-W 21:19, 8 August 2018 (UTC)

As a side note, will stewards be required to run for this right if they want to make a JS change on Meta? Or can they just use their steward rights? --Rschen7754 18:35, 8 August 2018 (UTC)

I'd say it'd be covered by Meta:Meta–steward_relationship#Administrative_actions_on_Meta if they're uncontroversial, etc. —MarcoAurelio (talk) 19:55, 8 August 2018 (UTC)
  • I don't see why interface editors should be treated any different than CN admins. Both tools are equally "risky". Since CN admin rights are part of the admin group on meta it doesn't make any sense at all not to grant interface editor rights to all admins on this project. What could be considered though is to remove the CN admin rights from the admin group and then proceed with the CN admin group in a similar fashion like what is being proposed here. --Vogone (talk) 01:35, 12 August 2018 (UTC)
    @Vogone: phab:T190015 suggests that the sitee js/css access (which does not currenly include USERxxx access) will be removed as well. — xaosflux Talk 15:03, 12 August 2018 (UTC)
    I read "Sitewide CSS/JS editing not covered by the patch: […] Javascript in CentralNotice banners […]" or are you referring to something else? --Vogone (talk) 15:17, 12 August 2018 (UTC)
    @Vogone: in the list of "Affected Wikimedia user groups:" ; it may be that removing the access from this group won't matter - as the CN banners will have their own control, but CNAdmins do appear to be on the list to lose js/css site pages in general. — xaosflux Talk 19:30, 12 August 2018 (UTC)
    Alright, that's how I understood it as well. But that means my point remains valid, since a hacker likely does not care which tool he has to use in order to achieve his goals. :-) --Vogone (talk) 19:43, 12 August 2018 (UTC)

Pushing forward

To bootstrap this, the following items need to get closed, I think some are getting closer to a consensus on some topics: Revised as below. — xaosflux Talk 19:56, 12 August 2018 (UTC)

  • Request processing requirements?
    Discussion to be open for at least 2 days for existing metawiki admins, if objections are raised discussion to extend to 7 days.
    Discussion to be open for 7 days for others.
    Closure upon a strong (~75% support) consensus being established following the minimum discussion time as determined by our bureaucrats.
    Unless the request specifies otherwise, no expiration date on grants.
  • Revocation criteria:
    Inactivity tracking and revocation will follow the process for Meta:Administrators#Policy_for_de-adminship, with restricted edits counting towards the "logged actions" criteria.
    For misuse, as determined by a community discussion at Meta:Babel with >50% support for removal.

Discuss

Any further comments to get this off the ground? We certainly can always revisit. — xaosflux Talk 19:56, 12 August 2018 (UTC)

What happens with CentralNotice? Can admins after the change still edit CentralNotices? --Steinsplitter (talk) 17:34, 14 August 2018 (UTC)
@Steinsplitter: phab:T190015 calls out that the "Javascript in CentralNotice banners" are not going to be impacted, however centralnotice admins will loose their existing access to modify other mediawiki javascript. — xaosflux Talk 17:52, 14 August 2018 (UTC)
Any tweaks requested? This will need to go live in time for the change, and this discussion hasn't been very heavily attended. — xaosflux Talk 15:31, 18 August 2018 (UTC)
Above text LGTM. — regards, Revi 15:48, 18 August 2018 (UTC)
  • I built out Meta:Interface administrators and the related process pages, marked under-construction pending any last initial comments. — xaosflux Talk 15:29, 19 August 2018 (UTC)
  • As per my comment above I deem the proposed procedure highly nonsensical as long as the CN admin rights remain with the admin group. There is simply no benefit from a security perspective. --Vogone (talk) 16:28, 19 August 2018 (UTC)
    @Vogone: the procedure is because this access is being removed from the admin group by the developer team, and we need a community mandate on how to allocate it again - do you have specific changes to the proposed process to suggest? Regarding CN: Patches related to sanitizing the code in CN's has already been worked on (see phab:T171987) - I'm not sure if those changes address your security concerns for CNAdmins being able to do bad things? — xaosflux Talk 17:13, 19 August 2018 (UTC)
    CN admins can run sitewide JavaScript just like interface admins can. The only difference is that the js is being executed as part of the banner. The task you mentioned refers to the ability to inject code to a CN's title (which is obviously a bug), but it also says "CentralNotice itself allows easy JS, HTML and CSS injection into almost any production wiki--that's what it's for, really." Should we decide that editing CN banners should be part of the standard meta admin toolset, then having a discussion prior to granting interface admin rights which don't add any extra risk to an admin's account is simply not necessary. I would suggest to add all metawiki admins to the interface admin group in that case. Generally, the rules for obtaining interface admin and CN admin permissions should be the same. --Vogone (talk) 19:23, 19 August 2018 (UTC)
    @Vogone: I created phab:T202244 to look in to concerns you have with CNA's still being able to inject via that process. I disagree that just because one vector still exists that the new access should just be issued to everyone - it defeats the purpose of the new restrictions existing. — xaosflux Talk 19:45, 19 August 2018 (UTC)
    To answer your question in the ticket: by removing CN permissions from admins and only allowing CN admins to manage CNs. --Vogone (talk) 20:01, 19 August 2018 (UTC)
    OK that's a possible improvement - but I'm not seeing it as a blocking task to us starting a framework for granting IA access. — xaosflux Talk 20:10, 19 August 2018 (UTC)
    I don't think it makes sense to discuss IA and CN separately and all rules applying to IA access should as well apply to CN access and vice versa. I would be very unhappy seeing two different and arbitrary procedures for two extremely similar access levels. That is my main point. --Vogone (talk) 20:19, 19 August 2018 (UTC)
  • While I know it is not possible to enforce it currently, how about to mention that IAs are strongly encouraged to have good account security and H:2FA enabled for their accounts? Other than that, the proposed rule looks good to me. I understand that it requires 75% of support as well, as we do for RfAs, etc. right? —MarcoAurelio (talk) 14:43, 21 August 2018 (UTC)
  • I must say that I miss a section detailing a removal process outside inactivity. I have witnessed two discussions concerning the removal of rights here without policy and I'd hate to go down that path again. It should cover immediate removal upon abuse and maybe a process where community can vote to remove someone's IA permission. —MarcoAurelio (talk) 14:46, 21 August 2018 (UTC)
    @MarcoAurelio: for reference - what policy would you use for this removal of sysops? — xaosflux Talk 03:00, 23 August 2018 (UTC)
    @Xaosflux: We have none. If I were to choose I'd use the commons' one which to me looks simple and to the point. —MarcoAurelio (talk) 10:23, 23 August 2018 (UTC)
  • Comment Comment Without the interface right, an administrator is unable to delete user js/css pages. That sounds pretty silly that a page is unable to be deleted, irrespective of whether it can be edited.  — billinghurst sDrewth 05:52, 29 August 2018 (UTC)
    If tech-admin rights are going to be temporary, making a two day wait for assignation of rights is going to be ridiculous if we are needing the right for deletion requests. So if that right is required for deletion, it needs to be a longer term assignation if there is a two day wait. OR we get the deletion right added to the standard admin tools, so it isn't a problem.  — billinghurst sDrewth 06:07, 29 August 2018 (UTC)
    Admins can delete these again, tested today. — xaosflux Talk 22:25, 29 August 2018 (UTC)

What "or if a request for comment has shown that a significant minority does not trust the interface admin" mean? Please clarify the criteria. Xaosflux's version was way better in that regard. —MarcoAurelio (talk) 11:27, 12 September 2018 (UTC)

What exactly is unclear to you? The wording is copied from the GS policy, where, IIRC, one such request happened years ago. It means that an RFC (it doesn't matter if it's called an RFC though, it can as well be on WM:RFA) can be started requesting that the user's right is removed. I prefer that wording over a "voting" provision with fixed percentage for a variety of reasons, not least because requests for adminship are not votes either and we have no criteria about "voting rights" (unlike some other wikis). --MF-W 14:04, 12 September 2018 (UTC)
That wording is unclear to me and I don't like it. I want clear provisions. —MarcoAurelio (talk) 16:59, 13 September 2018 (UTC)
In fact I remember right that I protested this same wording for GS some time ago. While I'm okay with the immediate removal provision, the "significant minority" and "vote of confidence" simply don't add up to me and would like that clarified. —MarcoAurelio (talk) 17:06, 13 September 2018 (UTC)

Closing?

Thank you to everyone that has contributed so far! Meta:Interface administrators has been updated with most of the suggestions above and the discussion has slowed, I'm proposing moving this to a close. — xaosflux Talk 13:41, 21 September 2018 (UTC)

@MarcoAurelio: and @MF-Warburg: does this capture the spirit of what you were both going after? (Minimal 'bureaucracy' and 'plain language') — xaosflux Talk 13:41, 21 September 2018 (UTC)
@Vogone: your inactivity concern about non-admin iadmins was considered towards this version in that the activity requirement is now only 1 usage/6months. Your CN concerns have a phab ticket open for additional review, and we certainly could re-review the CN granting guidelines (feel free to start a discussion, Steinsplitter also had some CN concerns). — xaosflux Talk 13:41, 21 September 2018 (UTC)
@Billinghurst: your viewdelete concern is a global problem, and is being addressed in phab:T202989 (currently pending code review). — xaosflux Talk 13:41, 21 September 2018 (UTC)
@PlavorSeol: you voiced an opposition without any details above, if you have any suggestions for what to include please elaborate? — xaosflux Talk 13:41, 21 September 2018 (UTC)
@KPFC: your suggestion that there should be no minimum discussion period doesn't seem to have much support, however no quorum requirements have been included so requests can be completed even if there is little discussion. — xaosflux Talk 13:41, 21 September 2018 (UTC)
Pings to prior participants should the latest version no longer reflect their prior comments: @Rschen7754:, @-revi:, @Nemo bis:, @Ajraddatz:, @Base:, @MusikAnimal:, @Ruslik0:. — xaosflux Talk 13:41, 21 September 2018 (UTC)
In its current form, I cannot support the proposed policy. It still has the issue of unnecessary waiting times (2d/7d rule), it has a potentially harmful inactivity policy (it is very well possible that someone edits meta less frequently than once every 6m, see for example Dschwen's past RFAs) and on top none of these arbitrary obstacles have been provided with a reason. My point stands that "security issues" cannot be a valid reason concerning meta since admins here have much more powerful tools and can circumvent JS/CSS edit restrictions, anyway. I am fine if this right is granted "on request" as a compromise, but anything beyond this is unecessary buraucracy lacking any justification. --Vogone (talk) 14:09, 21 September 2018 (UTC)
I agree with Vogone and therefore i cannot support the proposed policy in its current form. As Vogone wrote above "unecessary buraucracy lacking any justification". Best --Steinsplitter (talk) 14:17, 21 September 2018 (UTC)

Hi, thanks for reminding me of this discussion! I have incorporated the discussions about the inactivity requirement and about the 2-day waiting period into the policy page now. Afaics, everyone who commented in fact supported its removal, contrary to what Xaosflux says. So the only thing that remains to be discussed are the removal provisions. Since implementing this policy is rather urgent as at the moment nobody can edit the interface except stewards (cf. Meta:Requests_for_help_from_a_sysop_or_bureaucrat/Archives/2018-09#TemplateStyles:_ContentModel_change_request), I marked it as accepted now so that we can process requests. I am very open to adjusting the policy to a clearer removal provision proposed by MA eventually. --MF-W 14:52, 21 September 2018 (UTC) I overlooked that MA had already adjusted the policy :-) --MF-W 14:58, 21 September 2018 (UTC)

Sorry I've been out of the loop. Thank you for the ping. In the name of security I still think granting on request is bad form and contrary to the entire point of why this user group was introduced. Global JS/CSS, for that matter, yet we don't seem to be taking it seriously? The policy page doesn't even mention the word "security", which is what this is about. Demonstrated need would be a bare requirement, in my opinion. Maybe at least a kind recommendation to practice good account security, including use of 2FA? I get avoiding bureaucracy, I hate it too. So I'm only going to propose some copy edits to at least give a remote impression that this is a most sensitive right. As currently portrayed, it's just "there" and doesn't have any particular importance. I've said this many times, but to reiterate, global AbuseFilter and spam blacklist are child's play compared to what JS can do. There are some existing loopholes (yes loopholes) that question the effectiveness of interface admin here on Meta, but I wouldn't assume them to remain indefinitely and those loopholes are much less likely to be the target of an attack anyway. I realize we are likely to be divided on this issue so please don't allow me to hold us back, but it would be nice to at least touch on the core issue of security somewhere on the policy page. — MusikAnimal talk 17:31, 21 September 2018 (UTC)

  • My thoughts are largely aligned with Vogone. The security benefits from this group are reducing attack surface, not that existing admins cannot be trusted with the access. I have no issues with including some wording to that effect in the policy. I initially supported a 2 day waiting period, but it's clear from further discussion that it would be overkill to require that from people who are already trusted in this area. I am similarly concerned with the inactivity part requiring actual use of the tool, because that could be few and far between. I would support an activity requirement of any edits or log actions in 6 months, and being checked as part of the existing checks for local sysops. – Ajraddatz (talk) 17:38, 21 September 2018 (UTC)
    @Ajraddatz: regarding inactivity, the way I interpreted it was:
    (for sysops) - this stays as long as your sysop stays, and you can also use these edits towards keeping your sysop
    (for non-sysops) - 1 use every 6 months to keep it.
    — xaosflux Talk 17:53, 21 September 2018 (UTC)
      • Although it appears to have been changed by User:MF-Warburg to "10 global edits" now, which I think is way to lenient, if you aren't going to ever use this on-meta - why do you need this here? I'd say moving as far as one "use" here per year may be enough, but if you aren't contributing on meta at all why do you need this access? — xaosflux Talk 18:04, 21 September 2018 (UTC)
    • Indeed! Of course editing CSS/JS pages can be used in a very malicious way, I am well aware of that. However, this group was not introduced because "of those who previously could do this, many were suspicious people", but because "many previously could do this who never used the tools in question and so are better off not having them available, so their accounts are no targets for being hacked". --MF-W 18:48, 21 September 2018 (UTC)
      • Can't we just require that the edits be done at Meta instead of global? Any edit, but locally, here. Thanks. —MarcoAurelio (talk) 20:43, 21 September 2018 (UTC)
        • I have no problem with that. --MF-W 10:40, 22 September 2018 (UTC)
        • As outlined above, this would be, in my opinion, a bad idea. Not every "technician" updating/cleaning up scripts here is necessarily an active metawiki editor who reaches 10 local edits in 6 months. Xaosflux's proposal (at least 1 "use" of the rights in 12 months) seems way more reasonable in this regard to me. However, 10 global edits in 6 months already show the account is not dormant/unmaintained. If a user indeed no longer needs their IA privileges here on meta, they will very likely accept removal if explicitly asked, and since they are active (as proven by the 10 global edit requirement) getting a reply shouldn't be an issue either. This could, by the way, be formalised in a fashion similar to the current admin removal process (ask for signature if there hasn't been a "use" for 6/12 months). --Vogone (talk) 10:55, 22 September 2018 (UTC)
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Meta:Babel/Archives/2018-07&oldid=18499736"