Meta:Babel

← Index of discussion pages

Babel

archives (latest) →

This is the general discussion forum for Meta (this wiki). Before you post a new comment please note the following: You can comment here in any language. This forum is primarily for discussion of Meta policies and guidelines, and other matters that affect more than one page of the wiki. If your comment only relates to a single page, please post it on the corresponding discussion page (if necessary, you can provide a link and short description here). For notices and discussions related to multilingualism and translation, see Meta:Babylon and its discussion page. For information about how to indicate your language abilities on your user page ("Babel templates"), see User language. To discuss Wikimedia in general, please use the Wikimedia Forum. Consider whether your question or comment would be better addressed at one of the major Wikimedia "content projects" instead of here.

Wikimedia Meta-Wiki

• About Meta
• Discussion pages
• Request pages
• Policies and guidelines
• Information and statistics
• Categories
• Help pages

Participate:

• How to edit a page
• Meta-Wiki discussion page
• Meta-l mailing list

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

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 - 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 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 - 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)

• Where may these requests be handled?

  All requests to be processed via Meta:Requests_for_adminship#Requests_for_technical_adminship similar to other access requests on that page.

  Any request may be requested to be (time limited) or (time- and scope- limited) similar to the existing Meta:Administrators#Limited_administrator_status process.

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

• Activity requirements?

  Same as Meta:Administrators#Policy_for_de-adminship (with protected edits counting as "logged actions").

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

• additional Comment With the change over, admins are now unable to view deleted .css that is in user: ns, and I am guessing that .js will have the same consequence. This is problematic for me at two levels, 1) as an admin I should be able to see all deleted pages that have not been oversighted; 2) as an ombudsman, I definitely should be able to see them as I should be able to see all oversighted pages as well.  — billinghurst sDrewth 21:43, 3 September 2018 (UTC)

  Yeah, it's not great. It is currently tracked in phab:T202989. Killiondude (talk) 01:43, 4 September 2018 (UTC)

  Being fixed at https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/456140/. Please help review, if you are confident/familiar with PHP and mediawiki. Thanks, —MarcoAurelio (talk) 21:05, 4 September 2018 (UTC)

  Can we request the right yet? I did a number of edits on MW pages which are "locked" now (See also Phab:T200997). Imho admins on meta should have this included by default, we can edit CN (which is raw js/css sidewide) and global abusefilter, global spam- & title blacklist. Best --Steinsplitter (talk) 10:43, 10 September 2018 (UTC)

  This has had so little input, suppose it is up to our 'crats if they think we have enough to define their scope. @MarcoAurelio: - any thoughts? — xaosflux ^Talk 13:40, 10 September 2018 (UTC)

• I added some basic "revocation" criteria above. — xaosflux ^Talk 18:30, 10 September 2018 (UTC)

• Published a maybe-final versions here: Meta:Interface administrators. — xaosflux ^Talk 13:20, 11 September 2018 (UTC)
  • I have made some changes to that page to remove superfluous bureaucracy: [1]. In particular I copied the removal provisions from GSes, which work well. --MF-W 18:38, 11 September 2018 (UTC)
    • To be honest I don't even see a need for a 2-day waiting period for existing sysops (similar to translation-adminship). --MF-W 18:44, 11 September 2018 (UTC)
      • Agreed. Let's remove the 2d criterion and proceed. --Vogone (talk) 11:10, 12 September 2018 (UTC)
      • I support MF-W's suggestion. The users, who already have admin flag are trusted people, no need to wait 2 days, which makes it only overly complicated and inflexible. – KPFC 💬 19:27, 12 September 2018 (UTC)
    • @MF-Warburg: regarding "used their rights for six months" - the only measurable access for this is "edit" and the bundled "undelete" and in areas that overlap with sysop; this makes it OK for someone to make 1 edit every 6 months to any mediawiki page for example (which if they are also sysop would result in them getting -sysop, but leaving this "more dangerous" access). I'd rather keep the normal admin inactivity rules, but allow these edits to count. — xaosflux ^Talk 18:52, 11 September 2018 (UTC)
      • I have changed it so that the normal inactivity policy applies for admins who are also interface admins. For non-admins, I wonder if requiring 10 (CSS/JS) edits in 6 months isn't too high - there might be legitimate use cases that appear from time to time but don't warrant making that many edits (cf. Meta:Requests_for_adminship/Dschwen_5). --MF-W 20:00, 11 September 2018 (UTC)
        • For non-admin int-admins, perhaps normal "edits" may be sufficient - intadmin editing is very niche, but it will show that the user is still actively in control of their account and responsive. — xaosflux ^Talk 20:14, 11 September 2018 (UTC)
          • So, at least 10 total edits per 6 months? --MF-W 10:38, 12 September 2018 (UTC)
            • Does not sound like a good idea to me, provided metawiki is not a home wiki to most. If someone requests that right in order to keep a specific JS/CSS page up-to-date, that should be allowed. Either make it "10 global edits per 6 months" or keep the previous rule, in my opinion. --Vogone (talk) 11:10, 12 September 2018 (UTC)
        • I agee with everything what MF-W wrote above in any regard, it sounds very reasonable. --Steinsplitter (talk) 11:00, 12 September 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 wonder what discussion on this right will finish first, the one on enwiki or the one here. --Rschen7754 18:15, 21 September 2018 (UTC)

'editcontentmodel' permission for 'massmessage-senders'

After some unexpected remarks relating to a change which I deemed uncontroversial, I have to seek community consensus for phab:T202597. To me it makes sense to add this permission to the group since it a) solves a bug and b) members of the group are trusted not to be vandals and mess around with content models, anyway. Should there be consensus in favour, I will SWAT schedule the change in 2 weeks from now on. Regards, --Vogone (talk) 08:13, 23 August 2018 (UTC)

• As long as the concerns exposed at <https://phabricator.wikimedia.org/T85847#2959070> still remain unresolved I'd strongly oppose. Regards, —MarcoAurelio (talk) 10:19, 23 August 2018 (UTC)

  I can't really follow your line of argument here. Shall we temporarily remove 'editcontentmodel' from admins as well then, in light of the discussion two sections above this one? If this is a bug, it needs to be fixed. Independently of the outcome of this discussion here. --Vogone (talk) 10:44, 23 August 2018 (UTC)

  Why remove admins? Admins can already edit user JS pages with our without editcontentmodel permissions (soon to be lost in favor of interface-admin). While I agree the bug --if it still exists, something that I've already asked-- should be fixed, expanding this access so everyone can exploit it looks a bad idea to me. This is a conditional oppose as long as that bug exists. In any case, it looks to me that people with 'massmessage' rights should be able to create and edit massmessage lists without the need of 'editcontentmodel', but that's a config change for the extension itself that we're not discussing in here. —MarcoAurelio (talk) 11:06, 23 August 2018 (UTC)

  Link to discussion on enwiki. Ping @Jo-Jo Eumerus so he can comment whether he knows the bug still exists or was fixed already. Thank you. —MarcoAurelio (talk) 11:16, 23 August 2018 (UTC)

  It still exists, I have tested it in my own user namespace. But I do not consider it to be a blocker. This is a highly monitored wiki, the users are trusted not to be vandals, and that a MassMessage sender's account is being hacked is just as likely as a hack of any admin account. Also, MMS are not many in terms of numbers. --Vogone (talk) 11:35, 23 August 2018 (UTC)

  (Edit conflict.) Well I'd say it's quite unfortunate that it still exists given the security concerns, moreover when those were recently exploited to hack into accounts with elevated permissions. Do we have a ticket for this? (there might be some in the security corner of Phabricator, but I don't have access there). —MarcoAurelio (talk) 14:19, 23 August 2018 (UTC)

• I think the "bug" is that the Special:CreateMassMessageList requires excessive permissions (the ability to change the content model of pages to and from things that have nothing to do with message lists) and that if that could be fixed it would be ideal. — xaosflux ^Talk 11:55, 23 August 2018 (UTC)

  Looking at SpecialCreateMassMessageList.php, removing the 'editcontentmodel' requirement would be a rather easy task. @Legoktm: Is there a reason for the requirement to have 'editcontentmodel' on that special page which we have not seen, yet? Removing it might indeed be the easiest solution to this problem. --Vogone (talk) 13:18, 23 August 2018 (UTC)

  (Edit conflict.) As I've said avove in small letters I feel this should be the prefered option if at all achievable. —MarcoAurelio (talk) 14:19, 23 August 2018 (UTC)

  Perhaps just change that check to 'massmessage' instead? After all we allow special workflows to create non-wikitext pages in general. — xaosflux ^Talk 14:14, 23 August 2018 (UTC)

  Currently it checks for 'edit', 'create' and 'editcontentmodel'. In my opinion, there is no need to restrict it to 'massmessage', since it has nothing to do with the actual delivery and thus is not dangerous for someone to test/prepare his delivery list before applying for MMS rights. --Vogone (talk) 14:22, 23 August 2018 (UTC)

  I'd support that as "option 2" (and not something special here on meta, but the default). — xaosflux ^Talk 14:43, 23 August 2018 (UTC)

• As for this specific task, the access being requested appears to be overkill for the usecase calling for it, I'd rather see a use case solutions from phab:T92795. — xaosflux ^Talk 00:06, 24 August 2018 (UTC)
• Oppose editcontentmodel as it unnecessarily raises security implications with javascript. Allowing CreateMassMessageList is a much better solution. As an additional note... if I recall correctly... the issue was very easily solved on EnWiki. I believe an admin simply created a large batch of empty MassMessageLists, and anyone could take (page move) an empty list as needed. Maybe I'm missing something, but this seems like Mount Molehill. Alsee (talk) 00:46, 24 August 2018 (UTC)
• I think the problem here is that the "editcontentmodel" permission lumps a number of things with disparate implications under the same permission. Changing a page from wikitext or JSON to JS or CSS and back just does not have the same implications as changing a page from wikitext to MassMessage. Perhaps splitting the permission into a "change content model except to and from CSS and JS" and "change content model to and from CSS and JS" makes sense. Jo-Jo Eumerus (talk, contributions) 07:29, 29 August 2018 (UTC)
• Oppose in favor of phab:T92795 fixing this condition instead. — xaosflux ^Talk 14:13, 19 September 2018 (UTC)

Possible in-wiki changes to MediaWiki messages?

There are 4 MediaWiki messages on this project that are related to MediaWiki:Blockedtext and MediaWiki:Abusefilter-warning, of which they are very plain and not using formats equivalent to Blockedtext and Abusefilter-warning:

• MediaWiki:Autoblockedtext: No link to information about autoblocks; doesn't provide additional information and alternate ways to bypass autoblocks.
• MediaWiki:Abusefilter-disallowed: No link to Meta:Requests for help from a sysop or bureaucrat to report false positives if a disallow-only filter has been triggered. This plain version would apparently bite the newbies.
• MediaWiki:Abusefilter-degrouped: Same as Abusefilter-disallowed.
• MediaWiki:Abusefilter-autopromote-blocked: Same as Abusefilter-disallowed.

The three Abusefilter messages listed here should have used a format deliberated from Wikipedia.

There were a few edit requests for more stylized versions of these MediaWiki message, but have been declined as a result of no advice for consensus. This is because that the actual pages do not exist, and if they was not created, they would use the default text for non-customized versions.

The following codes were used for these edit requests, which will be proposed here (results are shown below the code for each message):

Autoblockedtext

Abusefilter-disallowed

Abusefilter-degrouped

Abusefilter-autopromote-blocked

I think the interface editors wanted to keep the plain versions of these message because they would look very nostalgic for Meta-Wiki.

Raising the discussion, would it be possible to implement these changes rather than retaining the text-only messages? 2600:1700:A2A0:FB50:10F9:9565:352B:1C07 01:05, 30 August 2018 (UTC)

I don't really care for all that here, since we serve users in all languages and I think it will be a royal pain to keep these translatable. — xaosflux ^Talk 03:50, 1 September 2018 (UTC)

Can you present your proposal in a more readily understandable manner? E.g. by putting the old and the proposed new version next to each other in collapsible boxes. --MF-W 14:05, 12 September 2018 (UTC)

Well, it was a little tricky, but I did what the OP did not, and configured it as you requested, MF-W. One technical point is that the originals aren't really surrounded by boxes; I just did that to set them off from anything else.

As far as the actual proposal goes, I think there are actually two separate pieces to that: (1) Should we add some formatting to the standard texts to make them stand out more—but rely on the standard texts because there are translations that already exist? (2) Should we actually change the text copy itself? Doing (1) overcomes Xaosflux's concern.

I don't have a strong feeling one way or the other, though I imagine that at least surrounding the message in a box to help it stand out would be useful, if that doesn't already happen. StevenJ81 (talk) 15:34, 21 September 2018 (UTC)

Inactive local bots

Hello. We currently have several inactive bots. I'd like to ask whether the community thinks bots inactive for N ammount of time should have their flags removed. I'm for one year of continued inactivity with previous notice to the bot operator before taking the permission from the bot. Regards, —MarcoAurelio (talk) 13:12, 17 September 2018 (UTC)

I don't see a need for this, as long as the tasks for which the bots have been approved are still valid. I see no point in the bot operator having to ask for yet another bot approval for the same tasks should their operators intend to resume them. --Vogone (talk) 13:50, 17 September 2018 (UTC)

On Ladino Wikipedia and Incubator, I was able to deflag several bots that had been inactive three years and longer, most of which were principally dedicated to adding or removing interwiki links. (I got community approval, and provided notice, before doing so, of course.) That's technically still a valid task, but in general the task is complete now. Why not start there, and see where it leads you? (And you could make the caveat that any bot deflagged under this notice can have the bot reactivated on operator request only, provided the operator is in good standing.) StevenJ81 (talk) 15:33, 17 September 2018 (UTC)

I think it is useless to inactive bots to keep their flags, as they are not clearly doing any tasks. In case of a bot returns to activity, the operator may request bot approval again, and the fact that it previosuly had the flag, wouldn't make it hard to get it again. One year is effective for me too, notifying the operator about this. Esteban16 (talk) 02:44, 19 September 2018 (UTC)

I don't think we have any "read" bots that are only here for highapi access, but we are a bit lower volume so I'd rather see 2 years on this. — xaosflux ^Talk 13:48, 19 September 2018 (UTC)

Severely inactive batch

• Some of these are severely inactive, I suggest de-flagging the following in a week barring a response from their operator here:

Bot	Last Edit	Operator
SanniBot	20130926	Stryn Sannita
Thehelpfulbot	20130828	Thehelpfulone
AvocatoBot	20130724	Avocato
FischBot	20130622	Pyfisch
Snowbot	20130305	Atcovi Snowolf
TranslationsVolBot	20121030	No current operator - WMF former staff
BOTijo	20120505	Emijrp
DougBot	20111219	Doug
Lucia Bot	20110821	Beria
SoxBot	20080724	Soxred93 (X!)
Millbot	20060223	Millosh
DrTrigonBot	Never (requested in 2012)	DrTrigon

— xaosflux ^Talk 13:44, 19 September 2018 (UTC)

You can de-flag my bot BOTijo. Emijrp (talk) 13:50, 19 September 2018 (UTC)

Done, thanks for your reply. —MarcoAurelio (talk) 20:47, 19 September 2018 (UTC)

SanniBot is not my bot. Stryn (talk) 14:31, 19 September 2018 (UTC)

@Stryn: thanks for the note, looks like bad template placement on that page and a revisionuser hack from Template:Bot!, updated accordingly to User:Sannita. — xaosflux ^Talk 14:57, 19 September 2018 (UTC)

Snowbot isn't operated by Atcovi either (Snowolf instead, as it can be seen in the permission request). It seems the bot template simply takes the last editor of the bot's user page as "operator" unless otherwise specified. --Vogone (talk) 15:17, 19 September 2018 (UTC)

Fixed to User:Snowolf. — xaosflux ^Talk 15:24, 19 September 2018 (UTC)

You can de-flag my bot as well, even though I see no point in deflagging it just because inactive. --Sannita - not just another it.wiki sysop 15:37, 19 September 2018 (UTC)

Done, thanks for your reply. —MarcoAurelio (talk) 20:47, 19 September 2018 (UTC)

Deploy FileExporter to Meta

Hello. This is a request to deploy mw:Extension:FileExporter on Meta-Wiki. The extension allows users to transfer files from Meta to Wikimedia Commons. It'll help me reducing the backlog of freely-licensed images that we host locally to be moved to Commons instead of doing so by hand, as I've been doing. This extension is enabled in arwiki, dewiki, fawiki, kowiki, mediawikiwiki and sourceswiki. Thanks, —MarcoAurelio (talk) 10:59, 19 September 2018 (UTC)

• I'm going to ping @Lea Voget (WMDE) just in case she has any objections. —MarcoAurelio (talk) 11:02, 19 September 2018 (UTC)
  • I've sent her an email. —MarcoAurelio (talk) 11:50, 19 September 2018 (UTC)
    • I've received her reply. She said there are no objections so as long as the community doesn't object in the next days I'll code a patch for enabling the feature here. Thanks. —MarcoAurelio (talk) 18:59, 20 September 2018 (UTC)
• Provided the extension is stable enough, sure. Let's do it. --Vogone (talk) 11:13, 19 September 2018 (UTC)
  • I've used the feature at mediawiki and in my experience is working well. —MarcoAurelio (talk) 11:50, 19 September 2018 (UTC)
• I concur with what Vogone said above. --Steinsplitter (talk) 11:37, 19 September 2018 (UTC)
• Sure, IIRC it doesn't actually "do" anything "on meta" so its not really risky. — xaosflux ^Talk 13:46, 19 September 2018 (UTC)