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.
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) CentralAuth
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- Per Justarandomamerican, this is
Not done. MacFan4000 (Talk Contribs) 02:38, 17 October 2024 (UTC)
- Per Justarandomamerican, this is
I've suggested it in the past (I think), and I'm gonna suggest it again, but creating a second wiki, maybe testwikibeta or something, and having centralauth would allow for a lot more testing, and I think it would be good, I've looked into it and CA isn't *incredibly* hard to install, so I think it's possible. Zippybonzo (talk) 18:03, 14 October 2024 (UTC)
- I mean in all honesty I think it would be cool to eventually add a couple more wikis onto the site for testing and writing some content. Zippybonzo (talk) 18:04, 14 October 2024 (UTC)
- ZB, though this would be nice, neither MacFan nor I have the technical expertise to install the extension. Justarandomamerican (talk) 18:50, 14 October 2024 (UTC)
- @Justarandomamerican, there's a guide for installing createwiki/managewiki that a mirahezian wrote, which also covers installing CentralAuth here, and I've done it before and am happy to provide assistance should problems occur. Zippybonzo (talk) 20:07, 14 October 2024 (UTC)
- Rejected for not being necessary and consuming too much time. Justarandomamerican (talk) 21:26, 14 October 2024 (UTC)
- @Justarandomamerican -- re not being necessary, I think it would be good for adding testing, and re taking too much time, it takes about 30 minutes, the majority of work is in localsettings.php, and wouldn't take longer than an hour or two to complete at most. Zippybonzo (talk) 06:59, 15 October 2024 (UTC)
- This would have been helpful if TestWiki was hosting one or more TestWikis, but there is only one.. So, why do we need to add CentralAuth for a single TestWiki, I don't think it can be of any use to TestWiki and we should not try to make TestWiki a Wikipedia.Happy testing!---kítєrєtѕu•[@píng mє] 16:29, 15 October 2024 (UTC)
- @Kiteretsu, my point is we could either branch out and provide other wikis, or create a second wiki for testing CentralAuth. Zippybonzo (talk) 17:44, 15 October 2024 (UTC)
- I'm opposed to this idea, one test wiki is good enough and as mentioned on discord centrelauth would be restricted which will make it untestable to users. Cocopuff2018 (talk) 19:25, 15 October 2024 (UTC)
- Just stopping by to lay out my thoughts on this:
- TestWiki should be committed to providing the best place to test the most amount of MediaWiki tools possible. Central Auth is a pretty integral part of many large Wikis and farms. Hence, allowing users to test its functions would be useful.
- I have heard some good points though: We don’t have a second wiki, it’s unneeded, it’s hard to install, etc.
- I would personally suggest that, if we were to implement this concept, that we could create a second wiki that is completely locked from editing, with a home page that describes its purpose is to simply be a second wiki for Central Auth testing.
- I don’t quite understand the logic of it being unnecessary. If we can provide a place to test tools other testwikis don’t have, that’s a huge positive. I do, however, understand the technical issue of actually installing it. Our two current SAs don’t have the time or ability to install it and I doubt they would be willing to allow a non-system admin install it.
- So in conclusion: If it is technically feasible, I Support. X (talk + contribs) 19:43, 15 October 2024 (UTC)
- Re the second wiki, it could be used as beta for testing extensions before deploying them to prod. Zippybonzo (talk) 19:44, 15 October 2024 (UTC)
- I'm opposed to this idea, one test wiki is good enough and as mentioned on discord centrelauth would be restricted which will make it untestable to users. Cocopuff2018 (talk) 19:25, 15 October 2024 (UTC)
- @Kiteretsu, my point is we could either branch out and provide other wikis, or create a second wiki for testing CentralAuth. Zippybonzo (talk) 17:44, 15 October 2024 (UTC)
- Hi. Points taken. However, there isn't anything to test in CA that wouldn't have to be restricted to Stewards beyond simply viewing local accounts. As such, this is rejected. Justarandomamerican (talk) 01:33, 17 October 2024 (UTC)
- This would have been helpful if TestWiki was hosting one or more TestWikis, but there is only one.. So, why do we need to add CentralAuth for a single TestWiki, I don't think it can be of any use to TestWiki and we should not try to make TestWiki a Wikipedia.Happy testing!---kítєrєtѕu•[@píng mє] 16:29, 15 October 2024 (UTC)
- @Justarandomamerican I am sorry, but @MacFan4000 is the global system administrator for Miraheze and a third-party SA for Wikimedia, so I am confused as to why MacFan4000 isn't capable of doing so. The AP (talk) 09:51, 16 October 2024 (UTC)
- My mistake! MacFan has said in the past on phabricator that he doesn't have the expertise to do so, so I assumed that was also the case today. Justarandomamerican (talk) 10:27, 16 October 2024 (UTC)
- @Justarandomamerican -- re not being necessary, I think it would be good for adding testing, and re taking too much time, it takes about 30 minutes, the majority of work is in localsettings.php, and wouldn't take longer than an hour or two to complete at most. Zippybonzo (talk) 06:59, 15 October 2024 (UTC)
- @Justarandomamerican, there's a guide for installing createwiki/managewiki that a mirahezian wrote, which also covers installing CentralAuth here, and I've done it before and am happy to provide assistance should problems occur. Zippybonzo (talk) 20:07, 14 October 2024 (UTC)
- ZB, though this would be nice, neither MacFan nor I have the technical expertise to install the extension. Justarandomamerican (talk) 18:50, 14 October 2024 (UTC)
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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
| Not done as there is no consensus to require 2FA on highly privileged groups at this time. Codename Noreste 🤔 Talk 21:27, 18 November 2024 (UTC) |
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)
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)
- 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)
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)
- Not sure you understand the purpose of this request. X (talk + contribs) 00:47, 24 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)
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)
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)
- 0 /var/www/html/includes/Revision/RevisionStore.php(1227): MediaWiki\Extension\Newsletter\Content\NewsletterContentHandler->unserializeContent()
- 1 /var/www/html/includes/Revision/RevisionStore.php(1510): MediaWiki\Revision\RevisionStore->loadSlotContent()
- 2 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
- 3 /var/www/html/includes/Revision/SlotRecord.php(324): call_user_func()
- 4 /var/www/html/includes/Revision/RevisionRecord.php(183): MediaWiki\Revision\SlotRecord->getContent()
- 5 /var/www/html/includes/Revision/RenderedRevision.php(229): MediaWiki\Revision\RevisionRecord->getContentOrThrow()
- 6 /var/www/html/includes/Revision/RevisionRenderer.php(226): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
- 7 /var/www/html/includes/Revision/RevisionRenderer.php(164): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
- 8 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()
- 9 /var/www/html/includes/Revision/RenderedRevision.php(199): call_user_func()
- 10 /var/www/html/includes/poolcounter/PoolWorkArticleView.php(91): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
- 11 /var/www/html/includes/poolcounter/PoolWorkArticleView.php(73): MediaWiki\PoolCounter\PoolWorkArticleView->renderRevision()
- 12 /var/www/html/includes/poolcounter/PoolCounterWork.php(171): MediaWiki\PoolCounter\PoolWorkArticleView->doWork()
- 13 /var/www/html/includes/page/ParserOutputAccess.php(328): MediaWiki\PoolCounter\PoolCounterWork->execute()
- 14 /var/www/html/includes/page/Article.php(760): MediaWiki\Page\ParserOutputAccess->getParserOutput()
- 15 /var/www/html/includes/page/Article.php(563): Article->generateContentOutput()
- 16 /var/www/html/includes/actions/ViewAction.php(78): Article->view()
- 17 /var/www/html/includes/actions/ActionEntryPoint.php(733): ViewAction->show()
- 18 /var/www/html/includes/actions/ActionEntryPoint.php(510): MediaWiki\Actions\ActionEntryPoint->performAction()
- 19 /var/www/html/includes/actions/ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
- 20 /var/www/html/includes/MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
- 21 /var/www/html/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
- 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)
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)
- This is nonsensical and completely against the wiki’s goal and purpose.
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)
