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

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)

  Dear @Dmehus, I believe that proposal 3 needs some changes, given that Inactivity Bot is now in effect. The AP (talk) 17:20, 20 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

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.

With unanimous support, this request is  Successful. MacFan4000 ^{(Talk Contribs)} 00:44, 24 April 2025 (UTC)

---

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)
8.  Support. X has clearly grown since his previous unsuccessful candidacy, and as far as I'm concerned, he is now ready to become a steward on this wiki. Drummingman (talk) 20:59, 20 April 2025 (UTC)
9.  Support --Cocopuff2018 (talk) 02:13, 21 April 2025 (UTC)

Abstain

Oppose

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)

---

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

Steward Confirmation/Recall process

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.

After slightly more than a week, consensus seems to be for option A. As such, the stewards information page will be updated accordingly. EPIC (talk) 15:10, 26 April 2025 (UTC)

---

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_6#Proposal 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)

---

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

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)

It might, and that was the original option, and I think that would be fine too. Justarandomamerican (talk) 01:11, 20 April 2025 (UTC)

Activity bot sounds good to me, ngl The AP (talk) 10:31, 20 April 2025 (UTC)

I kind of like "Justarandomamerican (BOT)," personally. I don't love shared bot accounts. We may well have multiple stewards running a 'rights bot' account, and the permission could easily be set by a steward on the applicable account. Unless there's a web-based reporting and administration tool that allows stewards to 'run' the bot via that interface, a log entry in the reporting tool is generated when successfully or unsuccessfully run, etc., then I think we could go with a generic name like "RightsBot". Dmehus (talk) 18:12, 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)

Thank you for your service. VancityRothaug (talk + contribs) 20:37, 20 April 2025 (UTC)

Proposal to exempt autopatrolled from inactivity policy

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.

After the discussion was ongoing for roughly one week, there is clear consensus to add the autopatrolled user right to the autoconfirmed permission, and for the autochecked and autoreviewed user groups to be merged with autopatroller and patroller user groups, respectively. Codename Noreste (talk) 17:53, 26 April 2025 (UTC)

---

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)

X, oh, yes, I definitely agree we should keep some of the user groups below sysop for testing of user group management and testing of scripts and such. I just think if we can consolidate some of the largely duplicative groups (reviewer into patroller, for example), it'll clean things up a bit. Dmehus (talk) 17:14, 20 April 2025 (UTC)

I support the first version. Sidrat al-Muntaha (talk) 19:59, 19 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.

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)

Keep me updated on how development goes! Justarandomamerican (talk) 09:10, 21 April 2025 (UTC)

Sure The AP (talk) 07:25, 22 April 2025 (UTC)

Request for approval: Anti-abuse bot

Hi, all! I'm requesting approval to run an anti-abuse bot with Steward rights. This bot would: Check for 5 rights removals in 15 minutes, and if the user performing such rights removals is not on an excluded users list (such list would include stewards and the inactivity bot), it would automatically block the user performing the rights removals and remove their rights. It needs Steward rights because it could be blocked with rights removed by a vandal, and needs to be able to unblock itself and still be able to remove rights in such a case. Justarandomamerican (talk) 20:37, 22 April 2025 (UTC)

• Just as an alteration to the proposal, the bot should only hold steward rights for as long as the operator holds them. EPIC (talk) 21:07, 22 April 2025 (UTC)

 Support with EPIC’s alteration. X (talk + contribs) 21:10, 22 April 2025 (UTC)

Are we sure that, for example, non-vandal users will not be accidentally affected? If so, then  Support. BZPN (talk) 21:50, 22 April 2025 (UTC)

Hey BZPN, the bot is designed to run continuously unless stopped manually. Every minute, it checks recent changes to identify users who have made rights changes. It keeps track of each user’s actions in a separate list. If a user's list exceeds 5 rights changes, the bot automatically removes their rights and blocks them for 7 days. This allows stewards to review whether the user was actually abusing their rights. The AP (talk) 00:09, 23 April 2025 (UTC)

I have an alternative proposal: create a dedicated user group and assign it the following permissions:

$wgRemoveGroups['abuse-bot'] = array('sysop', 'bureaucrat'); // to remove sysop and crat from abusers

$wgGroupPermissions['abuse-bot']['edit'] = true; // permits editing of abuser talk pages

$wgGroupPermissions['abuse-bot']['editprotected'] = true; // allows editing even if the page is protected

$wgGroupPermissions['abuse-bot']['read'] = true;

$wgGroupPermissions['abuse-bot']['bot'] = true; // marks the user as an automated process

$wgGroupPermissions['abuse-bot']['createtalk'] = true; // enables creation of talk pages if they don't exist

$wgGroupPermissions['abuse-bot']['block'] = true; // grants the ability to block users

$wgGroupPermissions['abuse-bot']['unblockable'] = true; // prevents abusers from blocking the bot The AP (talk) 17:01, 23 April 2025 (UTC)

That's a good proposal,  Support. BZPN (talk) 18:31, 23 April 2025 (UTC)

Thanks to everyone who contributes positively here. Since this is a test wiki, it shouldn't be treated like a content wiki. While it's important to stop vandals and spammers to keep things running smoothly, this wiki isn't hosted by a major organization like Wikimedia and has limited resources. So, I suggest avoiding the use of bots running at high speeds (like once per minute). I believe the abuse filters and the current community are enough to handle spammers and vandals. @MacFan4000 probably knows more about this, but I just wanted to share my thoughts. DR (talk) 08:18, 28 April 2025 (UTC)

Looking at Grafana, I see normal CPU, RAM, etc. Justarandomamerican (talk) 10:16, 28 April 2025 (UTC)

Yeah, currently the graphs are normal, but I have not reviewed the source code of that bot, so I am not sure how many requests it will make in a short period. What I wanted to say is that we should run bots as slowly as possible, since there is no urgency, so that human users can access the site smoothly. DR (talk) 10:40, 28 April 2025 (UTC)

I haven't noticed any delay in the site's loading. The bot only requests recent changes, so I estimate each call uses at most around 5 MB of memory, though I might be wrong. As Justa mentioned, the CPU and RAM usage are normal. There have also been instances of abuse involving mass rights removals, and it takes time to respond since not everyone is active all the time. If there is an abuse filter for this, I might consider changing the setup, although I am not aware of any such filters. Also if needed, I can provide the bot's code if Justa agrees. The AP (talk) 12:03, 28 April 2025 (UTC)

Grafana? Where? Justman10000 (talk) 01:36, 9 May 2025 (UTC)

https://grafana.testwiki.wiki DR (talk) 01:40, 9 May 2025 (UTC)

Oh, but I've already submitted a PR Justman10000 (talk) 01:37, 9 May 2025 (UTC)

2FA recommendation/proposal

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.

 Done, per unanimous consensus. I will be confirm all interface administrators and stewards have 2FA enabled and leave those that don’t a talk page message. X (talk + contribs) 16:41, 29 April 2025 (UTC)

---

As a system administrator, I am responsible for site security, and as such, would like to recommend to the community that Stewards and Interface Administrators have 2FA enabled as a requirement. This would patch an important security hole: password guessing/brute forcing. Justarandomamerican (talk) 23:44, 22 April 2025 (UTC)

 Support Obviously required The AP (talk) 23:53, 22 April 2025 (UTC)

 Support. BZPN (talk) 23:54, 22 April 2025 (UTC)

 Support - Drummingman (talk) 18:06, 23 April 2025 (UTC)

 Support. Sidrat al-Muntaha (talk) 04:15, 24 April 2025 (UTC)

I also support this for the record. If it is possible to have a system enforced requirement (as was recently introduced to Wikimedia for example) then that would be great as well. EPIC (talk) 06:05, 24 April 2025 (UTC)

We already have Special:VerifyOATHForUser, and the community is not so big as compared to Wikimedia - so there isn't a necessary requirement for system forced 2FA The AP (talk) 06:33, 24 April 2025 (UTC)

 Support VancityRothaug (talk + contribs) 08:13, 24 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.

TheAstorPastor for Steward and System Administrator

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 isn't a clear consensus to promote unfortunately. The concern raised was that one does not necessarily need to first become a steward in order to become a Sysadmin. Between this and the lack of votes, this request is  Unsuccessful. MacFan4000 ^{(Talk Contribs)} 00:57, 5 May 2025 (UTC)

---

I would like to nominate TheAP for the tools. As he is a technical whiz, I think that he is fit for system administratorship, as well, so that will also be a part of this nomination. He has developed Inactivity bot, which is extremely useful, and he fits all the prerequisites for sysadminship. Justarandomamerican (talk) 00:05, 23 April 2025 (UTC)

I accept the nomination. If you have any questions for me, I’d be happy to answer them. Just to clarify, I’m only accepting the nomination for steward at this time. I believe that being a system administrator requires an exceptional level of trust—even greater than that of a steward. That said, I do intend to reapply for system administrator once I’ve established myself here, which I expect to happen soon. The AP (talk) 00:08, 23 April 2025 (UTC)

Due to a lack of participation, this request has been extended for a minimum of five days, to end no earlier than 4 May. EPIC (talk) 16:31, 29 April 2025 (UTC)

Ok. The AP (talk) 16:35, 29 April 2025 (UTC)

Support

 Support - With the comment that, I agree with TheAstorPastor that it is a good idea to become a steward first. See also my comments here and here, with the comment that I mean this in general terms, so that this says nothing about AP's qualities or my confidence in him as a person. Drummingman (talk) 15:52, 24 April 2025 (UTC)

Procedural support , just to make sure it's valid. It appears some people have voted for themselves, soooooooo The AP (talk) 12:51, 30 April 2025 (UTC)

•  Support I don’t see any issue with it. DR (talk) 16:07, 30 April 2025 (UTC)

Oppose

Neutral

• Per my comments on Discord and in the comments thread below. This is unnecessary as the candidate has earned enough community trust, in my opinion, to forgo stewardship and simply apply for the right they are actually seeking. X (talk + contribs) 00:53, 23 April 2025 (UTC)

Questions/Comments

• I really don’t think you need to be a steward to become a system administrator, it’s a completely different skill set. It is for this reason steward is not a requirement for SA. I encourage you to simply apply to be a system administrator, because that is where we are truly lacking in staff. You have proven yourself to be trustworthy in that capacity, and while I agree that the trust required of a system administrator may be even greater than that of a steward, I disagree that you need one before the other. Best of luck, if you choose to continue! X (talk + contribs) 00:30, 23 April 2025 (UTC)

  Hello X,

  I respectfully disagree with your point. Since you've acknowledged that the role of system administrator carries greater responsibility than that of a steward, I believe the most appropriate way to demonstrate my trustworthiness is by first serving effectively as a steward. Holding IA rights already indicates a level of trust, but steward responsibilities would allow me to further prove myself.

  While the roles differ in some technical aspects, both involve access to tools like CheckUser and Suppression, as well as responsibilities such as appointing IAs—so the skill sets do overlap to a significant degree.

  I’m fully aware of the current shortage of system administrators and genuinely want to contribute to resolving that.However, I still feel it's more suitable for me to apply for steward first.As I mentioned to Justa in a private conversation, I intend to apply for system administrator in about 3–4 months if I am successfully elected as a steward. The AP (talk) 00:41, 23 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.

So...

Well, I've been away for a while! And what do I have to watch? I applied as a steward/system administrator a while ago... What happened? Right! Nobody wanted me! Be it because of trust or competences that I am not supposed to have!

And let's not forget the "good" Tailsultimatefan3891 (talk · contribs)! I still don't know what the action was all about!

But I'll throw the question into the room in general... What is this dirt? Yes, well, I was still quite new! That may be one thing! But yes... one could say, to bring down my competences, especially without proof or at least circumstantial evidence...

In the end, it doesn't matter anyway! Be honest, if I were to nominate myself today or in a week... so in the very near future, would one support me? Hmm, right! I don't think so either!

What I want to get at? I meant that I had to watch something? Right, I mean the TWO NEW stewards! So, again the question, what is this dirt? I mean, sure, the new stewards know what they're doing! But this also applies to me! Justman10000 (talk) 01:58, 9 May 2025 (UTC)

Justman, reading this after some weeks, I'm disappointed that you have such a big craving for permissions. Everywhere, even on a test wiki, not only on content wikis. We normally call this hat collecting. You are talking about competences, but are always angry if you don't get permissions, while communicating in a way ("what is this dirt") that doesn't make you trustworthy for any permission. If the community elects other people for stewardship, and not you, that's their free decision based on what they perceive. And, to be honest, their decision is fully understandable.

This kind of bahavior is happening since years and I really hope that you'll change it sometime in the future because otherwise you will just keep having issues for not willing to understand how wiki communities work and interact. It's not only about permissions, you are often not able or willing to understand legitimate criticism, this is something you should work on, as I told you several times. You are not a child and fully responsible for what you do. Just my two cents, TenWhile6 00:33, 1 June 2025 (UTC)

Inactivity Bot

Greetings, As many of you are likely aware, the Inactivity Bot currently automates the removal of rights based on the inactivity policy, specifically for sysops and bureaucrats. The bot's codebase has become quite cluttered, and I'm planning to clean it up by removing unused and unnecessary functions.

As part of this cleanup, I'm considering removing the notification system. At present, the bot sends a message to users after 75 days of inactivity, warning them that their rights will be removed in 15 days. Personally, I don't think this notification is essential, but I’d like to hear the community’s thoughts before making any significant changes. The AP (talk) 06:26, 11 May 2025 (UTC)

Late reply, but I agree with this. AlPaD (talk) 22:38, 20 June 2025 (UTC)

TheAstorPastor for sysadmin

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.

Successful. Justarandomamerican (talk) 13:49, 9 September 2025 (UTC)

---

I would like to request that the community appoint TheAstorPastor a system administrator. I can vouch for their technical experience, and I have been incredibly busy, causing me to be less able to work on sysadmin work. Justarandomamerican (talk) 15:41, 10 August 2025 (UTC)

I accept the nomination. If you have any questions for me, I’d be happy to answer them. The AP (talk) 15:46, 10 August 2025 (UTC)

 Support trusted Bosco (talk) 15:49, 10 August 2025 (UTC)

 Support ~/Bunnypranav:<ping> 16:18, 10 August 2025 (UTC)

 Support. X (talk + contribs) 19:44, 10 August 2025 (UTC)

I supported you last time, and I am glad to see your application again. The previous request didn't succeed due to limited community participation, so I'd like to ask a question that might help others better understand your experience. Could you walk us through your background with MediaWiki and the technical work you have done so far? DR (talk) 08:13, 11 August 2025 (UTC)

Hello DR,

Thank you for your question. Let me start by sharing how I became involved with MediaWiki. In late 2023 and early 2024, I became interested in MediaWiki primarily because Wikipedia runs on it. I explored the documentation on mediawiki.org and examined the source code of various parts of the software. At the time, my technical background was mainly in other softwares, particularly Java related.

In mid-2024, I began working on a test site where I installed MediaWiki and experimented with different configurations. From that point, my interest in MediaWiki grew significantly. I later joined SkyWiki, a wiki farm, where I initially served as a steward and now work as a system administrator. My contributions there have included assisting users with wiki-specific configuration changes, installing new extensions, setting up Grafana, troubleshooting Phorge, and more.

In early 2025, I contributed to TestWiki by developing two bots: Inactivity Bot, which removes rights from inactive users, and Justarandomamerican (BOT), which monitors for misuse of permissions. I am currently developing a TestWiki-specific MediaWiki extension to automate the removal of rights from inactive users. A screenshot is available here. I have also applied for the position of Technical Advisor for WikiOasis, Justa can confirm this. The AP (talk) 13:28, 11 August 2025 (UTC)

 Support DR (talk) 15:21, 11 August 2025 (UTC)

 SupportTrusted user AlPaD (talk) 16:44, 3 September 2025 (UTC)

---

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

Remove nonexist user rights

Please remove the autoreviewer and reviewer flags from CanonNi and Célian, and remove the reviewer rights from Pro-anti-air and Janus, as the autoreviewer and reviewer rights have been deleted. Bosco (talk) 15:07, 11 August 2025 (UTC)

 Done MacFan4000 ^{(Talk Contribs)} 15:48, 11 August 2025 (UTC)

The next person

Now that the next person has been given the chance to do my dream job, I'm turning my back on this fucking store! I'm sick of getting kicked in the teeth and falling into the dirt! Would anyone here have ever upvoted my sysadmin application? Let alone nominated me? So why give this fucking store another chance? Do whatever you want with my account! I'm not coming back! Justman10000 (talk) 08:56, 26 September 2025 (UTC)

Remove 2FA for Peterxy12

My device was lost, so can you help me remove my 2FA? Peterxy12 (talk) 13:50, 9 October 2025 (UTC)

Confirming that request seems to be from the account owner, per CU. EPIC (talk) 14:36, 9 October 2025 (UTC)

Disabled The AP (talk) 14:51, 9 October 2025 (UTC)

Confirmation on another wiki no longer needed for bureaucrat rights

For transparency, as per steward discussion, the requirement to confirm your account on another wiki before obtaining bureaucrat rights is no longer necessary. Reviewing bureaucrats/stewards may still ask requesting users for confirmation in cases where it may be useful. EPIC (talk) 06:44, 22 October 2025 (UTC)

FYI

I'll be temporarily importing a few hundred English-Wikipedia pages to test an enwiki bot. I'll nuke them when I'm done. Thanks – Test94944 (talk) 16:50, 26 October 2025 (UTC)

Stewardship for ThunderPups*

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.

No chance of passing, especially when you have a history of abusing multiple accounts. MacFan4000 ^{(Talk Contribs)} 04:56, 7 November 2025 (UTC)

---

The strongest reason I want to become a steward on the Test Wiki is to contribute to the technical quality assurance and stability of the entire platform by safely testing new software and administrative tools before they impact millions of live users. ThunderPups* (talk) 22:26, 6 November 2025 (UTC)

---

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

error in mediawiki

Red dust (talk) 21:11, 14 November 2025 (UTC)

Add the bureaucrat permissions to the steward toolset?

For transparency purposes and because stewards are highly trusted, I propose that we add most, if not all of the user rights from the bureaucrat permission and place them into the steward toolset, but we still retain the bureaucrat permission for non-stewards. Codename Noreste (talk) 21:36, 24 November 2025 (UTC)

 Support Don't see why not. Tester (ᴛ•ᴄ) 17:47, 25 November 2025 (UTC)

What purpose does it serve? Can you elaborate? The AP (talk) 18:00, 25 November 2025 (UTC)

Given that stewards are considered the non-test administrators on this wiki (similarly, bureaucrats have some access to non-test user rights), and that stewards can also modify abuse filters with restricted actions (same goes for abuse filter administrator[s]), I think it would be reasonable to also include the bureaucrat user rights in the steward user group (and retain the bureaucrat user group for non-stewards). For example, on the English Wikibooks (where I'm an administrator), that project's administrators had the reviewer (editor) user group in addition to sysop, which was redundant given that administrators over there can review edits and pages. Codename Noreste (talk) 00:45, 27 November 2025 (UTC)

Template:Permissions granted

Hello, Test Wiki community! I recently made a template that merges "Template:Administrator"/"Bureaucrat"/"Interface administrator granted" all in one. It has a parameter that can be followed by a value, and each one contains a different message that serves as a response to successful requests. I was wondering if we can use this template, replacing the aforementioned ones in the userRightsManager gadget, going forward? Username (talk) 04:55, 25 November 2025 (UTC)

I was thinking if a shorter name like Template:Granted would make things concise, since the "permissions" part would be implied anyways. Then one could do something like {{granted|admin}}. Neat idea to combine all the templates into one, though! Tester (ᴛ•ᴄ) 17:46, 25 November 2025 (UTC)

Thanks! And yes, I strongly agree with the new template name you specified and your reasons for it. Thus, I will proceed with that name. Username (talk) 20:57, 25 November 2025 (UTC)