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

Grace periods

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

 Done X (talk + contribs) 19:27, 21 November 2024 (UTC)

---

One of my pet peeves is that people are establishing the grace period for users' rights too early. People should wait a little longer to do it so that the day of the new grace period and expiration date are close to each other. Thus, I might revert the grace period that was added to London's rights earlier today, despite the expiration date being entirely correct, but too far from today. But, with grace periods (PLUS CORRECTIONS) comes an extremely clogged log so likely I won't this time.

Now that I think about it, I will probably retire from doing grace periods soon (most likely today), and I will try notifying users about their rights differently, via their talk pages two weeks before supposedly But this idea isn't final. Tsukushi (talk) 21:02, 8 September 2024 (UTC)

We've had this system for a while and it's both fair and useful. No reverts should be made unless a Steward agrees with the decision, as up until now there have been no issues. Sav • ( Edits | Talk ) 01:43, 9 September 2024 (UTC)

I think we should add a section to the inactivity policy about grace periods (how long they should be, when they should be set, etc.) I don't think we should retire the practice, as it's quite useful to both bureaucrats and users having their rights removed. Justarandomamerican (talk) 18:33, 9 September 2024 (UTC)

On second thought, never mind. I going to stick with the practice as I still enjoy doing/using it. And about the inactivity policy, I agree. Tsukushi (talk) 16:44, 15 September 2024 (UTC)

RFC: Adding a section to the inactivity policy on grace periods

I propose that the following section be added to the inactivity policy: "Grace periods are an optional way of enforcing this policy. Grace periods involve making the inactive user's rights expire in 2 weeks when they would have otherwise been removed in 2 weeks. It adds extra notification to the inactive user, who can always change their rights back." Justarandomamerican (talk) 18:14, 15 September 2024 (UTC)

 Support: This explains it all. Tsukushi (talk) 00:19, 23 September 2024 (UTC)

---

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

RequestSolver

Hi.Everyone, I've keeping on here a proposal of RequestSolver using on the permission page and community portal for marking request manually as done, not done, already done and on hold.etc, I've feel happy if known to what think about this proposal of others users for this proposal.Happy testing ---kítєrєtѕu•[@píng mє] 05:50, 13 September 2024 (UTC)

Retirement

Since my work is neither recognised or even accepted of, and also because no one wants to give me a chance, I feel compelled to stop my work here... As system administrator, I could have done a lot of work... However, since I was already rejected there and told to become a steward first... So I wanted to do this, and?

PS: If I really wanted to harm this project, I would have done it long ago! Justman10000 (talk) 17:31, 15 September 2024 (UTC)

I'm sorry. Your contributions are valued. They always have been. Nobody thinks you're going to harm the project, there are just already 2 active stewards, which people think is enough. I sincerely hope you come back soon! Justarandomamerican (talk) 18:20, 15 September 2024 (UTC)

Request for edit

Please mark on the MediaWiki:Gadget-MassRollback.js gadget page (using a comment (//) at the top of the script), that I am its author. User Xaloria copied my script from PTW ([1]) without my knowledge. Although it is not protected by copyright, I would like to be listed as the author :). Ping for recently active IA: @Justarandomamerican, @Kiteretsu, @TheAstorPastor. Best regards, BZPN (talk) 18:54, 6 October 2024 (UTC)

Thank you for the notification! This will be done. Justarandomamerican (talk) 18:56, 6 October 2024 (UTC)

 Done. Justarandomamerican (talk) 19:01, 6 October 2024 (UTC)

Thank you! BZPN (talk) 19:02, 6 October 2024 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Tester (ᴛ•ᴄ) 11:16, 21 December 2024 (UTC)

Tailsultimatefan3891's sockpuppets

Considering that Tailsultimatefan3891 has now been unblocked for a while, should I remove all of the sockpuppets from this category and have them unblocked as well? Tsukushi (talk) 06:28, 29 October 2024 (UTC)

I don't see why we would unblock sockpuppets, but keeping the main unblocked seems fine. Zippybonzo (talk) 12:38, 29 October 2024 (UTC)

Require 2FA for highly privileged groups

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'm proposing that we should require 2FA for Interface Admin, Steward and Sysadmin group members as security precautions, as IAs can edit pages that would allow them privilege escalation, and stewards/sysadmins can give such permissions out which could cause issues if their accounts were compromised. Additionally, I think bots with admin/iadmin perms should have 2FA required as they are probably less monitored security wise. Zippybonzo (talk) 10:44, 12 November 2024 (UTC)

& it should probably be required for AFAs Zippybonzo (talk) 10:46, 12 November 2024 (UTC)

 Oppose: We haven’t had any issues with accounts with elevated permissions being compromised. If the community trusts them to hold the permissions, than they can also be trusted to make sure their account is secure. X (talk + contribs) 11:10, 12 November 2024 (UTC)

 Oppose: I don't see a reason to add it since the rate of accounts being compromised has been vary low --Cocopuff2018 (talk) 14:24, 12 November 2024 (UTC)

 Oppose There hasn't been a case where an account was compromised, so I don't see any reason to make 2FA mandatory The AP (talk) 16:01, 12 November 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Name Change Request

Hi, can my name please be changed to Skiyomi? (to match my Wikimedia name) Thank you! Piccadilly (My Contribs | My Messages) 19:54, 19 November 2024 (UTC)

Going to go ahead and mark this as  Not done. Renaming would cause additional confusion, especially given the extraordinary circumstances that apply to you. Additionally, you requested a rename in March saying "This will be my last rename request here." X (talk + contribs) 19:25, 21 November 2024 (UTC)

I can understand the concern about confusion, and I do accept this decision. But what "extraordinary circumstances" do you mean? Piccadilly (My Contribs | My Messages) 20:20, 21 November 2024 (UTC)

Your history as an LTA and no warning (straight block) upon abuse. X (talk + contribs) 22:32, 21 November 2024 (UTC)

RFC: Remove Inactivity Clause

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

 Done More than three weeks have passed since the discussion began.With three votes in support and only one in opposition, I am closing this discussion and removing the clause from the policy. The AP (talk) 10:15, 15 December 2024 (UTC)

---

The current Inactivity policy states that "These [Steward or system administrator] rights may be restored within 1 hour of them being removed; otherwise, a reconfirmation vote will be held."

If a user holding this level of advanced permissions has been inactive for six months, a one hour request-back, without community input, does not make a lot of sense. X (talk + contribs) 19:50, 21 November 2024 (UTC)

Discussion

•  Support as requester. X (talk + contribs) 19:50, 21 November 2024 (UTC)

  Just a clarification: I am proposing removing the clause completely; they would have to re-RfS. X (talk + contribs) 00:46, 24 November 2024 (UTC)

•  Comment: instead of a one-hour reconfirmation request, does one who lose their advanced permission must run through another community vote? Codename Noreste 🤔 Talk 15:13, 22 November 2024 (UTC)

  I think they should if they want to regain their rights The AP (talk) 15:51, 22 November 2024 (UTC)

•  Oppose 1 hour is a bit short, but I feel 24 hours is more reasonable. Zippybonzo (talk) 15:55, 22 November 2024 (UTC)

  Not sure you understand the purpose of this request. X (talk + contribs) 00:47, 24 November 2024 (UTC)

  I do, I feel that if you've been inactive, within 24 hours it's perfectly reasonable to request them back. Zippybonzo (talk) 08:01, 25 November 2024 (UTC)

•  Support, agree with proposal. BZPN (talk) 16:22, 24 November 2024 (UTC)
• I guess one hour makes no sense, due to the fact that no one can be 24/7 online. That's why I  Support this request. --TenWhile6 17:26, 10 December 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Rename request

Please change my username and my bot (PB08-bot) to Bosco and Bosco-bot respectively, thanks. PB2008 (talk) 12:57, 9 December 2024 (UTC)

This is now  On hold awaiting Steward decision - you should receive a response soon. VancityRothaug (talk) 16:28, 9 December 2024 (UTC)

 Done. Drummingman (talk) 17:24, 9 December 2024 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Tester (ᴛ•ᴄ) 11:17, 21 December 2024 (UTC)

Internal error

The following error is displayed when visting Newsletter:Administrators' newsletter

[ba26798e8f169f81e1f6821f] /wiki/Newsletter:Administrators%27_newsletter MWContentSerializationException: The Newsletter content is invalid.

Backtrace:

from /var/www/html/extensions/Newsletter/includes/Content/NewsletterContentHandler.php(72)

1. 0 /var/www/html/includes/Revision/RevisionStore.php(1227): MediaWiki\Extension\Newsletter\Content\NewsletterContentHandler->unserializeContent()
2. 1 /var/www/html/includes/Revision/RevisionStore.php(1510): MediaWiki\Revision\RevisionStore->loadSlotContent()
3. 2 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
4. 3 /var/www/html/includes/Revision/SlotRecord.php(324): call_user_func()
5. 4 /var/www/html/includes/Revision/RevisionRecord.php(183): MediaWiki\Revision\SlotRecord->getContent()
6. 5 /var/www/html/includes/Revision/RenderedRevision.php(229): MediaWiki\Revision\RevisionRecord->getContentOrThrow()
7. 6 /var/www/html/includes/Revision/RevisionRenderer.php(226): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
8. 7 /var/www/html/includes/Revision/RevisionRenderer.php(164): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
9. 8 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()
10. 9 /var/www/html/includes/Revision/RenderedRevision.php(199): call_user_func()
11. 10 /var/www/html/includes/poolcounter/PoolWorkArticleView.php(91): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
12. 11 /var/www/html/includes/poolcounter/PoolWorkArticleView.php(73): MediaWiki\PoolCounter\PoolWorkArticleView->renderRevision()
13. 12 /var/www/html/includes/poolcounter/PoolCounterWork.php(171): MediaWiki\PoolCounter\PoolWorkArticleView->doWork()
14. 13 /var/www/html/includes/page/ParserOutputAccess.php(328): MediaWiki\PoolCounter\PoolCounterWork->execute()
15. 14 /var/www/html/includes/page/Article.php(760): MediaWiki\Page\ParserOutputAccess->getParserOutput()
16. 15 /var/www/html/includes/page/Article.php(563): Article->generateContentOutput()
17. 16 /var/www/html/includes/actions/ViewAction.php(78): Article->view()
18. 17 /var/www/html/includes/actions/ActionEntryPoint.php(733): ViewAction->show()
19. 18 /var/www/html/includes/actions/ActionEntryPoint.php(510): MediaWiki\Actions\ActionEntryPoint->performAction()
20. 19 /var/www/html/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
21. 20 /var/www/html/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
22. 21 /var/www/html/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
23. 22 {main}

I believe since PB2008 has been renamed recently and he was a subscriber of the newsletter - his account needs to removed from the list ; kindly look at this similar error reported at phabricator The AP (talk) 20:51, 9 December 2024 (UTC)

pinging @Justarandomamerican and @MacFan4000 as they are Sys admins The AP (talk) 20:52, 9 December 2024 (UTC)

Fixed Justarandomamerican (talk) 22:24, 9 December 2024 (UTC)

Requesting permissions removal from TenWhile6

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

I am assuming good faith in this case—that User:VancityRothaug made this request with the right intentions. However, it’s important to understand that we do not remove rights from users simply because we believe they might not use them in the near future. Rights are removed only if users meet the criteria outlined in the inactivity policy. Since reinstating rights to an account is considered a logged-in action, the user is considered active. I encourage VancityRothaug to carefully review the list showing users’ most recent logged actions and to apply grace periods only after thoroughly checking the dates of those actions. The AP (talk) 18:03, 10 December 2024 (UTC)

---

Dear community, I hope this request finds you all well. On the 9th December I have filed a inactivity grace period against @TenWhile6 for being inactive for a period of 2 months, and set their rights to expire in 2 weeks, when the inactivity would reach 3 months as per the inactivity policy. The user has proceeded to make their rights permanent 3 minutes after the grace period notification was left on their talk page. Upon checking their user contributions I have seen that the user has received a grace period warning on the 23rd September, to which they responded wishing to keep their roles however after checking the users contributions further I have noticed that they have not edited at all since their reply to their first grace period notice. From my point of view, I believe this user is not showing any intent to use his permissions in the near future therefore I am beginning this community vote to have the users permissions removed. VancityRothaug (talk) 17:04, 10 December 2024 (UTC)

You may read the Test Wiki:inactivity policy again. no edits or logged actions within the last three months means that your actions on 9th december ([2] and [3]) were a clear violation of the policy, because my last logged action was on 6th december. I know you are pretty new here, sysop since two weeks, but please try to be more careful.

As an explanation why I am not really active here: I am an active member of the wikimedia community, currently serving as a global sysop and sysop in two wikis. Sometimes I need to test things and thats the exact moment when I need my permissions here, that's why I want to keep them and why I will clearly use these permissions in the future. TenWhile6 17:09, 10 December 2024 (UTC)

Discussion

•  Support as requester. VancityRothaug (talk) 17:05, 10 December 2024 (UTC)
• I will not "vote" here, because I am obviously involved. But imo this is not backed up by any policy, as explained above. I am an active member of the Wikimedia Community and there is basically no reason to make this complicated. This is a test wiki and I could literally request the permissions again, if they get removed. This request is one of the funniest and most unnecessary things that happend to me this year. --TenWhile6 17:17, 10 December 2024 (UTC)

This is nonsensical and completely against the wiki’s goal and purpose.  Not done X (talk + contribs) 17:50, 10 December 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request for Rename

Hello, I would like to request that this account be renamed to Alachuckthebuck, my username on wikimedia projects. link to userpage. 0hD33r! (talk) 00:14, 17 December 2024 (UTC)

 Done by Justarandomamerican (log id 56662) Tester (ᴛ•ᴄ) 15:01, 17 December 2024 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Tester (ᴛ•ᴄ) 11:17, 21 December 2024 (UTC)

Delegated rights and the inactivity policy

Currently, for rights that are very high trust and delegated from Stewards or the community (such as NSS and AFA), those rights can be re-requested at any time. I would propose removing that clause, but I would like to hear the ideas of others: What should happen if a person holding one of those rights loses them due to inactivity and then re-requests them? Justarandomamerican (talk) 14:05, 17 December 2024 (UTC)

Discussion

I  Support the removal of this clause from the inactivity policy. I believe that an inactivity removal should be treated as a normal removal and hence require another community vote to regain their position. VancityRothaug (talk) 15:45, 17 December 2024 (UTC)

 Oppose, if the user already got approval to get those rights in the first place (i.e. they are trusted to handle sensitive role(s)), why over-complicate things just because of inactivity? If someone has a concern, they can just share it when the user re-requests the rights. There may be some exceptions but I'd otherwise support keeping the clause in. Tester (ᴛ•ᴄ) 15:55, 17 December 2024 (UTC)