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.
- 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.
- 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
- Support as nominator. VancityRothaug (talk + contribs) 08:13, 31 March 2025 (UTC)
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)- Support sure, good luck! BZPN (talk) 19:26, 31 March 2025 (UTC)
- Support Good luck! Sav • ( Edits | Talk ) 19:15, 1 April 2025 (UTC)
- Support Keep up the good work. -C1K98V (💬 ✒️ 📂) 02:35, 2 April 2025 (UTC)
- Support Bosco (talk) 08:51, 2 April 2025 (UTC)
- Support LisafBia (talk) 09:11, 2 April 2025 (UTC)
- 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:
- 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.
- The Twinkle gadget does not function at all. I intend to replace its content to load via mw.loader.load.
- I would like to convert my script for finding unused pages and files into a gadget.
- I plan to update my MassRollback gadget to a newer version.
- 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)
- That does clarify, thank you. I
- 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)
- 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-pollandsecurepoll-edit-polluser rights into either of:
- 1. The
bureaucratuser group (would require an additional level of trust); or, - 2. The
sysopuser group
- B. Merge the two permissions into the
interwiki-adminuser group, then rename the group Election and Interwiki Administrator (election-interwiki-admin) - C. Maintain the
election-adminuser group, but instead merge theinterwiki-adminpermissions into either of:
- 1. The
bureaucratuser group (would require an additional level of trust); or, - 2. The
sysopuser 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)
