Meta:Babel

From Meta, a Wikimedia project coordination wiki
(Redirected from WM:BABEL)
Jump to navigation Jump to search
 ← 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
This box: view · talk · edit
Filing cabinet icon.svg
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[edit]

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[edit]

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 consensus being established following the minimum discussion time as determined by our bureaucrats.
    Unless the request specifies otherwise, no expiration date on grants.


Discuss[edit]

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)
Emoji u1f600.svg 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)

Allow 'snowball' closures of unsucceeding requests sitewide[edit]

Hello. I am proposing that Meta:Snowball be amended. Please find the details at Meta talk:Snowball. Thank you. —MarcoAurelio (talk) 09:53, 14 August 2018 (UTC)