Wikipedia talk:Interface administrators

This is the talk page for discussing improvements to the Interface administrators page.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

WT:INTADMIN

Archives: 1, 2, 3: 30 days

Explicitly mention that Bureacrats have/can grant Interface admin rights?

According to User:Izno, 'crats can grant interface admin rights, but this page doesn't mention that anywhere that I could easily see. I would have directly fixed it myself, but am not deeply familiar with the permissions or implications. ~ 🦝 Shushugah (he/him • talk) 23:04, 8 June 2022 (UTC)[reply]

@Shushugah It is the second bullet on Wikipedia:Bureaucrats already; this page is similar to Wikipedia:Administrators in the regard to how it explains things. — xaosflux ^Talk 00:31, 9 June 2022 (UTC)[reply]

Clarify the right can be refused

Per my comments at BN the existing policy imposes a waiting period without actually granting bureaucrats the ability to say no, or defining when they can. To clarify that issue, I propose adding the following text to the policy: The request will remain open for 48 hours for first-time requests, and if there is community consensus against granting, bureaucrats may decline to grant access.

Don't think this needs a formal RfC, but not going to update without starting a discussion. TonyBallioni (talk) 00:47, 16 June 2022 (UTC)[reply]

(see Special:PermaLink/1093342938) It should be for "at least" 48 hours, the # of hours isn't capped. These typically don't get much advertisement, etc - so I don't expect there to be much of a gauge of "community" consensus that would need to arise to defeat it in such a short time. I'd like to not make this too "bureaucratic", something along the lines of if a 'crat has concerns, then an additional/extended consensus discussion should occur. Keeps the expectation that the default is YES, leaves a safety valve, but ultimately puts it in the hands of the community. — xaosflux ^Talk 00:57, 16 June 2022 (UTC)[reply]

Yeah, I'm fine with whatever and agree with what you're saying. I just don't think we've ever had one opposed before, even by a crank, so worth clarifying that there's a way for it to be refused, so I think we should at least say something relating to that somewhere. TonyBallioni (talk) 01:00, 16 June 2022 (UTC)[reply]

Even if it's perhaps against my personal interest, I support both the basic idea of the clarification ('crats should have some discretion) and Xaosflux's interpretation. {{Nihiltres |talk |edits}} 01:27, 16 June 2022 (UTC)[reply]

Hmm, I'm not sure this is needed. The current policy states: All editors may discuss the applicant, but the final decision rests with the reviewing bureaucrat. I interpret that to mean that individual bureaucrats may accept or decline any request at their discretion, regardless of what the community-at-large thinks (although I'm sure bureaucrats would not deliberately ignore a clear community consensus). This is similar to how WP:PERM operates: regardless of what people comment, the final decision on requests is by the reviewing admin. The proposed wording seems to restrict the ability of bureaucrats to decline only to situations where there is community consensus against granting, so it seems like this change would have the effect of limiting what bureaucrats can currently do. Mz7 (talk) 01:47, 16 June 2022 (UTC)[reply]

I think that 'crats should have the discretion to decline a request, either based on the community comments or their own findings. I support any changes or clarifications needed to implement that. If it turns out an RFC is needed, please ping me as I don't anticipate watching this discussion. Thryduulf (talk) 02:00, 16 June 2022 (UTC)[reply]

I feel that "the final decision rests with the reviewing bureaucrat" is fairly explicit that a Crat can either grant or refuse the request. And the grounds for refusal are given in the Background section. If a user meets the criteria: "highly trusted, have at least a basic understanding of JS and CSS, are aware of the privacy expectations of Wikimedia wikis, and have a decent understanding of how to secure their accounts" they will be granted the right, if they fail in one of those criteria they will be refused the right. There is a discussion as to if Nihiltres can be trusted given that they made a mistake; and the consensus is that they can be trusted because they cleaned up their mistake and have made no others. The process seems to be working fine. If people wish to amend the wording to make it clearer, they can do so; as long as they are not altering the implications of the wording then there is no need to seek consensus. Wording such as: "If the consensus is that the administrator is not highly trusted, or does not have at least a basic understanding of JS and CSS, or is not aware of the privacy expectations of Wikimedia wikis, or does not have a decent understanding of how to secure their accounts, then the right will not be granted" could be added for clarity.

I agree with Xaosflux that "at least" should be added before "48 hours". As it stands it could be interpreted that after 48 hours the request is automatically closed, and if the request has not been granted, it could default to not being completed, so a fresh request would need to be made. SilkTork (talk) 02:04, 16 June 2022 (UTC)[reply]

Should it be "grant if there is consensus" or "don't grant if there is consensus against"? and if there is community consensus against granting, bureaucrats may decline to grant access. could be interpreted as "bureaucrats must grant if there is no consensus". Jo-Jo Eumerus (talk) 10:54, 16 June 2022 (UTC)[reply]

@Jo-Jo Eumerus similar to WP:PERM we don't normally have a consensus measuring discussion around these, the prior RfC consensus leaned towards 'crat discretion; just like if I declined someone at WP:PERM - if a consensus arrived via discussion some other admin would do it. — xaosflux ^Talk 13:40, 16 June 2022 (UTC)[reply]

"the final decision rests with the reviewing bureaucrat" feels pretty unambiguous to me. It feels like a normal item that you would get at WP:PERM, with an added previso of at least 48 hours given for the community to comment if there is reasons to deny. Whilst WP:BN isn't the most trafficked place, it certainly gets enough views to know if the community as a whole has reasons to deny the request. If the time is a big deal - make it a week. Requests at WP:PERM only require the closing admin to see if the user can be trusted and other users can weigh in on the request. Although, and if there is community consensus against granting, bureaucrats may decline to grant access, this suggests to me that a crat wouldn't have a choice but to award the perm if there was no further discussion about it. Lee Vilenski ^{(talk • contribs)} 11:27, 17 June 2022 (UTC)[reply]

We are volunteers, so we always have a choice.

The default is that the right will be given as long as there are no objections because the right used to be part of every admin's toolkit. It was decided (not by the community if I recall, but by WMF) that letting every admin, including those randomly appointed by Jimbo way back when, have access to the tool might be problematic. While more recently appointed admins would be deemed to have the common sense not to switch on the chain saw if they didn't know how to use it, there was clearly a suspicion by WMF that some of the early admins were idiots. As such the situation is that an admin has to request the tool, and that request should in itself be sufficient to allay any concerns - however, just to be sure, there is a 48 hour hold so people can come forward with evidence that the admin is in fact an idiot. If nobody does come forward, we can simply flick the switch (or leave it for somebody else if we don't fancy it, or don't understand the implications).

By policy we are not allowed to give ourselves the right, though technically we can. It's kind of interesting that we are trusted enough not to give ourselves the right, but not trusted to give ourselves the right. I assume it is simply an error that we have been left with the ability to grant ourselves the right. SilkTork (talk) 13:31, 19 June 2022 (UTC)[reply]

@SilkTork it is mostly that it is extra layers of technical controls that would be needed to also add in a "but not to yourself" check that aren't really necessary - if someone with granting access was up to no good could they could just give access to an alt account and bypass the whole thing anyway. — xaosflux ^Talk 13:48, 19 June 2022 (UTC)[reply]

I agree with your generally process overview - basically if a processing 'crat declines it can be a subtle statement of "it's possible that you actually are an idiot", of which other 'crats can overrule by just granting it (especially following some community input). — xaosflux ^Talk 13:50, 19 June 2022 —(UTC)

On a side note, the MediaWiki developers provided the capability, but left it up to the local wiki communities to decide on how to assign the privilege (see Wikipedia:Village pump (miscellaneous)/Archive 59 § New user group for editing sitewide CSS/JS and m:Creation of separate user group for editing sitewide_CSS/JS). All the decisions on the granting process were made by the community (see the archives for this talk page). isaacl (talk) 16:28, 19 June 2022 (UTC)[reply]

You'll know more about this than me isaacl. My understanding is that the right already existed within the admin toolkit, but that the "MediaWiki developers" (I'm not quite sure where they stand in the Wikipedia world, but as they are MediaWiki - which is a part of WMF - I tend to think of them as part of WMF rather than Wikipedia, though I think that is possibly a murky area - are some developers volunteers and some paid by WMF?) took the right away from Wikipedia admins because they decided it was a security risk. My understanding (and please correct me if I am wrong), is that this was done without consultation with the Wikipedia community. My understanding (and, again, correct me if I am wrong - this is not an area I tend to get involved in) is that the Wikipedia community then looked at a way for the right to be restored to admins, and the consensus was that the right could be restored on application with a simple 48 hour pause to see if there were any objections. Essentially, every admin on Wikipedia could apply for the right and, pending nobody declaring that any of them were idiots, it could be given to them. We could, in theory, restore the right to every admin on Wikipedia in a 48 hour period. And, I suppose, the "MediaWiki developers" (WMF?) would be perfectly OK with that as we would have followed the agreed Wikipedia procedure. Or, do you suspect that there would be an objection because there would be a risk that some of the admins are not to be trusted (by the WMF, as I assume they are trusted by the community otherwise they would not still be admins)? SilkTork (talk) 18:13, 20 June 2022 (UTC)[reply]

@SilkTork tangentially related, WMF (the owners of the servers) require that anyone that wants int-admin must use 2FA - so all those admins would need to activate that first. — xaosflux ^Talk 18:52, 20 June 2022 (UTC)[reply]

While I wouldn't have been surprised if this were the case, the only guidance I can find came from Tgr in their role as a MediaWiki developer. As far as I recall (and as I can see in a quick skim of the archive), there was consensus support on English Wikipedia for requiring two-factor authentication for interface admins, in recognition of the extreme power of being able to cause malicious Javascript to run within user browsers. isaacl (talk) 20:55, 20 June 2022 (UTC)[reply]

The 2FA is a global requirement for every project, there are a few roles requiring it - see the banner at meta:Interface_administrators. — xaosflux ^Talk 22:21, 20 June 2022 (UTC)[reply]

Thanks for the reference; that makes sense to me. I see that the note was added in December 2018, after the granting process had reached consensus here. isaacl (talk) 22:59, 20 June 2022 (UTC)[reply]

The meta page I linked to has links to the corresponding Phabricator ticket and wikitech mailing list discussion. As far as I can tell, Tgr created the feature on their own initiative in order to improve security, which involved creating a new user privilege (which yes, made it possible to keep admins from editing the site-wide Javascript and CSS pages). It's true that the MediaWiki developers considered the rollout to be under their purview, as a security matter, and so only held what was in essence an advisory consultation on meta. Wikipedia talk:Interface administrators/Archive 2 § RfC: Approving the updated proposal has the English Wikipedia discussion for the final process (replacing the stop gap process, which the community put in place to ensure that someone would able to edit the pages in scope during the interim) which did, as you stated, approve a process where "[b]ureaucrats are authorized" to grant the interface administrator permission upon request after a 48-hour waiting period. Whoever is responsible for security at the WMF might have opinions, but as far as I can tell, the community remains free to decide for itself on the process. isaacl (talk) 21:32, 20 June 2022 (UTC)[reply]

This seems fine (both the original proposal, and the "at least" for the time). More specifics beyond that required seems unneeded, but TB is right that best to have a "why do we need this" then need to hash out the changes at the same time as the problem. Nosebagbear (talk) 12:34, 24 June 2022 (UTC)[reply]
I'm okay with the proposed change to the wording of the policy for clarity purposes; I see no harm in making details more clear if they seem to be ambiguous, and adding a WP:SNOW clause to the policy's wording seems reasonable. I agree with what Nosebagbear stated above, in that "[m]ore specifics beyond that required seems unneeded, but TB is right that [it's] best to have a 'why do we need this'". ~Oshwah~^{(talk) (contribs)} 02:52, 4 July 2022 (UTC)[reply]

RFC: Increase inactivity requirement

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia policies and guidelines

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Proposed:

In: Interface administrators who have made no edits or other logged actions for at least 2 months or who have made no edits using the permission for at least 6 months should have the user right removed.

Change to Interface administrators who have made no edits or other logged actions for at least 2 months or who have made no edits using the permission for at least ~~6 months~~12 months should have the user right removed.

Recent discussion: Special:PermaLink/1200817440

Proposed reasoning: interface-admin actions are not very high, but are generally productive. For editors that are still generally active, but have less frequent interface updates having them have to re-request when needed is counterproductive. We currently have <10 int-admins, and this change is not expected to cause us to have 'too many' as the total-inactivity threshold is still low.

Support

As proposed. — xaosflux ^Talk 11:23, 30 January 2024 (UTC)[reply]
I have no problem with the proposed change. The 2 month requirement could be seen as unnecessarily stringent too — Martin (MSGJ · talk) 12:20, 30 January 2024 (UTC)[reply]
Support Per what I said in the other discussion about being an infrequent user as a gadget maintainer and there being very few intadmins. Galobtter (talk) 14:01, 30 January 2024 (UTC)[reply]
Support - Also why do we have a two-month requirement? It seems WAY too strict. I think that editing requirements more similar to WP:INACTIVITY would better suit interface administrators: (1) Has made neither edits nor administrative actions for at least a 12-month period. (2) Has made fewer than 100 edits over a 60-month period. Somebody tell me why this wouldn't work supposing (2) were bumped up to 1000 edits or so. Schierbecker (talk) 17:03, 30 January 2024 (UTC)[reply]
Support, though I'm fine with the 2-month general inactivity requirement. It's hard to overstate how potentially dangerous the intadmin right is, so it makes sense to remove it at the first sign of overall inactivity. It's just that use of the intadmin bit itself doesn't really come up super often, so the tool-use requirement needs a bit of calibration. Writ Keeper ⚇♔ 17:12, 30 January 2024 (UTC)[reply]
Support. I think there are multiple intadmins whose primary activity is to be the maintainer of a major gadget. Updates to that gadget can go more than 6 months without a deploy sometimes, so it is easy to lapse intadmin. {{IAER}}s aren't always great for updating major gadgets either. Sometimes the gadgets have custom deploy scripts that only one or two people know how to use. –Novem Linguae (talk) 17:31, 30 January 2024 (UTC)[reply]

Oppose

Discussion

An important balance for security is that we should not have too many of these users, and the current requirements were built along those lines. It has been quite some time now, and we are not seeing administrators using this role as some sort of hat-collection (not surprised, as we don't expect that sort of behavior from our admins...). Some of our int-admins deal with infrequent issues such as maintaining certain gadgets. — xaosflux ^Talk 11:30, 30 January 2024 (UTC)[reply]
Are we restoring rights to intadmins (if any) who lapsed under the six-month policy but never fell afoul of the new proposed policy? Schierbecker (talk) 17:53, 30 January 2024 (UTC)[reply]
Given that they could already just ask for it back at BN, I doubt that's necessary. Writ Keeper ⚇♔ 17:58, 30 January 2024 (UTC)[reply]
Agreed. I think keeping the rfc simple and as-is is a good idea. –Novem Linguae (talk) 17:59, 30 January 2024 (UTC)[reply]