Requests for Comment/Meta Interface Admin Group

Note: This RFC only affects Meta and does not apply globally.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

---

This RfC has been outstanding for months, with a clear consensus supporting most of the proposals or alternate proposals, so like @Amanda Catherine:'s bold close of this outstanding RfC, I'm going to boldly close this and notify a bureaucrat, with the capacity to implement it, to implement.

Regarding the first part on group management, there is a no consensus supporting Amanda's original proposal to include stewards as those who may grant interface administrator; however, as noted in the alternate proposal, stewards can already act in cases of emergency or where there has been no local action after "a reasonable period of time." Thus, there is a very strong consensus for the alternate proposal that this local user right should be granted either by Meta:Administrators or Meta:Bureaucrats, with stewards only acting in the case of emergencies or where, hypothetically, there was no local action after a considerable period of time. One user noted that we may want to consider defining what that "reasonable" or "considerable" period of time is to be by way of a future RfC or community discussion.

Regarding appointment, there is a clear consensus for the first proposal, with a weak consensus against the second proposal.

Regarding revocation, there is strong consensus for the first two proposals, overwhelming opposition against the third, and the fourth had little traction. The fourth seemed interesting, but as the lone supporter, @Reception123:, noted was moot if proposal #1 passed, which it has now done. Dmehus (talk) 15:49, 11 July 2020 (UTC)

---

Bureaucrat Note: Proposal 1 fails, amendment to proposal 1 passes - as proposal 1 has failed, the amendment is not looked at further. Therefore, there is no consensus from this RfC on which groups can manage the new group. Status quo shall stand in that Bureaucrats only can manage the group and this is not being delegated to administrators. John (talk) 16:37, 11 July 2020 (UTC)

Introduction

This RFC is intended to establish consensus regarding the use of the Interface Administrator user group on Meta. As some background, this group was added to MediaWiki core in (I believe) version 1.32 as an added layer of security against compromised administrator accounts. Previously, users with sysop access could edit all pages in the MediaWiki: namespace and edit all CSS/JS pages, both sitewide pages and personal user scripts. However, this posed a security risk because if an admin account was compromised or went rouge, severe damage can be done that would affect all users of the site by inserting malicious content into CSS or JS pages - perhaps more damage than would be done by perhaps deleting the main page or something like that. As a result, the editinterface userright, which allows modification of pages in the MediaWiki: namespace, among other similar permissions, were revoked from the sysop group and given to their own independent group that is assignable by bureaucrats. However, on Meta these changes were overridden locally so that sysops still have the rights they originally had, and the interface admin group has since been unused.

However, there may be certain cases where access to the MediaWiki namespace and other interface pages is needed or desired while full administrator rights are not needed. The circumstance that prompted the creation of this RFC is a personal desire to do some work to improve Twinkle, which has its code hosted in the MediaWiki namespace, without applying for full administrator access. The purpose of this RFC is to establish consensus for use of the Interface Administrator group, which has the necessary permissions unbundled from the sysop group.

Proposal regarding group management

Currently, only Meta bureaucrats can add or remove the interface administrator user group, which limits the management of the group to only 2 users (John and Southparkfan as of writing). It is proposed that Meta administrators and Stewards also be allowed to manage the interface admin group, so that there is a number of people able to manage the group that any requests will be attended to in a reasonable amount of time.

Support

1.  Strong support As proposer. Amanda Catherine (talk) 21:21, 22 May 2020 (UTC)
2.  Strong support Yep. No reason not to. Right now, the bureaucrats we have on Meta are either (a) a steward or (b) a system administrator. It's quite possible we'll gave other stewards, or we'll need to add bureaucrats. But I'm also thinking this proposal is moot as stewards aren't exempt from Meta (only Global Sysops are), so stewards can already add interface admins on Meta. Dmehus (talk) 17:40, 29 June 2020 (UTC)

Oppose

1.  Oppose While I  Support administrators being able to add interface admins, I am opposed to the Steward proposal as I see no need for Steward intervention on a wiki that has active administrators and at least one active bureaucrat. Stewards should intervene when a community needs assistance or support and I feel like that is not the case for Meta. Reception123 (talk) (C) 07:30, 23 May 2020 (UTC)
2.  Oppose Per Reception -EK ● 📝 ● 🌎 23:43, 23 May 2020 (UTC)
3. The entire purpose of this group's creation was to take away the ability from administrators. Why simply allow admins to give it to themselves then? Naleksuh (talk) 04:51, 29 May 2020 (UTC)

   @Naleksuh: My reading of your comment is that you're not opposed to this, but rather, are just wondering why not let Meta Admins grant the interface administrator user right? I'd support that also personally. Anyway, your comment was added to the "oppose" section, so just pinging you in case you want to move to "neutral" comments section. Dmehus (talk) 17:42, 29 June 2020 (UTC)

If it wasn't an oppose, I would not have put it in oppose section. {{oppose}} is optional to use. Naleksuh (talk) 01:03, 4 July 2020 (UTC)

@Naleksuh: Okay, perfect, that's what I thought, but it's not always clear so just wanted to make sure that was on the record. Dmehus (talk) 19:31, 4 July 2020 (UTC)

Abstain

1. Not against it, but the need to acquire editinterface rights should be rare enough that burdening/awaiting a bureaucrat would not be a big problem. I do support having editinterface separate from other Admin rights on the basis of demonstrated need. Another example is maintaining the Message of the Day (sitenotice/anonnotice), which are also in the protected MediaWiki: namespace. Spıke (talk)23:04 22-May-2020

Comments

1. Move to close as moot Stewards already have the power to add editinterface on Meta when there has been no action by local bureaucrats after a "reasonable period of time," or something to that effect. Global Sysops can't operate on Meta, but there's no exemption or opt-out provision for Stewards. Dmehus (talk) 17:47, 29 June 2020 (UTC)

Amendment 1 to Proposal regarding group management

Steward is removed from the people explicitly authorized to manage the usergroup (except in case of an emergency).

Support

1.  Support As I explained in my oppose above, I don't feel there's a need to explicitly allow the local Steward group to edit this userright, since it is a local user right. In case of an emergency and a lack of local staff around, as on any other wiki Stewards can use their permissions accordingly, but they should not be doing routine appointment/revocations since this is local business. Reception123 (talk) (C) 15:20, 24 May 2020 (UTC)
2.  Support. Per Reception123. Stewards have a responsibility to the wiki farm; Meta Admins administer Meta. There is no reason to blur the distinction. Spıke (talk)19:34 24-May-2020

   @Spike: That's true, yes, but they also can close local Meta discussions when there has been no action by a local Meta bureaucrat for a considerable period of time. In short, Stewards aren't exempt from using their powers on any wiki, including Meta. It seems to me the only thing we need to do here is close this proposal as moot or invalid and start a new proposal to clarify what a "reasonable period of time" is, no? Dmehus (talk) 17:52, 29 June 2020 (UTC)

3.  Support per reception123 and spike. DeeM28 (talk) 18:39, 27 May 2020 (UTC)
4.  Support Per above supporters. WickyHoney (talk) 08:47, 30 May 2020 (UTC)
5.  Support per Reception123.--MrJaroslavik (talk) 18:08, 6 July 2020 (UTC)

Comments

1. Move to close as moot Stewards already have the ability to close editinterface permissions requests if a local Meta bureaucrat has not acted in a "reasonable period of time." Perhaps the only thing needed here is to clarify what that reasonable period of time is. Dmehus (talk) 17:49, 29 June 2020 (UTC)

Appointment

Proposal 1

A user may be added to the interface administrator user group at the discretion of users agreed to in the above proposal for group management if the requesting user meets all of the following criteria:

• A clear and specific purpose for requesting the right has been demonstrated (i.e. the user has made clear what exactly they plan to use the permissions for and are not "hat collecting")
• The user already holds wiki creator, rollback, CVT, or other userrights that demonstrate that they are trustworthy
• The user has no recent history of blocks or other sanctions on Meta
• The user confirms that they have a strong password

Support

1.  Support As initial drafter of this RFC I support either proposal 1 or proposal 2. Amanda Catherine (talk) 22:29, 22 May 2020 (UTC)
2.  Support I think community votes are important and necessary for rights that have a lot of permissions and rights that interact with the community. Interface administrators being in charge of editing the MediaWiki namespaces and the JS and CSS files, I think the discretion of an admin or bureaucrat is sufficient for the rights. Reception123 (talk) (C) 15:09, 24 May 2020 (UTC)
3.  Support per above. Don't think we need more voting for this. DeeM28 (talk) 18:39, 27 May 2020 (UTC)
4.  Support Sounds good to me. WickyHoney (talk) 21:03, 19 June 2020 (UTC)
5.  Support Seems fine to me, but to clarify, they must only hold one of those user rights, not all of them, correct? Otherwise, I'm opposed. Dmehus (talk) 17:54, 29 June 2020 (UTC)

   @Dmehus: Yes, that is correct. The user in question must only hold one of the user rights mentioned (or frankly, any other user rights that demonstrate they are trustworthy, which in practice pretty much means anything besides autopatrolled and confirmed). Amanda Catherine (talk) 23:56, 5 July 2020 (UTC) (sorry for the late response... I had taken my eyes off of this RFC because it was going stale/inactive. Please ping me if you ask a question to make sure I see it. Thanks!)

6.  Support --MrJaroslavik (talk) 18:08, 6 July 2020 (UTC)

Proposal 2

Interface administrator rights may only be granted after a successful request at Meta:Requests for permissions, where successful is defined as:

• The request has been open for at least 5 days
• At least 5 users have independently supported the user requesting permissions (independently meaning without canvassing or meatpuppetry)

In addition, a request for interface administrator at RFP will not be considered valid unless the user has also met all of the following criteria:

• A clear and specific purpose for requesting the right has been demonstrated (i.e. the user has made clear what exactly they plan to use the permissions for and are not "hat collecting")
• The user already holds wiki creator, rollback, CVT, or other userrights that demonstrate that they are trustworthy
• The user has no recent history of blocks or other sanctions on Meta
• The user confirms that they have a strong password

Support

1.  Support As initial drafter of this RFC I support either proposal 1 or proposal 2. Amanda Catherine (talk) 22:29, 22 May 2020 (UTC)
2.  Support But I'd add that we should put this on hold until we've implemented two-factor authentication as a global group, so the requestor should be required to use two-factor authentication to ensure their account was not compromised. Dmehus (talk) 17:56, 29 June 2020 (UTC)

   Regarding 2FA, I think that's an interesting proposal and we should be doing more to ensure that users that hold advanced rights enable 2FA on their accounts. Reception123 (talk) (C) 18:42, 6 July 2020 (UTC)

Oppose

1.  Oppose In favor of proposal 1 I think this right can be requested similarly to how rollback/confirmed/autopatrolled are. Reception123 (talk) (C) 15:09, 24 May 2020 (UTC)
2.  Oppose because I support Proposal 1. WickyHoney (talk) 21:04, 19 June 2020 (UTC)
3.  Oppose per Reception123.--MrJaroslavik (talk) 18:08, 6 July 2020 (UTC)

   @MrJaroslavik: Can you clarify if you're supporting or opposing this proposal? The location of your expression contradicts the !vote template used. Dmehus (talk) 18:30, 6 July 2020 (UTC)

   Thank, fixed.--MrJaroslavik (talk) 18:32, 6 July 2020 (UTC)

Comments

• Repeating my chronic request that we get close to voting on exact text after a drafting interval with public input. Here, if Proposal 1 failed but Proposal 2 were adopted, 2's incorporation of criteria from 1 could lead to controversy. Spıke (talk)23:08 22-May-2020

I think I have now addressed this. Amanda Catherine (talk) 23:28, 22 May 2020 (UTC)

Revocation

Proposal 1

Interface administrator permissions may be immediately revoked by a bureaucrat, administrator, or steward without a prior discussion if either of the following occur:

• The user account has shown indication of being compromised
• The user has engaged in vandalism in restricted namespaces or on restricted pages

Support

1.  Strong support As proposer. Amanda Catherine (talk) 22:29, 22 May 2020 (UTC)
2.  Support All of the above groups should defend Miraheze against vandalism and all the rules should support their doing so.. Spıke (talk)23:17 22-May-2020
3.  Support for obvious reasons. Reception123 (talk) (C) 15:16, 24 May 2020 (UTC)
4.  Support of course. DeeM28 (talk) 18:39, 27 May 2020 (UTC)
5.  Support Agreed. WickyHoney (talk) 21:07, 28 May 2020 (UTC)
6.  Support Sure.--MrJaroslavik (talk) 18:08, 6 July 2020 (UTC)

Comments

1.  Comment: Not opposed to this, but would prefer these requirements be further elucidated. I'd prefer to make it a requirement to use two-authentication, so we should pause this implementation until Miraheze has implemented an OAuth implementation vis-a-vis Meta Wiki on Wikimedia. Dmehus (talk) 17:58, 29 June 2020 (UTC)

Proposal 2

Interface administrator permissions may be procedurally removed if the user holding the rights has been inactive on Meta for 30 consecutive days. If the user is active globally on other wikis, an attempt to contact the user and notify them of the pending removal of rights for inactivity should be made.

Support

1.  Strong support As proposer. Amanda Catherine (talk) 22:29, 22 May 2020 (UTC)
2.  Support. At least this. The power to editinterface is so specific and task-based, I wouldn't mind if it lapsed automatically after 30 days of disuse (even if the user remained on Meta doing other things); without prejudice against asking for the rights again if a new need arose. Spıke (talk)23:14 22-May-2020
3.  Support per Spike. Reception123 (talk) (C) 15:16, 24 May 2020 (UTC)
4.  Support If someone is inactive they should not keep the rights. I also agree with The Pioneer and think that interface admin should be limited. DeeM28 (talk) 18:39, 27 May 2020 (UTC)
5.  Support I agree with Spike and DeeM28. WickyHoney (talk) 19:28, 4 June 2020 (UTC)
6.  Support per Spike. --MrJaroslavik (talk) 18:08, 6 July 2020 (UTC)

Comments

 Comment:I think that it is better to give Interface Admin authority by specifying a period rather than giving it indefinitely.First, give the interface administrator authority for 30 days, and then extend the term if necessary. (While maintaining sup{Remaining term} = 30days).--松 (talk) 09:49, 25 May 2020 (UTC)

 Comment:Addendum:I would like to add the condition that an extension application can be made after the remaining period is within one week.In short, I think the deadline should not be extended when there are no bureaucrats or administrators.--松 (talk) 10:13, 25 May 2020 (UTC)

 Comment: 30 days is too short. We should pause this until we've implemented two-factor authentication, then we could make a requirement for editinterface user rights to have two-factor authentication enabled. I'm surprised @John:, @Void:, and/or @RhinosF1: haven't commented on this RfC. Dmehus (talk) 18:02, 29 June 2020 (UTC)

Proposal 3

Any member of the Miraheze community in good standing may initiate a request for removal of interface administrator rights ("vote of no confidence") if they believe that the rights have been abused, but there is not an urgent or emergency situation necessitating their immediate removal. A user starting such a request must demonstrate clearly why they believe the rights have been abused, and preferably should support their claims by providing diffs or discussion logs. A request for removal will be successful (i.e. will result in the removal of permissions) if:

• The request clearly demonstrates abuse of the rights
• The request has been open for at least 5 days
• At least 5 users independently support the removal of the rights
• There is no evidence that the request was created in bad faith as "retaliation" for actions with which one disagreed or other reasons

Support

1.  Strong support As proposer. Amanda Catherine (talk) 22:29, 22 May 2020 (UTC)

Oppose

1.  Oppose Opposing per my support of Proposal 1 for appointment. If interface administrators are appointed by discretion, removal should also be by discretion, or else it would not make sense to appoint by discretion and remove only with a vote. Reception123 (talk) (C) 15:16, 24 May 2020 (UTC)
2.  Oppose. The fourth bullet is remarkable. A Meta Interface appointee makes changes in the MediaWiki: namespace that, in my opinion, break Meta. (Imagine here whether I appealed to him directly and whether he dealt forthrightly with me about his changes.) Eventually, I request removal of his editinterface rights. Now we are to weigh whether my request was "in bad faith" or whether doing something about my disagreement constitutes retaliation? Fourth bullet could read, "Only if a drama storm fails to take root." Spıke (talk)19:42 24-May-2020
3.  Oppose per Spike and Reception123. Nothing further to add. Dmehus (talk) 18:04, 29 June 2020 (UTC)
4.  Oppose Per above statements. WickyHoney (talk) 00:29, 5 July 2020 (UTC)
5.  Oppose per Reception123.--MrJaroslavik (talk) 18:08, 6 July 2020 (UTC)

Proposal 4

Interface administrator permissions may be revoked by a bureaucrat, administrator at their discretion. after a discussion on Meta:Administrators' noticeboard. This discussion is not a vote and is mainly for administrators and bureaucrats to discuss whether the user should be revoked and for what reason.

Support

1.  Support Assuming Proposal 1 for appointment passes, this is the only way that makes sense to be able to revoke someone. As I said above, you can't appoint by discretion and revoke by vote, that does not make much sense in my opinion. Reception123 (talk) (C) 15:16, 24 May 2020 (UTC)

Comments

• Sloppy. How much discussion constitutes "a discussion on Noticeboard"? What if notice of abuse arises on Discord or by telephone? Sure, require that it be disclosed on Noticeboard (with the candidate for revocation permitted to state his view). But then, "for what reason....the user should be revoked"? Presumably we got here for a reason, we are not using Noticeboard to invent one. Spıke (talk)19:46 24-May-2020

  I'm assuming that you are being hypothetical here, but under most circumstances I don't think that discussing wiki things via telephone is a good idea (especially since UK tends to be even more sensitive to harassment than United States where the WMF needs to be concerned). (sorry for invoking a Wikipedia dispute on Miraheze (I know I've been criticized for doing that before) - I just happen to follow enwiki ArbCom business closely). Amanda Catherine (talk) 20:13, 25 May 2020 (UTC)

• Since I was the only person who supported/opposed I have striked out that and just left it to discretion. As I said, it doesn't make sense to appoint someone without a vote but to need a vote to revoke them. Reception123 (talk) (C) 11:02, 25 May 2020 (UTC)

  Agreed. However, we haven't yet decided whether appointment was by discretion or by request with support of 5 members. Again we are weighing multiple pieces moving independently. Spıke (talk) 15:15 25-May-2020

  @Spike: Yes, perfectly right and from now on the correct method should be to have the same proposals for appointment/revocation as if someone votes one proposal for appointment the counterpart would also need to be voted for revocation. In this case, of course this proposal should only pass if the appointment proposal regarding discretion passes. Reception123 (talk) (C) 17:45, 28 May 2020 (UTC)

•  Comment: Original Proposal has been striked out and modified since I was the only person who voted. Reception123 (talk) (C) 11:02, 25 May 2020 (UTC)
•  Comment: Proposal is sloppy per @Spike: above. I would just add that stewards can already remove editinterface when a local Meta bureaucrat has not responded or closed within a "reasonable period of time." This should've been noted in the original proposal. But I think we can use common sense that bureaucrats already have this ability, since as @Reception123: pointed out, it's already a discretionary appointment. Dmehus (talk) 18:07, 29 June 2020 (UTC)
•  Comment: I would just like to comment that I am surprised that no one else has voted for this proposal. Six users have voted in favor of proposal 1 which statutes that interface administrators are appointed "at the discretion of users agreed to in the above proposal", so why would proposing that they are also revoked at the discretion of said users be such an absurd idea? I believe that if this request passes, the status quo would be that anyway, as no other way of revocation has been voted on. Reception123 (talk) (C) 18:39, 6 July 2020 (UTC)

General Comments

Personal comment

I think this RfC has been stagnant for about two weeks.--松•Matsu (talk) 15:31, 18 June 2020 (UTC)

---

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