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)

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)

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
• autopatrolled
• chatmod
• reviewer

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)