Welp, consensus is pretty divided on this one so it is my assessment that non-admins will not be allowed to request access to interface administrator at the this time.—CYBERPOWER(Chat)20:42, 16 October 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm hosting a brief 714-day straw poll on whether or not we should allow non-admins to request access to the permission. In the previous RfC, I boldly set up a process for non-admins based on comments in the RfC. At this time non-admins cannot request access, but because a process now exists, my question becomes, should we allow non-admins access?—CYBERPOWER(Chat)23:20, 2 October 2018 (UTC)
Process: The user will make a request, at the correct venue, to request access to the permission. The applicant will be required to leave a notice at WP:VPT, WP:BN, and WP:AN. Applicants are encouraged to answer the following two questions:
Please describe any relevant on-wiki experience you have for this role.
Please outline, without breaching your personal privacy, any off-wiki experience or technical expertise you may have for this role.
The request will be open for one week for all editors to comment on regarding the user's technical competence, trust, and suitability to holding this permission.
After one week, minimum, has elapsed, the reviewing bureaucrat will assess the consensus of the discussion, and grant access if support is around 75%, or higher.
Duration of right: Should be temporary, default 6-months, unless requested.
I don't know that I see a compelling reason to treat it terribly differently than c:Commons:Translation administrators (other than the basic point of removing for sysops who don't have the requisite need/skills for vulnerability reasons). Some sysops will have the needed skills, and some non-sysops will also. In both cases it's a very small minority of the whole. I don't see why, for the handful of users that would qualify, you would need to understand speedy deletion criteria or the username policy in order to computer on an advanced level. The same way that having fluency in another language is not a prerequisite for being a sysop on Commons, but it's also not a barrier to using that knowledge to help the project if you are willing and able. GMGtalk00:42, 3 October 2018 (UTC)
Only active template editors and active bot operators (active in 6 months) (both requirements) This right is unlike edit filter managers. And over 99% editors excluding template editors or bot operators cannot know how to write a script very well and they do not know how script works. If they want this rights, they can request template editor rights first then request Interface administrators right. If we are open to all non-admins, it will waste our time to !vote. So only expand to template editors and bot operators and template editors and bot operators are mostly highly trusted and it should be active recently Hhkohh (talk) 23:31, 2 October 2018 (UTC)
(edit conflict × 2) @Hhkohh:over 99% editors excluding template editors cannot know how to write a script very well and they do not know how script works. I'm pretty sure many non-admin bot-operators (had to use programming script to make it) are not template editors, so I think what you said isn't true. SemiHypercube✎23:47, 2 October 2018 (UTC)
@Hhkohh: Is this right really that much unlike edit filter manager? I mean, both edit filters and sitewide JS/CSS affect the whole site, but I do see the difference. (edit filters affect only the editors, whereas sitewide JS/CSS affects all users and could possibly do stuff like install malware in the hands of a compromised account) Even if we do open this right to non-admins, we'll probably still have only about 20 or so users with this right, rather than the ~1200 accounts that used to be able to edit it, so a reduction to 1.6% of the potential attack area is still significant. SemiHypercube✎00:52, 3 October 2018 (UTC)
Strong yes. RfA is not the only way to determine trust. I should not have to be active in admin areas to get this permission. RfA is totally unsuited for being a prerequisite for this permission; most of what's needed to pass an RfA has absolutely nothing to do with being an intadmin. If we wanted to establish a very high bar for this new process, nothing's stopping us. Strongly agree with what GMG said, even though (at press time, anyway) he has struck his comment. Enterprisey (talk!) 03:57, 3 October 2018 (UTC)
Yes does anybody remember Cobi's RfA(s)? This guy was/is friggingly trusted. It was clearly mentioned in his nominations that he will use his tools only in technical parts, more like a sys-op than an "admin". Yet there were opposes based on "no content creation" and similar stuff. If you are worried about trust, make the new process thoroughly scrutinising. This is simple: does a candidate have the ability to handle/use it? Is he trustworthy? If yes to both, then give him the perm. At WP:PERM, gor granting NPP, experience with page moving and a little demonstration of page moving policies is required. NPP requires more trust than PGM, but there is no policy stating "only PGMs can become NPPs". —usernamekiran(talk)12:34, 3 October 2018 (UTC)
Yes. I see a flaw in the argument that RfA should be required to show the required trust in that RfA is judged on a candidate's suitability for doing general admin things and requires demonstration of relevant experience. Someone judged to not have enough experience of AFD, CSD, AIV, etc will not pass RfA, even if they are perfectly competent and trustworthy for doing "Interface admin" stuff. Boing! said Zebedee (talk) 16:08, 3 October 2018 (UTC)
Yes - competence with this technical area is not evaluated at RfA, only trust is. In line with the process used for EFM, I don't see how some untrusted non-admin would be able to pass a request for IntAdmin. Also RfA is one of the worst parts of this project, so we should be deprecating it as much as possible. -- Ajraddatz (talk) 16:17, 3 October 2018 (UTC)
Yes I expect that a non-admin would need to pass a high bar of need, competence, and especially trust in order to be granted this right, but I don't see any reason to hardcode adminship as a de jure requirement. Also I am not a fan of hierarchization of special permissions in the form "interface-admin > admin"; they are non-commensurable permissions sharing a common requirement of being trustworthy. Roughly speaking, being an admin requires trustworthiness + competence/experience/interest in content and adminning areas + demeanor, while interface-admin permission demands trust + technical competence + need/interest in interface-editing. An editor (at least in theory) can meet the latter bar even without having an interest in regular adminship and we shouldn't just bar candidates who meet (and can show that they meet!) the actual requirements for this permission from even applying. Abecedare (talk) 04:21, 4 October 2018 (UTC)
Yes - There are two basic criteria for this right:trustworthiness and competence. A RfA is not necessary to show either. I do not want to deny editors like Enterprisey Iadmin because they haven't written a FA, or misjudged a couple of AfD's. The opposers make the claim that Iadmin is a higher bar than adminship. It's not. It's a completely different bar. I trust admins to close a controversial discussion. I trust Iadmins to inspect code to ensure it's safe. The tasks are way different, and should not be piped through the same (broken) process. Tazerdadog (talk) 06:01, 4 October 2018 (UTC)
Yes. My initial reaction is as per many of the No's. The whole point of removing it from admins are for security so that a smaller number than the 1,200 admins have access and only if they're generally going to need it, so it doesn't make sense to be giving it to non-admins. However, the proposed process is a RFA-like process, the only real difference is location of the discussion. Since the rights have been split off, I'm not adverse to someone being able to request access to only those rights they need instead of having to go through an RFA and all that entails. -- KTC (talk) 14:43, 4 October 2018 (UTC)
Per your link, Meta seems to require a Meta-RfA for this privilege, which apparently also takes a week and needs support of over 75% of the participants. How is this different from the "no" votes requiring an RfA as well? ~ ToBeFree (talk) 17:14, 4 October 2018 (UTC)
On Meta, RfA is used for requesting most advanced permissions (sysop, intadmin, central notice admin, CU, OS, crat, etc). The Meta process requires a week-long discussion for non-admins, in-line with what is used for EFM here and what us supporters would also like for intadmin. -- Ajraddatz (talk) 18:05, 4 October 2018 (UTC)
Yes we should accept trustworthy community members even if they don't want the block button. Yes, we'll need to determine whether they're actually trusted. Yes, there should be scrutiny. But seriously, we should not make "willing to undergo RFA" or "willing to retain an admin bit" be a requirement. There is no practical reason why every single iadmin should be required to hold both bits, and if someone wants one without the other, then that's okay with me. I hope that nobody is seriously objecting to this out of a belief that a candidate's suitability must be scrutinized at a page that is called "RFA". We're not supposed to be a rigid bureaucracy here. What matters is that scrutiny happens and trust is determined to be present, not exact page where the scrutiny process is written down. WhatamIdoing (talk) 19:44, 4 October 2018 (UTC)
Yes - An entirely different skill set from that which is needed for simple adminship. An interface administrator should be familiar with coding in CSS and JavaScript. The approval process should be separate. Kurtis(talk)23:17, 4 October 2018 (UTC)
Yes RfA is too wide-ranging of a political issue to apply to int-admin. No one would pass RfA with the claim that they need access to js/css pages. Chris Troutman (talk)23:53, 4 October 2018 (UTC)
Yes. We have many good editors who are more technically competent than they are socially savvy. Allowing users to hold IAdmin without Sysop makes it possible for us to trust good editors with the interface without miring them in the mine-field of the block, delete, and protect buttons. Deryck C.11:40, 5 October 2018 (UTC)
The level of scrutiny would be similar to RFA, but less political. It looks like some people are opposing based on the Wikipedia:Interface administrators#Process for requesting for administrators and haven't read what is actually being proposed. Or would an editor be unsuitable for this because they have supported or opposed too many deletions, or have criticised too many of your administrative decisions? Peter James (talk) 17:47, 5 October 2018 (UTC)
Yes. There are some admins that I wouldn't trust to protect a page correctly, let alone edit the interface. Those opposing this speak as if every user will have this right. It is very clearly for the few and far between cases where non-admins have become clear assets to the community that lacking this right would impede their ability to contribute. Putting it at a step beyond RfA is essentially saying you must be a content creator in order to edit the interface pages. Surely everyone can see the ridiculousness of that. Nihlus18:24, 5 October 2018 (UTC)
Yes There has to be a good compromise that can be achieved here so non-admins that know what they are doing and are very trustworthy that don't want to be admins can apply for this user right if that is the only thing they want to help out with. Someone like Enterprisey (who I've never met) but seems to be very trustworthy shouldn't have to become an admin if all they want to help out with is the interface-admin group. I think there should be some sort of application/process a non-admin should go through to get this right and as a community I'm sure there can be some pre-requisites that we can agree on that would drastically limit the number of potential eligible non-admins. The closest example we have currently to this would be edit filter manager right and that has about 14 non-admins. I'm sure this right wouldn't exceed that number considering only 12 admins currently have this right. At least we should give it some sort of limited trial. ♪♫Alucard16♫♪13:01, 6 October 2018 (UTC)
Yes The edit filter is also a sensitive area that we let non-admins work in. I certainly agree with the sentiment that this is more sensitive but given its also more technical nature there are some slim number of users for whom it would be appropriate to grant this role. Certainly would need more scrutiny than admins who request the right but shouldn't be a complete dealbreaker. Best, Barkeep49 (talk) 17:46, 6 October 2018 (UTC)
Yes on principle, no to this specific proposal I believe that setting up an process would encourage more people to request this right, and may lead to more people having it than is good from a system security perspective. I think we should be willing to ignore all rules in exceptional cases like Enterprisey, but our policy should not set forth a specific process for giving out this permission nor create a parallel RFA process. I would prefer a line be added to the policy stating something like "In exceptional cases, highly qualified non-admins may ignore all rules and request the right. A bureaucrat may grant the right if strong consensus exists to ignore the typical requirement of adminship." I believe this reinforces the fact that this policy doesn't trump IAR, but that grants under it should be rare and hard to achieve without a level of trust similar to RfA. Wugapodes[thɔk][ˈkan.ˌʧɻɪbz]22:33, 6 October 2018 (UTC)
Yes, though open to strengthening - I think this is a reasonable proposal, however clearly there are trust issues. Thus I'd suggest we strengthen as much as possible the requirements short of requiring an RfA which can fail for non-trust reasons. Whether this be the mild version of a requirement Interface Admin nominator I've mooted below, complete agreement from every IA etc I'd like to see Nosebagbear (talk) 01:26, 7 October 2018 (UTC)
Yes, although I don't see why the right has to expire so quickly. Requiring renewal every 6 months is a pain. Granting it for a year seems more reasonable. I agree that there's no reason this needs to be tied to adminship. Interface administration is a technical task which is quite different than regular admin tasks and needs different qualifications. Kaldari (talk) 20:55, 11 October 2018 (UTC)
Yes. If a non-admin would clearly make good use of the tools, it seems silly for me to have to make them go through RfA to get badgered on content creation, AfD, etc. for the sole reason of requesting a whole separate user right. If we make this a thorough process where the candidate has to answer questions and the community has a week to comment on the candidate's suitability, I see no issue with granting this to non-admins, even if it wasn't the original purpose of the user right.--SkyGazer 512Oh no, what did I do this time?12:29, 15 October 2018 (UTC)
Strong Yes. Sorley required to combat vandalism given the signficant backlog with requesting admin accses, most oppostion seems to be reactionary rather than having a logical argument. Zubin12 (talk) 07:37, 16 October 2018 (UTC)
It's never been available to non-admins before, and given the heightened concern over potential abuse it seems like this would be a step in the wrong direction. I don't see what problem this would solve. 28bytes (talk) 23:37, 2 October 2018 (UTC)
Edit conflict: The quoted text has been modified while I was writing. ~ ToBeFree (talk) 01:13, 3 October 2018 (UTC) Please don't grant this privilege to anyone except administrators. The separation of this usergroup has been done because even in the hands of administrators, the risk of abuse has proven to be too high sometimes. If someone is trustworthy enough to become an interface administrator, they should always do an RfA first. If they get rejected by the community, they should not be able to request this privilege, as the community does not trust them enough to use the "normal" administrator toolset correctly. Also, the privilege could easily, using perfectly valid JavaScript, be abused to gain administrator privileges and to execute any actions in the name of other users. It would just require one script on a single page to automatically force the next visiting bureaucrat to grant adminship to the user, and to block all other administrators from the wiki. It would just require one script to abuse Wikipedia pages for cryptocurrency mining, yielding great irreversible, anonymous profits (see Monero) for the attacker before the script is removed. The reason for the "interface administrator" group's existence is that this has apparently actually happened. "Non-admins should be more trusted"? Trustworthy non-admins should consider becoming administrators. ~ ToBeFree (talk) 00:47, 3 October 2018 (UTC) Update: Striked one sentence per the indented discussion and steward's statement below. Thanks! ~ ToBeFree (talk) 17:32, 6 October 2018 (UTC)
@Xeno: I would like to, and I would have been more specific in the first place if I had a diff or something specific to point to. The problem is that information about the specific incident seems to be hidden from public view, maybe because of WP:DENY considerations or open security issues that need to be fixed first. Here is what I could find:
Phabricator ticket phab:T190015 mentions a hidden ticket, phab:T189665. The public mention contains the following text: "With Javascript editing being just one of the many rights administrators have, most communities do not fully understand its dangers and are not sufficiently careful about assigning it. E.g. relatively low-trust user groups sometimes get (that resulted in T189665 recently), no one is worried about long-inactive admins retaining their privileges, there is very little oversight of small wikis with few active admins etc."
Maybe someone with access to that ticket, when reading this, should please confirm if it is about exactly such an incident. ~ ToBeFree (talk) 16:55, 6 October 2018 (UTC)
The recent security incidents involved an attacker that used compromised admin accounts to make malicious additions to js files. The angle of attack that the individual used to compromise the accounts is no longer usable. The issue has never been with trusted users adding malicious js. -- Ajraddatz (talk) 17:13, 6 October 2018 (UTC)
@Ajraddatz: Thank you very much for the clarification. Has this "malicious"ness of the javascript been indeed associated with privileged API call abuse or cryptocurrency mining? I'm wondering whether my original statement is true. ~ ToBeFree (talk) 17:23, 6 October 2018 (UTC)
Not the situations I refer to. I've heard about something involving cryptocurrency mining, but I believe that is resolved as well. -- Ajraddatz (talk) 17:27, 6 October 2018 (UTC)
Given the comparatively lax granting guidelines, I'm even more strongly in support of this option. RfA, poor though it may be, is our only non-ArbCom mechanism for a baseline level of community trust. ~ Amory(u • t • c)01:20, 3 October 2018 (UTC)
We won't. I was going to reply to your statement in support of this, but I'll do it here: I basically agree with everything you said, except that currently RfA is our best mechanism for establishing a baseline of community-level trust. We can create something analogous, but why? It won't receive the same level of scrutiny, and if it does we've just reinvented the wheel and created two separate tracks. Moreover, I believe most of the support for the current granting policy was of the "sysops are already trusted, they've had this for nearly two decades, etc." variety. Allowing non-sysops goes against that, and represents a broadening of the ability, not a shrinking. ~ Amory(u • t • c)13:41, 3 October 2018 (UTC)
Allowing non-admins access to site-wide JS/CSS is a bad idea. I've said it over and over, but int-admin is literally the most sensitive user group there is. Edit filter management, page deletion, blocking, etc., are trivial in comparison. Technical fluency is obviously a requirement, but that's not what int-admin is about. It's about reducing the number of accounts that have such rights, and for non-admins, there is the larger trust issue. I think we can all agree we don't want another RfA process, but that's what it would have to be. Fortunately, the number of editors who would actually benefit from int-admin is very slim (admins included), and the non-admins I can think of off the top of my head I believe could pass an RfA. The introduction of int-admin is a step forwards, establishing lax granting criteria following the last RfC was a bit of a step backwards (my opinion), but allowing non-admins to have these rights is undoubtedly a leap in the wrong direction. — MusikAnimaltalk01:46, 3 October 2018 (UTC)
No - IA is an even higher responsibility than admin, and should given only to admins. If an editor is trustworthy enough to be an AI, they should be an admin first. L293D (☎ • ✎)12:18, 3 October 2018 (UTC)
As an inherent way to limit access, requiring RfA is easy. We have enough admins with the required skill set. RfA determines if they have the required trust. Opening this up is not required. TonyBallioni (talk) 13:44, 3 October 2018 (UTC)
No. Anyone with access to sitewide javascript could fairly easily insert javascript code that hijacks admin, 'crat, and checkuser accounts to perform admin actions. I'm rarely on the "if we need to trust them for the job, then they can just become an admin" bandwagon, and I'm generally for some unbundling of admin tools, but I think in this case it's a bit different. Since this permission essentially allows the user to perform sensitive admin actions (such as retrieving oversighted text/images or performing checkuser lookups), it should require that they be an admin with full community vetting. --Ahecht (TALK PAGE) 16:05, 3 October 2018 (UTC)
Non-admins have never been able to do this. There is no need for many people to be able to change interface pages and reducing the attack surface is the fundamental rule of security. Protecting the privacy and security of readers and editors is not just bureaucracy. Johnuniq (talk) 00:50, 4 October 2018 (UTC)
No. I believe that it's not just unnecessary, but users with this level of access and to sensitive and critical site-wide pages and the .css, .js, and .json pages of other editors should be those that have been vetted by the community and by consensus trusted with the administrator toolset before access to one of the most sensitive user rights on Wikipedia should be considered. ~Oshwah~(talk)(contribs)01:31, 4 October 2018 (UTC)
Per my alternate proposal, there are too many gaping holes for non-admins to abuse this. Infact, I think not even RfA is sufficient for gaining access to something that potentially sensitive. Kirbanzo (talk) 04:11, 4 October 2018 (UTC)
It's an extremely sensitive right and misuse could have very severe consequences if misused, more than the admin toolkit. We shouldn't be opening this up, particularly under the suggested guideline. The guideline on granting edit filter manager to non-admins says "The assignment of the edit filter manager user right to non-admins is highly restricted. It should only be requested by and given to highly trusted users, when there is a clear and demonstrated need for it. Demonstrated ability that one can and will use it safely is absolutely critical." This applies even more strongly to interface admins. Hut 8.507:02, 4 October 2018 (UTC)
Reluctantly have to agree with ToBeFree, although not about the practicality of RfA. All admins will need to demonstrate competence in JavaScript. Hawkeye7(discuss)00:31, 5 October 2018 (UTC)
No. This is a very advanced user right, offering much more opportunity to wreck the encyclopedia than even an admin enjoys. As such, if we were to open it to non-admins, we'd need some kind of RfA process to be inaugurated to ensure that the applicant had the trust and confidence of the community. And if you're going to have such a process, why not just use RfA itself, since that's an already established process for vetting people, and we don't need a separate one. Plus, if a non-admin goes through RfA purely to do interface admin work, and passes, then we have also gained a new regular admin who might not otherwise have applied. Finally, we have already established that we don't need very many interface admins, and having a small number is vital to reduce the attack surface. The work involved is sporadic and can I believe be handled by the small group of regulars we already have. — Amakuru (talk) 12:06, 5 October 2018 (UTC)
I believe that with the sensitivity of this right, applicants for it should demonstrate broad community trust via a process like RfA—so, why not just use RfA? Even if they primarily plan to do only technical work, it won't hurt them to have the admin tools in addition. At worst they just don't use them, and still no loss to anyone. If someone can be trusted as an interface admin, they also can certainly be trusted as a regular admin. SeraphimbladeTalk to me05:20, 6 October 2018 (UTC)
why not just use RfA? Paraphrasing Nosebagbear below, RfA rejects applicants on factors besides trust that are irrelevant to intadmin work, such as knowledge of deletion policy. Enterprisey (talk!) 17:53, 8 October 2018 (UTC)
While I think the “inherent limiting factor” argument is the strongest (i.e. instead of millions with the ability to request, only 1200 can), your response here shows a lot of the disconnect between technical contributors and the rest of the community: programmers/engineers/devs/[insert title of the day] are a dime a dozen, especially on an open source platform. Who cares if there are great programmers who can’t pass RfA but we should trust with this: there are also plenty of people who meet that description who can and have passed RfA. We lose almost nothing and gain an extra layer of security (the RfA requirement.) In addition to that: if the community can’t trust someone not to hit the delete button, I really don’t want that person to have the ability to have this. That goes directly to trust in the whole person towards the toolkit, which is relevant here. TonyBallioni (talk) 06:09, 9 October 2018 (UTC)
Indeed, and I passed RfA with very minimal AfD and AIV experience because I was able to demonstrate competence, trust and experience in other areas, plus a good volume of content creation. And my stated aim for being an admin was to help out at RM, where I was experienced. It's an interesting question how the community will react to a future RfA in which the candidate stated subsequent promotion to IntAdmin as their reason for needing the tools. I suspect that if their record showed they had the general experience (albeit lacking in some areas), with a smattering of content creation, and general trust and respect, there would not be a problem in today's RfA climate. — Amakuru (talk) 06:20, 9 October 2018 (UTC)
Per MusikAnimal. Comparing with the edit-filter managers situation: EFs don't affect readers who don't edit, but because interface admins can modify things like MediaWiki pages, they can change things for everyone. Consider edits like this and the one that left the whole site looking like the image at right — this is what interface admins can do, so they need vetting similar to (or greater than) what's done for people who want to block vandals and delete copyright infringements. As I said somewhere else, if we have non-admins trustworthy enough to deserve this right, they're also trustworthy enough to get the general admin suite. Nyttend (talk) 21:56, 6 October 2018 (UTC)
I can't think of a person trustworthy enough to edit the interface (which, when abused, is an absurdly crazy power) that is not trustworthy enough to be an admin. —Kusma (t·c) 16:10, 8 October 2018 (UTC)
The dispute would seem to be that RfA removes applicants on factors other than trust that may/would be irrelevant to an Int-Admin Nosebagbear (talk) 17:23, 8 October 2018 (UTC)
Agree with @Nosebagbear:. I feel like why people don't want to request adminship is because passing an RfA often requires content creation, or some other area which is unrelated to their planned area of focus (like why should somebody write good articles or DYK articles if they plan to block vandals or, in this sense of requiring adminship for this right, editing sitewide CSS/JS?) I know that content creation isn't the only thing considered in RfA, but I feel like too much emphasis is placed on it. You don't need the mop to write featured articles... SemiHypercube✎17:44, 8 October 2018 (UTC)
RfA is only about trust. That is the only thing at all being considered there. Just because you don’t like what some people’s standard for trust is doesn’t make it invalid. RfA is the only measure we have of community trust in a user for advanced permissions. And no, some backwater techcabal vetting process will come nowhere close, which is what anything here would amount to. Ask yourself when the last time RfBAG received more than 15 total !votes, and you’ll see what I mean. TonyBallioni (talk) 02:24, 11 October 2018 (UTC)
To me, it's not so much a question of trust as it is one of suitability. Both individual flags require that an editor have the confidence of the community. The thing is, the overwhelming majority of administrators will never save a single edit to MediaWiki interface; most of them wouldn't even know the ins and outs of CSS or JavaScript. A regular administrator needs to possess good communication skills, an in-depth understanding of policy, and sound judgment. These are things that an interface administrator should also possess, but their specific job is narrower in scope and requires some degree of proficiency in programming. I can pretty much guarantee that, barring exceptional cases, interface privileges will likely be exclusively granted to administrators. Kurtis(talk)22:31, 8 October 2018 (UTC)
The way to help change that is to go to WP:RFA, check whether the candidate is being opposed for stupid reasons, and if yes (so most of the time), vote support. Also, don't vote oppose unless you really really really have to (i.e. very rarely). Don't vote to oppose a candidate because you had bad experiences with other people (the mythical block-happy teenage vandalfighter admins were one of the reasons content creation became such a thing at RfA). If you don't feel comfortable supporting, just abstain. Find 100 people who do that, and RfA suddenly is easier to pass. It will stay a stressful experience, but whether the candidate can cope with stress is actually a fairly relevant part of the nastiness of RfAs. —Kusma (t·c) 09:19, 11 October 2018 (UTC)
Well would the proposal below where "Any non-admin desiring to apply for these rights must be nominated by an Admin already possessing Interface Administrator rights" help with concerns? I mean if an admin with the interface-admin wouldn't feel right nominating a non-admin for the interface-admin right that would stop that process dead in its tracks. If an admin with interface-admin rights does nominate a non-admin for these rights then they will be up for community discussion as per the above process. With this in place I highly doubt many admins with this right would stick their necks out for just any non-admin and the ones they do nominate would be rather trustworthy non-admins that just don't want the rest of the admin toolset. ♪♫Alucard16♫♪14:00, 9 October 2018 (UTC)
I'd argue that's a positive. One of the reasons why RfA is so awful is because of the massive levels of participation. Imagine telling someone they're interviewing for a job but it's "no big deal", and then having an interview panel that could fill an auditorium. I imagine that a small group of existing intadmins and technically-minded people could very easily and effectively judge whether someone could be trusted to use this bit well. And maybe do so better than the bloated, arbitrary, and stressful situation that RfA is. -- Ajraddatz (talk) 05:09, 11 October 2018 (UTC)
If we can not trust someone to be an administrator, why would we trust them with even more power? If someone is responsible enough to handle this position, they are certainly responsible enough to become an administrator first. Alternate Side Parking (talk) 22:20, 14 October 2018 (UTC)
I think not. Because of the exploits available with sitewide JS access, users with this right must be highly trusted on the level of admin. Then only admins should have this user right. — Insertcleverphrasehere(or here)12:24, 15 October 2018 (UTC)
Discussion
I think admin vs non-admin is more than enough to go with for now. This bot-op/TE thing is totally uncalled for. Are we kidding with all this bureaucracy? I know a lot of guys who are expert level programmers, but they arent bot-ops/TEs. —usernamekiran(talk)00:54, 3 October 2018 (UTC)
Indeed — while a good technical understanding of python might make you capable of managing (aka using stack overflow) simple css/js responsibly, it's more of a good thing to mention rather than a de-facto qualifier. Template structure is wholly unrelated. It comes down to trust — the community implicitly trusts bot ops and TEs more, hence why it might be relevant. ~ Amory(u • t • c)01:24, 3 October 2018 (UTC)
Usernamekiran does have a point: As a general policy text or specific reason, it would be a strange requirement. A legitimate path to gaining the privilege would then be inventing a little bot and gaining approval for it before personally taking over the world. ~ ToBeFree (talk) 01:29, 3 October 2018 (UTC)
@Hhkohh: Template editors have been able to modify sitewide javascript files before? I did not know that, and was not able to find that information. Could you give me a link? ~ ToBeFree (talk) 01:41, 3 October 2018 (UTC)
No, template editors could not edit JS/CSS (TemplateStyles maybe, but this is a relatively new thing and the CSS is sanitized anyway). I mean no offense, but I agree the headings for "only template editor", etc., are mostly clutter. — MusikAnimaltalk01:52, 3 October 2018 (UTC)
Usernamekiran No need for adding pending changes reviewer, because too many active experienced editors have this right, so this will make no sense to add this, just you !vote all non-admins instead. If you want to add EFM, go ahead Hhkohh (talk) 01:18, 3 October 2018 (UTC)
It amuses me how people think that an RfA that doesn't consider technical skill at all somehow means any admin can get the right with minimal review, while a process that would specifically consider technical skill is "too risky". This should have been the requirements for granting to anyone, admin or not. Anomie⚔13:00, 3 October 2018 (UTC)
As I understand it, the concern is less about people making mistakes due to (lack of) technical skill, and more about people who are indeed quite skilled using it nefariously. RFA is an admittedly imperfect vetting process for sorting out nefarious intent, but it's usually well-watched and well-attended, at least. 28bytes (talk) 14:25, 3 October 2018 (UTC)
OTOH, a rogue admin could as well use it nefariously. And unfortunately the !vote there was swayed by people who wanted to make it as easy as possible for any admin to get it because all admins used to have the ability. Anomie⚔13:07, 4 October 2018 (UTC)
I think the point is that we should have an appropriate vetting process similar to RFA. However, it does not have to be the same as RFA - for instance, I do not see how issues on for example anti0vandalism experience or content creation would be relevant for interface administrators. If RfA was a properly functioning process, and an admin candidate only interested in working on the interface would be tested on having a general clue and experience working on the interface, we would not need the process and could just send everybody to RfA. However, unfortunately, RfA does not work like this, and having a parallel process could be beneficial.--Ymblanter (talk) 19:02, 3 October 2018 (UTC)
If Enterprisey would do an RFA, this would probably be moot, so I don't really support this. That said, this seems similar to the "edit-filter-manager" permission, and as that can be granted to non-admins, I'm not opposed either. The suggestion of needing specific privileges is not a good one, and I don't see a need to spell out experience requirements per WP:NOTBURO. power~enwiki (π, ν) 21:59, 3 October 2018 (UTC)
Yes I agree, let's just make Enterprisey an admin :) This should happen regardless if int-admin were a thing. Int-admin on the surface may seem similar to edit filter manager. This is a common misconception. To put it bluntly, if you have access to site-wide JS/CSS you can (with malicious intent) do everything listed at Special:ListGroupRights, and do things MediaWiki isn't supposed to do, like compromise the privacy and security of everyone who visits the site in an automated fashion, even with monetary gain. So the bar therefore is obviously considerably higher. This abuse has never happened on enwiki, but it has on other WMF wikis, multiple times. I actually don't really oppose non-admins getting int-admin rights, I just don't see how we'll do it without introducing another RfA process which seems excessive. — MusikAnimaltalk01:50, 4 October 2018 (UTC)
MusikAnimal, I think it would be fine to have another RfA process, because the new one wouldn't focus on all the other stuff like DRV, UAA, etc (per a few people above). Also what Ymblanter said above. Enterprisey (talk!) 01:54, 4 October 2018 (UTC)
Sure, it certainly wouldn't focus on content creation and the like. Candidates would need to be subject to just as much scrutiny, though, and that would apply to all behaviour on the site and not just technical contributions. Establishing an RfIA process is going to be a nightmare... yet we'd hardly ever need it. There's yourself, and an exceptionally few number of non-admins who'd benefit from site JS/CSS editing rights. It might be a little annoying from time to time, but any editor can request assistance from what is (based on historical data) an already plentiful supply of int-admins. — MusikAnimaltalk02:22, 4 October 2018 (UTC)
This is the thing that doesn't make any sense to me. We are all agreed that all sensible people, and specifically the folks who understand this area best, would support making Enterprisey an admin, and two days after that, we'd be perfectly happy to hand over this particular user right, too, without so much as a second glance. But despite agreeing on all that, there are a bunch of people saying "No! Absolutely not! We must Always Follow All The Rules. Enterprisey can't have this user right unless and until Enterprisey undergoes a process that is absolutely notorious for devaluing technical contributors and being abusive in general!" And we say this despite knowing that Enterprisey actually does not want to hold the admin bit, and despite knowing that RFA outcomes sometimes destroy good editors, and despite knowing that trustworthy editors are sometimes rejected at RFA for spurious reasons. Exactly what additional value could RFA provide in a such as case Enterprisey's? The community bonding effects of shared trauma? Adding an additional, essentially random risk of failure to the process? A belief that nobody can fix CSS and Javascript unless there's also a chance that you could accidentally misclick on a delete button while you're at it? This doesn't make sense. A process should select the right people and exclude the wrong ones. "You have to do RFA and hold the admin bit to get this one" seems to be excluding some of the right people. WhatamIdoing (talk) 20:01, 4 October 2018 (UTC)
Why don't we just IAR and grant the bit for six months at a time, upon request to non-admin active maintainers of gadgets who have not been blocked in the last year ? I personally don't think there will be any security risk posed by that criterion. — fr+07:41, 5 October 2018 (UTC)
@MusikAnimal:, @Power~enwiki: - I mean if we're all so agreed that Enterprisey (and potentially literally 1 or 2 others) are so suited, but for whatever reason aren't of mind to suffer through RfA (with its additional problems discussed elsewhere), perhaps the compromise solution should be to make them interface admins, and, until a new RfC determines otherwise, the only non-admin IAs. I disagree with the policy not being open, but there seems functionally universal agreement that a couple of the most active contributors should be added. Nosebagbear (talk) 20:14, 9 October 2018 (UTC)
Firm and resounding "no" from me. I don't see an int-admin RfA-style process working, as much as I'd like it to. The biggest thing is that it's not really necessary, or worth the hassle, because so few users would ever fall into this bucket. There are prolific gadget maintainers (ie This, that and the other) have for years gotten by just fine requesting help from admins. I don't want any user to "suffer" through any process, but the new process would have to put the candidate through just as much scrutiny, to the point it doesn't make sense to introduce a separate process. The argument that you have to have well-rounded experience in deletion areas, policy, etc., to become an admin, just isn't true. There have been admins who have passed an RfA, with ease, without any relevant need for the tools beyond technical matters (ie West.andrew.g). Enterprisey meanwhile actually would be a well-rounded admin. He should go for it :) I'll be happy to nominate and judging by this discussion there's a handful of other regular RfA nominators that would co-nom as well. — MusikAnimaltalk20:46, 9 October 2018 (UTC)
Noting the concerns in the No section, how's this as a compromise: Admins can get Interface Admin through a simple BN request, and non-admins go through a similar vetting process as CheckUser/Oversight get prior to being permitted to request at RfPerms (or wherever else). Would that alleviate most concerns? DaxBane19:56, 4 October 2018 (UTC)
For those opposing the grant to non-admins, would there be any objection to someone posting an RfA in the usual format on the usual page to be closed by a bureaucrat in the usual way, but making it clear that they are requesting Interface admin only? This would presumably mean the candidates receives the same amount of scrutiny as any other RfA but wouldn't be opposed on the basis of insufficient experience in other areas required for regular adminship... WJBscribe(talk)11:03, 5 October 2018 (UTC)
How often is the right used now, and is there a reason that an edit protected request, or similar, could not be engaged for those wishing to push changes? –xenotalk16:12, 6 October 2018 (UTC)
To those who say that anyone who can be trusted with the interface administrator role should be able to pass a request for administrative privileges: if the RfA process only evaluated trust, this would be the case. However candidates requesting administrative privileges are also evaluated on the competencies they've demonstrated, including knowledge of policy and guidelines in varied areas. Previous candidates who have sworn up and down of their interest in a limited subset of administrative duties have generally still been judged on the broader set of admin tools, albeit in some cases less stringently. While I can appreciate the practicality in introducing a tiered system of privileges (there should be enough eligible and willing administrators who can fulfill the interface administrator role, saving us from creating a parallel approval path), since the tasks of an interface administrator are not a superset of those of an administrator, there is no functional reason for making the latter a prerequisite for the former. isaacl (talk) 02:27, 7 October 2018 (UTC)
Isaacl is bang-on, RfA is not just a trust-measuring system. We could have some technical gurus who have never created an article, or have no mainspace edits, and thus would never make it through the ravening hoards. We're generally supposed to encourage users avoiding acquiring rights they have no need for. We seem to be having a volte-face on that within this discussion. Nosebagbear (talk) 16:54, 7 October 2018 (UTC)
Trust vs RfA Skillset Query - discussion is fairly flowing about potential Int-Admins who couldn't pass RfA on the basis of non-trust criteria that are not relevant to Int-Admin work. I was wondering which of the cases below was responsible for the "No" !voters saying it must be done via RfA despite this (potential) issue since it seems so fundamental to viewpoints. Pinging a few No voters for some serious thoughts @Hut 8.5:@MusikAnimal:@Seraphimblade:@Nyttend:@ToBeFree:
RfA is the only suitable mechanism for assessing high trust levels, an alternate means couldn't assess trust strongly enough. RfA No !votes based on non-trust/technical criteria would be a negative, necessary, side-effect
Int-Admins could implement Admin actions and so require a skill set beyond trust and technical acumen, thus any int-admin should also be an admin by meeting the full admin criteria as decided within an RfA
I feel that while non-admins should be able to request the interface administrator right, in practice, admin rights will be a de facto prerequisite, similar to WP:RFB — BillHPike (talk, contribs) 21:01, 7 October 2018 (UTC)
I didn't get your ping, by the way. Yes, RfA is only the suitable mechanism for assessing trust. Int-admin > normal admin, so candidates need to be subject to just as much scrutiny. You can pass an RfA with very narrow interests such as technical matters, provided the need is there. Case in point Wikipedia:Requests for adminship/West.andrew.g. — MusikAnimaltalk20:54, 9 October 2018 (UTC)
In terms of security risk, yes, an interface admin has a greater ability to cause havoc. But in terms of the role itself, an interface administrator does not require any access privileges beyond the newly introduced access level, and so it is not a superset of the administrator role. isaacl (talk) 21:14, 9 October 2018 (UTC)
Thought it was a good idea at the time - but upon review I see my proposal's own issues - mainly the fact this would be too buereacratic. As such, I'm withdrawing this proposal. Kirbanzo (talk)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
So I noticed a gaping hole in the first proposal - the potential for non-admin (or potentially rogue admin) users to use the permission to spread malware via Wikipedia (without a user manually installing the malicious code into the script repositories the maker cannot access otherwise). Thereby, legal issues could become a problem, and thereby I suggest the following:
I propose that the permission must be granted bythe Arbitration Committee. This would ensure that users are chosen as to show competence and an ability to handle the role. I believe this is needed as the permission involves messing with some code that could potentially alter Wikipedia entirely, for better or worse. There's also the issue of users with the permission being able to potentially inject malicious code into the personal script pages of users, bringing legal issues into this.
This would be done in a similar manner that the Arbitration Committee selects CheckUsers & Oversighters - a window to nominate yourself for the position, and have other Wikipedians either support or oppose the nomination. ArbCom, once the window closes, will select the new "Interface modifiers" (arbitrary name for the non-admin version) from the list of candidates. This would also apply to administrators seeking the right.
Please comment below if you support or object to this alternative proposal.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Interface Admin Nominator Tweak?
Some of the nos above are concerned about significant weight of people applying. Others feel the trust requirement is so high additional requirements are needed. As a resolution to the first and a limited modifier to the second, how about the following modifier? Nosebagbear (talk)
"Any non-admin desiring to apply for these rights must be nominated by an Admin already possessing Interface Administrator rights"
I wouldn't have any issue with that and it would be a good way to significantly cut down on how many non-admins could apply for the right. This would allow for someone to apply for this right that doesn't want the full admin toolset. With this modifier in place I wouldn't expect the number of total people having the interface-admin right to expand greatly and I trust admins who have this right already to be very selective in which non-admins are nominated for this right. ♪♫Alucard16♫♪04:49, 7 October 2018 (UTC)
Sounds good to me. Someone with enough trust to become an intadmin should have no problem finding an intadmin to vouch for that. Enterprisey (talk!) 04:57, 7 October 2018 (UTC)
Just pinging @Cyberpower678: the original poll creator since they've presumably got a more developed thought process as to if this is contradictory to the current set-up, since i joined the discussion pretty late. Nosebagbear (talk)
Not really. It just changes the application requirement, everything else in the already established proposal remains the same.—CYBERPOWER(Chat)22:21, 7 October 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Note: I have !voted, but hopefully this is a suitably neutral link - as a significant expansion of the IA remit it seemed suitable to post a specific link. Nosebagbear (talk) 16:06, 27 November 2018 (UTC)
Hi Izno! I noticed that you edited this page and removed the {{INTADMINRightPlace}} help template that I recently created and added to it. If you're not aware, I created the same help templates that you see on the top of Wikipedia:Administrators, Wikipedia:Reviewing pending changes, Wikipedia:Account creator, Wikipedia:Autopatrolled, Wikipedia:Page mover, and many other pages. These templates are not there in order to prevent disruption (I read this in your edit summary as the reason why you didn't believe that the addition was an improvement to this page?); they exist for new and novice users who were navigated to this page and are lost, and they help point them to the correct place that they're looking for with the proper link. I just wanted to explain the reason for the addition and ask for additional information regarding your removal so that we can discuss it and work things out. What are your thoughts regarding the edit? What makes you believe that the template isn't an improvement to this page? Please ping me in your response so that I receive an alert - I have a lot of pages on my watchlist, and I'd like to sort this out with you. :-) Thanks Izno! ~Oshwah~(talk)(contribs)06:30, 15 February 2020 (UTC)
The yellow is garish and full-width. I believe that on some other pages you added this template that you want it to stand out. On this page, it has no competition except the policy-proper and the policy template. This is the first concern. (I kind of honestly see it as a defacement of our otherwise pristine policy pages.)
The second concern is that this page has not seen any disruption to indicate the need for such a template, nor have you presented evidence that this page needs to direct lost, inexperienced, users to the place they need to go (much less the other pages you added the template, but I won't argue for/against in their regards). No-one has wandered to this talk page and said "I can't find anything", much less tried to do something as silly as apply to be an administrator on the main page, or less sillily to report someone else for being an edit warrior or a vandal. I think one will have needed to have done something really strange to end up on this page; I don't think it's linked from many places at all.
Between the two, well, it's not an improvement. Maybe there is some scope for a more subtle link toward the top like "if you need any kind of help, consult this Master Help Page", where master help page can either be a directory or it can be something like the Teahouse, but I wouldn't be the first one to remove such a subtle link, either.
In the meantime, I've added a link or two and reorganized things a little to make it quicker to get to the link to the interface admin's noticeboard, which has what is basically a duplicate template to the one you added in the form of {{noticeboard links}}. --Izno (talk) 23:09, 16 February 2020 (UTC)
The administrator makes a request, with a rationale, .... Bureaucrats may inquire about why the administrator is requesting access at their discretion.
@Izno: I suppose "a rationale" is needed, but it doesn't have to be a great one - in most cases it's fairly obvious because admins needing this normally have experience in the area. If an admin that has never touched a script asked for it "just for fun", I'd expect a lot more inquiries from 'crats would be forthcoming... Including a basic rational, especially for non-obvious cases will may reduce delays that could be injected with questions. — xaosfluxTalk15:20, 16 November 2020 (UTC)
Important change
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
~ ToBeFree (talk) 01:29, 3 October 2018 (UTC)
Note: I've added this to WP:CENT. Mz7 (talk) 20:44, 3 October 2018 (UTC)
Moved to WP:IANB
Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. ScottishFinnishRadish (talk) 00:54, 6 October 2021 (UTC)