Test Wiki:Community portal

The community portal is Test Wiki's village pump and noticeboards, two-in-one.
Archives: 1 • 2 • 3 • 4 • 5 • 6 • 7 • 8 • 9 • 10 • 11 • 12

Proposal: Abolish the non-steward suppressor right

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is unanimous and clear consensus to abolish the non-steward suppressor (NSS) role going forward. While the original proposal called for immediate removal, Drummingman's suggestion—to allow the current NSS, namely X, to retain their rights—received clear support. As such, X will retain their rights until they either resign or are appointed as a steward. No new NSS appointments will be made. This proposal is therefore closed as successful, with Drummingman's amendment adopted. The AP (talk) 15:09, 7 April 2025 (UTC)

---

This was already partly discussed in the Test Wiki Discord server, and I'm ultimately bringing it up here as a proposal for the community to comment on.

Simply, I'd like to propose abolishing non-steward suppressors on this wiki. We currently have two such users, me being one of them, but ultimately at this time, there is really not much need. There are mainly two factors to this, which I will be listing here.

1. The amount of suppressions, and especially suppression requests, are already low to this date. Except for two suppressions this month (one performed by me and the other by a steward), the last 50 suppressions date back to July last year, most of which were either reverted, performed as tests or performed for old edits/log entries.
2. The community is too small, and not large enough to justify having independent suppressors or checkusers. On a wiki as small as this one, it is likely best to center the suppression task to the stewards, both since they already are experienced with CU/OS and personal information, and considering that they have already been the ones mainly handling suppressions on this wiki either way. This would also be a benefit for the security aspects as well, even if compromises are indeed rare here.

Potentially, the community could consider to instead elect new stewards with the inactivity of Dmehus and decreased activity of Justa and MacFan, but in the current state, there isn't really a need nor a community large enough to justify having NSS at this time, and I therefore propose to instead center this task to the stewards. EPIC (talk) 13:12, 30 March 2025 (UTC)

•  Support - as proposer. EPIC (talk) 13:12, 30 March 2025 (UTC)

  Just for the record I would also be fine with Drummingman's suggestion to let current NSS keep the rights. EPIC (talk) 05:55, 3 April 2025 (UTC)

 Support ~/Bunnypranav:<ping> 13:38, 30 March 2025 (UTC)

 Support VancityRothaug (talk + contribs) 08:00, 31 March 2025 (UTC)

 Support -C1K98V ^{(💬 ✒️ 📂)} 02:32, 2 April 2025 (UTC)

 Support - However, my opinion is that the current two NSSs may retain their rights until they become stewards or resign, and that no new NSSs will be appointed. Drummingman (talk) 19:05, 2 April 2025 (UTC)

 Support Per Drummingman AlPaD (talk) 08:55, 3 April 2025 (UTC)

 Support Drummingman’s alteration to the proposal. X (talk + contribs) 10:08, 3 April 2025 (UTC)

---

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

Nomination of User:EPIC for Stewardship

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is a clear, unanimous consensus to promote EPIC to steward. On behalf of the steward-team, congratulations. Drummingman (talk) 14:09, 7 April 2025 (UTC)

---

As with the NSS removal, this was already partly discussed in the Test Wiki Discord server and I would like to officially create this nomination here on the community portal. I am hereby nominating EPIC for a stewardship here on Test Wiki. I believe that they have shown extreme dedication to all the hats they hold both on Test Wiki and other, notable wikis and that they would be a perfect fit to help oversee the administration of Test Wiki, alongside with the other 3 stewards. As many of you may know, EPIC is also a steward on Wikimedia which I find to be a great achievement, further improving his experience. Please let me know if you have any other questions in the discussion below. VancityRothaug (talk + contribs) 08:13, 31 March 2025 (UTC)

I stated it in the Discord server as well so I will partly repeat that here; I'm willing to serve if the community and current stewards are in favor of it, since I could bring some further useful experience and extra help especially now that Dmehus is not currently active and two of the other stewards have decreased activity. One of the stewards have expressed their endorsement beforehand, so I'm ultimately accepting. I shouldn't have a big issue with keeping up my activity either, though I'll otherwise resign if I end up not meeting my expected activity levels.

Noting for transparency that I'm currently a steward for the Wikimedia projects as well as a sysop on the Swedish Wikipedia and Meta (and a CheckUser on the latter). EPIC (talk) 08:30, 31 March 2025 (UTC)

Support

1.  Support as nominator. VancityRothaug (talk + contribs) 08:13, 31 March 2025 (UTC)
2.  Strong support Irrespective of the NSS removal proposal, EPIC is a clearly suitable candidate, and will definitely help this wiki. Highly trustworthy. ~/Bunnypranav:<ping> 08:16, 31 March 2025 (UTC)
3.  Support sure, good luck! BZPN (talk) 19:26, 31 March 2025 (UTC)
4.  Support Good luck! Sav • ( Edits | Talk ) 19:15, 1 April 2025 (UTC)
5.  Support Keep up the good work. -C1K98V ^{(💬 ✒️ 📂)} 02:35, 2 April 2025 (UTC)
6.  Support Bosco (talk) 08:51, 2 April 2025 (UTC)
7.  Support LisafBia (talk) 09:11, 2 April 2025 (UTC)
8.  Strong support Very trusted user and Steward on 2 wikifarms AlPaD (talk) 08:48, 3 April 2025 (UTC)

Abstain

Oppose

---

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

IA changes

Hello.

In response to my request for Interface Administrator rights, I have been asked (by @Justarandomamerican) to provide a list of at least three planned changes for review by other Interface Administrators. Below are the changes I intend to implement:

1. In MediaWiki:Gadget-UserInfo.js, I plan to fix the electionadmin display so that it includes a link to TW:EADMIN. Additionally, the links in the script currently redirect to the title in the user's language instead of the correct translation of the page. I will fix this issue.
2. The Twinkle gadget does not function at all. I intend to replace its content to load via mw.loader.load.
3. I would like to convert my script for finding unused pages and files into a gadget.
4. I plan to update my MassRollback gadget to a newer version.
5. Similar to Twinkle, I would also like to replace the content of MediaWiki:Gadget-RedWarn.js to load via mw.loader.load, as it does not currently work properly.

I welcome any feedback or additional suggestions from the community. Best regards, BZPN (talk) 19:57, 1 April 2025 (UTC)

LGTM. Per my comments on Discord, I don’t have any concerns regarding your knowledge or skill with IA tools, simply curious why you were socking on Miraheze. X (talk + contribs) 21:25, 1 April 2025 (UTC)

I believe stewards should grant you IA on a temporary basis at least. You clearly understand what you're doing, though the socking on Miraheze is a red flag. However, I don't think you'll cause immediate disruption to this project. The AP (talk) 01:54, 3 April 2025 (UTC)

That's (partially) right. Stewards may grant the interface administrator permission to trusted users with a defined need; however, it isn't limited to temporary grants. Note, though, that the permission may be removed if inactive after 30 days (i.e., no usage in MediaWiki CSS/JS space). It's limited to granting by stewards for security reasons. Dmehus (talk) 17:37, 13 April 2025 (UTC)

 Done. Thank you for volunteering. You now have rights to edit all JS and CSS pages on the wiki. Please ensure to review your code before making an edit, especially when making edits to skin or common pages. Justarandomamerican (talk) 12:39, 3 April 2025 (UTC)

Thank you :). I'll get to work soon. Best regards, BZPN (talk) 13:56, 3 April 2025 (UTC)

UserRightsManager

Hello. Is it just me that the UserRightsManager gadget doesn't work (only the button is displayed, but doesn't respond to clicking), or do other users have this problem too? I'd like to know if it's a problem with the gadget or maybe it's something on my end. Best regards, BZPN (talk) 18:08, 10 April 2025 (UTC)

It directs to Special:UserRights. The AP (talk) 13:25, 11 April 2025 (UTC)

Proposals: Administrators' newsletter and Newsletter extension

I looked through the current subscribers to the Administrators' newsletter, and I don't see evidence of subscribers opting in (versus being subscribed involuntarily).

Test Wiki is, by its name and definition, a place to test gadgets, scripts, and permission sets in MediaWiki software. As such, Administrators and Bureaucrats on Test Wiki are primarily testing permissions, so there will be frequent changes to users with the permission (it changes daily, in most cases). As a result of this, the utility of such a newsletter is very low, versus, say, a content wiki like English Wikipedia.

At the same time, the Newsletter extension is a useful extension, particularly for sending out important notices like inactivity notices, or perhaps notices of community discussions (stewards should primarily handle the latter; any bureaucrat can handle the former).

To ensure users do not become overwhelmed with e-mail notices, I therefore propose the following: -- Dmehus (talk) 17:59, 13 April 2025 (UTC)

Proposal 1: Administrators' newsletter is made opt-in

The Administrators' newsletter is made opt-in and the subscriber list reset to 0 upon this proposal being closed as adopted. Before resetting the subscriber list to 0, the closing steward shall send one administrative newsletter instructing current subscribers they need to re-add their names to the newsletter's subscriber list if they wish to continue receiving the newsletters.

•  Support as proposer. Dmehus (talk) 18:01, 13 April 2025 (UTC)
•  Support. X (talk + contribs) 19:51, 13 April 2025 (UTC)
•  Support as proposer. EPIC (talk) 20:20, 13 April 2025 (UTC)

Proposal 2: Newsletters extension should be removed

The Newsletters extension should be removed.

NOTE: The recommendation is to oppose, to provide a reverse affirmation of support to its installation. In other words, it's a vote of confidence. A majority of support with valid arguments would be a vote of non-confidence and would result in its removal.

•  Oppose ratification of support as proposer. Dmehus (talk) 18:01, 13 April 2025 (UTC)
• This is entirely unnecessary. X (talk + contribs) 19:49, 13 April 2025 (UTC)
•  Oppose as no apparent reason to. EPIC (talk) 20:20, 13 April 2025 (UTC)

Proposal 3: Mandatory newsletters

The following newsletters are made mandatory (i.e., non-opt-in; opt-out is allowed).

• Inactivity notices. Trusted bureaucrats and stewards may send out the notice, typically no more than once per month.
• Notices of community discussions. Stewards, or any current or future steward-delegated role, may send these newsletters, typically consolidated in digest format such that there are no more than 1-2 per month.

NOTE: This proposal is conditional upon Proposal 2 failing.

•  Support as logical and sound as proposer. Dmehus (talk) 18:02, 13 April 2025 (UTC)
•  Oppose-ish. I’m not entirely sure how doing mass messaged inactivity notices would work. It’s not like people stop editing on the same day(s) so it doesn’t really apply. I think we’ve tried this and it didn’t really work, if I remember correctly. For the community discussion notifications, I would support those if they were opt-in. X (talk + contribs) 19:55, 13 April 2025 (UTC)

  Technically speaking, neither is mandatory, since 'opt-out' is still permitted. We wouldn't be mass-adding all current users to these two newsletters, but rather just allowing the existing members to continue, regardless of whether they had opted in or not. So, in that sense, in kind of 'is' opt-in. Hope that clarifies. Dmehus (talk) 20:33, 13 April 2025 (UTC)

  That does clarify, thank you. I  Support for community discussions. X (talk + contribs) 21:31, 13 April 2025 (UTC)

•  Support for community discussions, at least. As far as I know we don't really send out inactivity notices and rather resort to grace periods for inactive admins, in which case they already receive a notification that way. EPIC (talk) 20:20, 13 April 2025 (UTC)

  Yeah, for clarity, on the inactivity notices, I wasn't proposing to mass add every Test Wiki user to the newsletter distribution list, but rather just allowing for users to have been added without having to explicitly subscribe. If recently active users were added to the list (i.e., those not currently blocked who were active in the last ninety (90) calendar days or so), that would also be permitted, but we wouldn't want to actively encourage that and probably should be a steward (unless they've given explicit permission on Discord, IRC, or on-wiki to be added. Dmehus (talk) 20:37, 13 April 2025 (UTC)

SecurePoll permission set

Hi all:

I'm glad to see we've enabled the SecurePoll extension. I'm wondering, though, to reduce the number of testing permission groups, if we might want to either:

• A. Add the securepoll-create-poll and securepoll-edit-poll user rights into either of:

1. The bureaucrat user group (would require an additional level of trust); or,

2. The sysop user group

• B. Merge the two permissions into the interwiki-admin user group, then rename the group Election and Interwiki Administrator (election-interwiki-admin)
• C. Maintain the election-admin user group, but instead merge the interwiki-admin permissions into either of:

1. The bureaucrat user group (would require an additional level of trust); or,

2. The sysop user group

• D. Something else? Elaborate.

What are your thoughts?

Cheers,
Dmehus (talk) 20:47, 13 April 2025 (UTC)

I would support merging both interwiki-admin and SecurePoll admin to the standard bureaucrat permission set. X (talk + contribs) 21:33, 13 April 2025 (UTC)

I will note that the "electionadmin" group was added, because in the upstream code, a check is hardcoded for membership in the "electionadmin" group. This was fixed in master, and has not been backported. Master requires MediaWiki 1.44+, so switching to that is not an option. I suppose we could try and cherry pick this commit, but unless that happens, this cannot be done for technical reasons. MacFan4000 ^{(Talk Contribs)} 22:29, 13 April 2025 (UTC)

Ah yes, I remember when the extension was initially installed we had that issue. X (talk + contribs) 23:06, 13 April 2025 (UTC)

Piccadilly: How do we handle this situation?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Despite participating in this discussion, there is consensus against unblocking Piccadilly at this time, and this has been withdrawn by Justarandomamerican. Codename Noreste (talk) 18:35, 16 April 2025 (UTC)

---

Hello. Yesterday, an email was sent to staff@testwiki.wiki. It was Piccadilly, asking for their talk page to be unprotected for an appeal. The community has imposed a site ban on Piccadilly, which requires any appeal to be directed to the community, along with a 1 year appeal timeframe. I would like to propose something new: a mentorship. Piccadilly can attend a mentorship for 1 month, with no violations of our rules (otherwise the site ban is reinstated and the appeal timeframe is reset) provided by a steward or other trusted community member. I would also like to propose lifting the ban for 2 months to allow this mentorship process to take place. Any concerns? Justarandomamerican (talk) 23:35, 14 April 2025 (UTC) withdrawn on 12:54, 16 April 2025 (UTC)

While I appreciate the community consultation before moving forward, I have to say I have my concerns and doubts about the efficacy of this “mentorship.” I applaud the efforts of the stewards, but given the extensive history of the user in question, I find it hard to believe that change will ever occur. Given that the community already unanimously and overwhelmingly voted to not allow any appeals until a year as passed, I suggest we continue to honor that. If a steward would like to mentor them on another project, (ex:Drummingman and WikiMedia) (@Drummingman simply using you as an example, feel no obligation :) I think that would be beneficial as we approach the one year mark to show growth. X (talk + contribs) 00:01, 15 April 2025 (UTC)

What about this: the mentorship is their last chance. Completely serious. If they go through it, and then break our rules again, we ban them indefinitely. No chance for appeal for 2 years. Justarandomamerican (talk) 00:10, 15 April 2025 (UTC)

I would be fine with that… but we have also had a lot of “last chances” with her. X (talk + contribs) 00:21, 15 April 2025 (UTC)

I'm also possibly fine with that, but as I've already expressed several times, I feel like there should be some kind of wider community support for something like this. There has already been a bunch of final chances, so if this goes through this should be the actual final chance, and no further such opportunities after that. EPIC (talk) 08:16, 15 April 2025 (UTC)

Noting that I'm opposed to an unblock at the moment, the linked diffs are simply too recent and it's probably better at this time to just let the year pass and evaluate this at that time. EPIC (talk) 10:21, 16 April 2025 (UTC)

I support this mentorship, but I will not be the one to carry it out. Drummingman (talk) 19:35, 15 April 2025 (UTC)

I am strongly opposed to this, see [1]. Codename Noreste (talk) 04:24, 16 April 2025 (UTC)

That is indeed very concerning. I also oppose an unblock. X (talk + contribs) 10:15, 16 April 2025 (UTC)

Oh, jeez, I withdraw my request for an unblock. Justarandomamerican (talk) 12:53, 16 April 2025 (UTC)

Hi. I came to check in on something completely different, and thought I would give a drive-by opinion. If this appeal is early (has it been a year?), I strongly oppose an unblock. Aside from CN's diff, if they can't follow simple, objective instructions like "don't appeal until a year has passed", there is no chance they can follow any rules. Best, HouseBlaster (talk) 06:03, 16 April 2025 (UTC)

---

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

Idea Lab: Deputy Stewards

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

Hi there! I recently created a draft page detailing the scope of a potential new user group, and I would like you to give me feedback on the need for, and scope of Deputy Stewards. Justarandomamerican (talk) 23:42, 16 April 2025 (UTC), withdrawn on 02:08, 17 April 2025 (UTC)

Note: This would replace the NSS and AFA roles. Justarandomamerican (talk) 23:42, 16 April 2025 (UTC)

 Support, seems like a useful addition. Sav • ( Edits | Talk ) 01:26, 17 April 2025 (UTC)

Seems largely unnecessary to me. It appears to be a combination of abuse filter admin and NSS, one of which is already being deprecated. The only difference that I noticed between the proposed role and stewardship is the use of the CheckUser tool. If someone is trustworthy and active enough to attain this right, they are most certainly able to simply become a steward. If the steward team is in need of additional membership/support and finds their duties too burdensome, I know multiple users that have expressed an interest if the need arose.

TL;DR: If the stewards need help, let’s elect more stewards not make an additional unneeded role. X (talk + contribs) 01:51, 17 April 2025 (UTC)

Honestly, you make good points. However, some form of functionary step up would be a good option in my opinion (to prove trustworthiness) but what exactly would that be? Should we make crat a non-test role? Justarandomamerican (talk) 01:55, 17 April 2025 (UTC)

In my opinion, trustworthiness can be shown in other ways. Through making thoughtful and informed comments here, consistently granting admin/crat rights according to policy, helping with inactivity removals, etc. Additionally, 95+% of users here are on other wikis. Trust can be shown through that as well. X (talk + contribs) 01:58, 17 April 2025 (UTC)

---

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

X for Stewardship

As arguably one of the more trusted non-stewards on Test Wiki, I believe X should become a Steward. They already have the permission to suppress revisions, which is part of the more sensitive tools of the Steward toolset. I believe they are trusted enough to have the full toolset. Thank you for your time. Justarandomamerican (talk) 02:13, 17 April 2025 (UTC)

I am honored to accept this stewardship nomination. A little bit about me: I’m a crat, NSS, and interface admin here on TestWiki. I also serve as a moderator and founder of the TestWiki Discord server. You can find me commenting on proposals here, auditing user rights, or dealing with LTAs. I also am a steward on multiple wiki farms, including WikiOasis and SkyWiki. I’m always just a ping away X (talk + contribs) 02:17, 17 April 2025 (UTC)

Support

1.  Strong support as nom. I nominated X for Stewardship for several reasons. 1, so we can have a team of 4 fully active stewards, 2, because they are already trusted enough for part of the toolset, and 3, they have different perspectives on things than the other Stewards. I believe a fresh dose of perspective is healthy for us, along with the fact that we could always use more Stewards (until, of course, we have 20 stewards LOL). Justarandomamerican (talk) 02:20, 17 April 2025 (UTC)
2.  Support per Justa. Codename Noreste (talk) 02:21, 17 April 2025 (UTC)
3.  Support ~/Bunnypranav:<ping> 10:35, 17 April 2025 (UTC)
4.  Support Would make a wonderful steward! The AP (talk) 14:17, 17 April 2025 (UTC)
5.  Support BZPN (talk) 17:39, 17 April 2025 (UTC)
6.  Strong support yet another well experienced user who deserves to become a steward here at Test Wiki. Supporting per justa. VancityRothaug (talk + contribs) 19:09, 17 April 2025 (UTC)
7.  Support. Sidrat al-Muntaha (talk) 19:21, 18 April 2025 (UTC)

Comments

1. Should this nomination be closed as successful, as appears likely, this is more of a note to system administrators that the non-steward suppressor user group must then be deleted in accordance with this this recently passed community proposal given that X's non-steward suppressor user group will be swapped for the steward user group on closing. Dmehus (talk) 17:58, 19 April 2025 (UTC)

Steward Confirmation/Recall process

Hello. This has been proposed in the past, but was withdrawn by the proposer. This is an RFC with multiple options. Should stewards: A: Be subject to community recall upon petition by 2 stewards or 5 bureaucrats, B: Be subject to community recall upon petition by 1 steward or 5 bureaucrats, C: not be subject to community recall or confirmation, D: Be subject to regular confirmation every 3 months? Options A and B would require community consensus in favor of recall, and option D would require community consensus to keep the steward. This proposal would not affect system administrators. Justarandomamerican (talk) 15:30, 17 April 2025 (UTC)

This is very much needed! Btw,for anyone wondering, the past proposal : Test_Wiki:Community_portal/Archive_11#Proposal_2 The AP (talk) 15:44, 17 April 2025 (UTC)

I support Option A.

• Option D too frequent to be practical.
• Option C which removes all forms of community recall or confirmation, lacks accountability.
• Option B would allow a single steward to initiate a recall, which could lead to abuse, personal disputes being escalated unnecessarily, and unnecessary use of the community's time.

The AP (talk) 15:48, 17 April 2025 (UTC)

I'd also support option A per above, or keep the system we have today (no confirmations but the possibility of a new voting if and when needed). EPIC (talk) 15:51, 17 April 2025 (UTC)

A > B > D, per above. Oppose C. Justarandomamerican (talk) 15:52, 17 April 2025 (UTC)

• If I may make a suggestion, it seems that option A is the best proposal, as it requires the consent of multiple users before a removal/recall procedure is initiated. I would say that option D seems to have the potential to lead to a number of disagreements and disputes. I understand that a similar confirmation vote was held on nlwiki in the past. (I was not yet a user on Wikimedia at the time.) I believe it was abolished there, partly because of the many disputes that arose from it. Greetings, Drummingman (talk) 16:01, 17 April 2025 (UTC)

I only support option A. I would expound, but my thoughts are largely echoed by everyone else above. X (talk + contribs) 16:24, 17 April 2025 (UTC)

I believe EPIC makes a good point in saying we should keep the current system with the possibility of a new voting if and when needed. What would that look like? I would say it might look like having an annual Steward re-confirmation vote, requiring Stewards to submit to a reconfirmation vote every year. Being subject to a reconfirmation vote at least once every year would, therefore, ensure the community is provided an opportunity to express their (dis)satisfaction level with current stewards every year. Dmehus (talk) 17:41, 19 April 2025 (UTC)

For a wiki and userbase as small as TestWiki, I’m not sure a yearly reconfirmation is necessary. I prefer proposal A to this. X (talk + contribs) 00:54, 20 April 2025 (UTC)

Proposal for a rights-bot

If you're on the Test Wiki's Discord server, you may already be aware of this update. For those who are not, I recently configured APBOT to handle the removal of rights from inactive users, publish inactivity warnings, and update the Activity page. However, since I am not a steward, APBOT cannot directly remove the interface administrator flag. To address this, I shared the updated code with Justa, who is currently running the bot through his account via a cron job on a server. I propose that a dedicated bot account named "Inactivity bot" be created and placed in the rights-bot group. This group should be granted the following rights:

• userrights – for removing rights from inactive users
• edit – to edit user talk pages and the Activity report
• createpage – to create the Activity page if it does not exist (in case someone deletes it)
• createtalk - to create talk pages of users, incase it doesn't exist
• read – basic read access to pages
• noratelimit – to prevent hitting API rate limits
• bot - to hide the bot's edits from recent changes

Additionally, the bot should only be allowed to remove rights from the following user groups:

• sysop
• bureaucrat
• interface-admin
• abusefilter-admin

The AP (talk) 17:22, 18 April 2025 (UTC)

userrights grants the permission to grant and revoke all user rights. If the bot should be restricted to specific groups, a $wgRemoveGroups would be better. I would also like to propose that it removes abuse filter administrator. Justarandomamerican (talk) 17:26, 18 April 2025 (UTC)

Oh yes - I forgot that it allows you to grant and revoke all user rights.... Also I am completely fine with removal of AFA since it also requires 3 months of inactivity The AP (talk) 17:29, 18 April 2025 (UTC)

If Interface Administrator is included among the groups to remove, then the bot must be run only by a current steward, as that group is solely administered by Stewards for technical reasons. As well, in order to be considered active as an Interface Administrator, the Interface Administrator must have made a CSS or JS edit in MediaWiki namespace or an CSS/JS edit in another user's userspace, as all other MediaWiki namespace edits require only sysop permission. Dmehus (talk) 17:34, 19 April 2025 (UTC)

The bot is being run by Justa. And I can configure it to check if the IA made changes in mw namespace, or made changes to css/js. The AP (talk) 17:41, 19 April 2025 (UTC)

I'm not sure why it needs to be administered by a steward. The bot only has permission to remove the group, not assign it. As for the technical reasons, I believe the concern was about the potential damage an interface admin could cause — but in this case, the bot doesn’t assign the group; it only has the right to remove it. The AP (talk) 17:44, 19 April 2025 (UTC)

If Justarandomamerican is running the bot, then I have no concerns with this proposal, though would note Inactivity Policy doesn't apply to chatmod and reviewer, so not sure why this would be removing those groups.

As for why it needs to be a steward, yes, I get that this bot would only be removing the permission, but the administration of the Interface Administrator user group isn't subject to community decision-making. It's strictly a steward-administered user group. I suppose stewards could delegate a non-steward to run the bot on a case-by-case basis, sure, but that would be stewards deciding to do it. It isn't something the community is able to decide. Dmehus (talk) 17:50, 19 April 2025 (UTC)

I’ve updated the list, and I’ll update the code as well at the earliest. The AP (talk) 17:54, 19 April 2025 (UTC)

Okay, sounds good, thanks! :) Dmehus (talk) 18:02, 19 April 2025 (UTC)

Can this rightsbot be run on Justarandomamerican (BOT) instead? Justarandomamerican (talk) 00:54, 20 April 2025 (UTC)

That sounds fine, but it may even be worth creating a new account with a specified username about the bots purpose, like “Inactivity Bot” or “Rights Bot”. X (talk + contribs) 00:59, 20 April 2025 (UTC)

Resignation

Hi all:

I've been too busy with work, which has led to my limited capacity as a steward. As well, when I do return, there is an increased level of education I have to do to inform myself as to recent developments, both technical and community, within Test Wiki.

So, I've decided to turn in my advanced bits. Should I have capacity with more regularity and consistency to return as a steward, I will do so then by seeking election.

Thanks,
Dmehus (talk) 16:20, 19 April 2025 (UTC)

Thank you for your service! X (talk + contribs) 17:00, 19 April 2025 (UTC)

Even with less activity, your insights were always very great. I wish you all the very best in real life. We will miss you! The AP (talk) 17:01, 19 April 2025 (UTC)

Thank you for all you have done for Test Wiki. :) Greetings, Drummingman (talk) 17:08, 19 April 2025 (UTC)

Thank you for your service! Hope to see you potentially return to activity. EPIC (talk) 17:07, 19 April 2025 (UTC)

Thank you for your service. I hope to see you soon. Sidrat al-Muntaha (talk) 19:56, 19 April 2025 (UTC)

Proposal to exempt autopatrolled from inactivity policy

I'd like to recommend that we exempt the autopatrolled from inactivity policy. The permission is not an advanced permission nor does it geant permissions with security implications warranting an removal where a user is inactive. Its only utility is to reduce the need to patrol revisions of users who are not autopatrolled. Test Wiki is not a content wiki; therefore, there is no need to have users regularly patrolling revisions.

As an alternative proposal, I would suggest adding the autopatrol user right to the autoconfirmed user group.

Cheers,

 Support both the main and alternative proposals. Dmehus (talk) 16:26, 19 April 2025 (UTC)

 Support alternative. Reduces unnecessary work on Stewards, and makes the groups config simpler. ~/Bunnypranav:<ping> 16:29, 19 April 2025 (UTC)

 Support Agreed The AP (talk) 17:02, 19 April 2025 (UTC)

This proposal is not necessary, given that the IP already only applies to admins, crats, AFAs, stewards, and system administrators. Justarandomamerican (talk) 17:12, 19 April 2025 (UTC)

Well, I have seen users in past remove autopatrolled and citing inactivity as a reason The AP (talk) 17:13, 19 April 2025 (UTC)

For example here and here The AP (talk) 17:15, 19 April 2025 (UTC)

Also this change will directly affect Test_Wiki:Community_portal#Proposal_for_a_rights-bot The AP (talk) 17:16, 19 April 2025 (UTC)

Per Justarandomamerican's comment above, we can, therefore, remove autopatrolled from the above proposal you mention, but I do agree with you that bureaucrats removing non-sysop user groups has definitely occurred many times.

We actually should remove the chatmod and reviewer user groups from the above proposal for that reason, too. Dmehus (talk) 17:37, 19 April 2025 (UTC)

That's good, then, Justarandomamerican, but like The AP, I have also observed similar non-sysop user group removals by bureaucrats in the past. If nothing else, this proposal seeks to codify or clarify inconsistent past practices. Dmehus (talk) 17:29, 19 April 2025 (UTC)

In that case, I would  Support the alternative proposal. Justarandomamerican (talk) 17:39, 19 April 2025 (UTC)

I have a few suggestions: we should merge the autoreview user group to the autopatrolled user group, and merge the reviewer user group with the patroller user group. Why do we need two separate groups that only have their edits marked as patrolled or reviewed in the meantime? Codename Noreste (talk) 17:54, 19 April 2025 (UTC)

I would suggest making that a separate proposal, but if there's no opposition to this (by way of replies), I think this can be administratively done. I would suggest autoreview be merged into autopatrolled and reviewer merged into patroller as you suggest. Dmehus (talk) 18:01, 19 April 2025 (UTC)

I would support these merges. I don’t think we should erase all permissions below sysop because they are important for testing, but I do believe there are too many currently that could do with some merging. X (talk + contribs) 00:57, 20 April 2025 (UTC)

I support the first version. Sidrat al-Muntaha (talk) 19:59, 19 April 2025 (UTC)

Notice to IAs removed for inactivity

Hello. I have recently configured the bot to remove IA after 30 days of inactivity in areas requiring the right. Hence, 4 users right have been removed. I apologize for any confusion regarding the notice. Justarandomamerican (talk) 18:02, 19 April 2025 (UTC)

That's okay. I don't think they need to be notified prior to removing the interface administrator group. It's one of the most security-sensitive user groups, and they were told the group can be removed by a steward if unused for 30 days or more. The notice is a courtesy, but I don't think it's needed, either. Dmehus (talk) 18:07, 19 April 2025 (UTC)

I wish to retain my Interface Administrator flag, as I will be testing and adding a new gadget that will replace UserRightsManager. The AP (talk) 18:23, 19 April 2025 (UTC)