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

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.

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)

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)