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

Piccadilly Appeal Terms

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

Both proposals successful. Piccadilly may not be unblocked unless a year has passed and the community (in addition to Stewards) accept an appeal. I will add to this in my sole discretion: Piccadilly may not be unblocked unless concrete evidence of actual change has been submitted, either in the form of proof of attendance in a therapy program, or if there has been at least 1 year of good behavior in another community. Justarandomamerican (talk) 22:34, 21 January 2025 (UTC)

---

The following is a community request for comment about Piccadilly’s appeal timeframe and form as the user has been blocked again. Please express your opinion on each proposal. X (talk + contribs) 00:46, 14 January 2025 (UTC)

Extend appeal timeframe

Piccadilly is currently prohibited from appealing their ban for a period of 6 months, per Drummingman’s initial unblock conditions. I propose extending this time to one year as the user has made it clear to us over and over that they will not change. They keep coming back every 3-6 months with no behavioral difference. X (talk + contribs) 00:46, 14 January 2025 (UTC)

•  Support: As proposer. X (talk + contribs) 00:46, 14 January 2025 (UTC)
•  Support: --Cocopuff2018 (talk) 04:35, 14 January 2025 (UTC)
•  Support AlPaD (talk) 15:29, 14 January 2025 (UTC)
•  Support --TenWhile6 08:46, 15 January 2025 (UTC)

Community appeal only

Additionally, I propose requiring that, for Piccadilly to be unblocked, there is a community appeal discussion. Piccadilly has abused the community enough to where they deserve a direct say in any appeal. The process would look like this: Piccadilly waits the selected timeframe. Piccadilly appeals to the steward email address. Stewards discuss appeal internally, and if approved, forward it to the community for a discussion on the community portal. I and others are frustrated with how this continues to be handled and the leniency to which we give LTAs. This proposal would give some say back to the community. X (talk + contribs) 00:46, 14 January 2025 (UTC)

•  Support, as proposer. X (talk + contribs) 00:46, 14 January 2025 (UTC)
•  Support: --Cocopuff2018 (talk) 04:35, 14 January 2025 (UTC)

 Support -Piccadilly always Violate Test Wiki policy and every time blocked by Stewards and Bureaucrats for violation of Test Wiki's policy and also for it's work. I'll be suggesting please avoid unblocked for Piccadilly because I have special concerns to them after unblocking they 'll be trying to violated again Test Wiki's policy and @Drummingman: is great guy and they think and decided to grant a chance again to Piccadilly for it's unblocking. Happy testing!--- Bhairava7 • (@píng mє-tαlk mє)

•  Support - I have reviewed their activity on Test Wiki in detail and I see no attempts to change behavior, leading me to the conclusion that this proposal would fit the community better. VancityRothaug (talk + contribs) 11:31, 14 January 2025 (UTC)
•  Support Unfortunately Piccadilly hasn't changed her behaviour. AlPaD (talk) 15:27, 14 January 2025 (UTC)
•  Support --TenWhile6 08:46, 15 January 2025 (UTC)
• I weakly  Support with special recommendations to Stewards, as someone who has dealt with this user for some time. This issue resembles exactly what happened with Apex (previous name) on Miraheze, viewable at Miraheze: Global ban for ApexAgunomu in the RfC section. This RfC was after Apex was poorly managed at Steward level and given many many many chances only to squash them all. So it became necessary for the community to opine where it realistically shouldn't have to, in ideal circumstances stewards will have reasonable expectations and only unblock when evidence suggests the pattern will not repeat. If stewards are to humor/pass through an appeal, they should do so with one of two expectations (neither involving how much time has passed or how much Apex promises to do better). They should see a pattern at some other community of Apex contributing without outbursts or being blocked long term. Or there should be reasonable evidence that Apex has sought professional help and growth for these outbursts that have plagued her across several platforms. Nothing less in this circumstance would make sense. If an appeal is forwarded to the community without assurances of either, the community should take up the task of looking for this evidence. --raidarr (💬) 18:19, 15 January 2025 (UTC)

---

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

Restrict abusefilter-access-protected-vars and abusefilter-protected-vars-log to AFAs and stewards?

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

Doing, as there have been no objections within 4 days. Justarandomamerican (talk) 17:24, 18 January 2025 (UTC)

---

Because abusefilter-access-protected-vars have the potential for regular administrators (who might not be familiar with abuse filters) to mark a filter as permanently protected without the ability to reverse it, I suggest we should restrict it to only abuse filter administrators and stewards who have the trust of the community to work with filters that might cause huge disruption if configured incorrectly, the same way as abusefilter-modify-restricted. Similarly, the log for abuse filter regarding protected variables might also have to be restricted to those two groups, since they might deal with personal information. Codename Noreste (talk) 18:31, 14 January 2025 (UTC)

Discussion

•  Support as the proposer. Codename Noreste (talk) 18:31, 14 January 2025 (UTC)
•  Support due to this user right having the power to make sensitive and irreversible changes to abuse filters. VancityRothaug (talk + contribs) 19:03, 14 January 2025 (UTC)
•  Support --TenWhile6 08:48, 15 January 2025 (UTC)
•  Support per Tenwhile --- Bhairava7 • (@píng mє-tαlk mє) 09:17, 15 January 2025 (UTC)

---

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

‪DisambiguousMonths

Can a steward remove he all his rights because he unblocked self, and re-give to bureaucrats there rights.And re-block it.Sorry for my bad english but i repeat i'm french.DodoMan (talk) 08:20, 15 January 2025 (UTC)

 Done by DrummingMan. DodoMan (talk) 08:21, 15 January 2025 (UTC)

all actions reversed. --TenWhile6 08:45, 15 January 2025 (UTC)

Because of this, we should restrict giving bureaucrat rights to only stewards. Codename Noreste (talk) 08:47, 15 January 2025 (UTC)

I don't think thats the right answer to this abuse. TenWhile6 08:49, 15 January 2025 (UTC)

Perhaps not that, but we should maybe restrict removing bureaucrat rights to stewards, and remove the unblockself right from Bureaucrats? It would certainly prevent the abuse, but then Stewards would have to manage the inactivity policy with Bureaucrats. Justarandomamerican (talk) 08:54, 15 January 2025 (UTC)

I agree with those options. Codename Noreste (talk) 09:00, 15 January 2025 (UTC)

I agree with Justa's comment. --- Bhairava7 • (@píng mє-tαlk mє) 09:01, 15 January 2025 (UTC)

To be honest, we have never really had an issue with crat abuse before, I feel like making multiple rights changes is a little brash. X (talk + contribs) 11:14, 15 January 2025 (UTC)

I disagree. It's not rash to implement preventative measures after a problem occurs. I'm not sure what the alternative is. Wait until the problem occurs more?Justarandomamerican (talk) 13:41, 15 January 2025 (UTC)

Justa's idea (restrict removing bureaucrat rights to stewards) is something we can discuss. I'd suggest to create a new section and do a community vote on this. TenWhile6 14:45, 15 January 2025 (UTC)

If stewards are up to taking on the role of managing bureaucrats' inactivity, I have no problem with supporting!

I suppose removing unblockself could cause inconveniences, as that could prevent one from undoing a test block on oneself. Also, if someone else with rights goes rogue and blocks a bureaucrat, they would then have to wait for someone else to undo their block. Why not just remove privileges when blocking someone? Tester (ᴛ•ᴄ) 14:46, 15 January 2025 (UTC)

@TenWhile6: Hi there, What is the exact answer of this abuse.😅--- Bhairava7 • (@píng mє-tαlk mє) 08:52, 15 January 2025 (UTC)

It is not necessarily a good idea to restrict bureaucrat assignment and removal because of two main factors. One is that it's plainly quite rare an instance, although Justa is correct that if there is an issue then it should be patched and we shouldn't hope that people won't do it again. That is burying one's head in the sand. The other factor is that restricting bureaucrat grant/removal without altering standards is that a future abuser can simply do it again and change their tactics. They can make a different stream of hard to reverse actions and not be easily handled by a fellow bureaucrat. A Steward's intervention will be required in one example, in the other it might but won't necessarily be required. Removing permissions is relatively simple to undo and this incident was dealt with quite expediently. The train of abuse goes deep in a rabbit hole: to pick apart another suggestion, not permitting unblockself means a rogue bureaucrat can simply block everyone else first and then that's another problem that's harder to resolve. On top of the inconvenience already suggested.

Instead, it seems to me a reasonable answer is to increase the surface of people who can deal with the problem. Perhaps there should be an autopatrolled type access for more senior testers/bureaucrats, whom's access cannot be removed by 'mere' bureaucrats. This lets more established bureaucrats or even trusted but not very active community members deal with rogues and make it harder to sneak in and gain destructive, harder to reverse access with the minimum standard of autoconfirmed that bureaucrats currently have. This would be their only access and it could be assigned at the trust of stewards so there are more people who could respond to an incident like this, but wouldn't complicate everyday operation by requiring a steward step in for every instance of bureaucrat addition and removal and going rogue. This answer might have problems but I think it's a more elegant place to start.

My 2c,

--raidarr (💬) 17:23, 15 January 2025 (UTC)

SecurePoll on Test Wiki

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

Consensus seems to be for option #4 (install only for testing, will not be used for community discussions/votes. MacFan4000 ^{(Talk Contribs)} 20:07, 22 January 2025 (UTC)

---

There has recently been a discussion on Phorge regarding the addition of the SecurePoll Extension to Test Wiki. @MacFan4000 said that community consensus is required to add the extension so I would like to ask the community on how they would like to see the extension accommodated in 2 easy options to select: Option 1 - SecurePoll is a Steward-only tool used for hosting community discussions. Option 2 - SecurePoll is a tool usable by everyone, for both community discussions and for testing purposes. Option 3 Dont add SecurePoll to Test Wiki. With kind regards, VancityRothaug (talk + contribs) 14:13, 17 January 2025 (UTC)

Option 1

This would involve adding SecurePoll as a steward-only extension.

 Support as requester. VancityRothaug (talk + contribs) 14:16, 17 January 2025 (UTC)

 Withdraw VancityRothaug (talk + contribs) 17:57, 17 January 2025 (UTC)

 Strong oppose The whole reason I requested this extention in phab:T117 is because this is heavily restricted in Wikimedia wikis, and will be useful for the community as a whole to test. ~/Bunnypranav:<ping> 15:26, 17 January 2025 (UTC)

 Strong oppose This extension should not be used for non testing reasons, like community discussions. X (talk + contribs) 18:17, 17 January 2025 (UTC)

 Oppose --TenWhile6 00:00, 20 January 2025 (UTC)

Option 2

This would involve adding SecurePoll for everyone.

 Strongest support as requester. VancityRothaug (talk + contribs) 14:16, 17 January 2025 (UTC)

 Strong support See my above comment. ~/Bunnypranav:<ping> 15:26, 17 January 2025 (UTC)

I am a little confused. On another proposal you said that you did not want this to be used for community discussions. X (talk + contribs) 18:15, 17 January 2025 (UTC)

@X Correct me if I'm wrong, but isn't this option to grant the rights to create/edit polls to everyone for testing? ~/Bunnypranav:<ping> 03:11, 18 January 2025 (UTC)

This one is for testing AND community discussion. Option four is just testing. X (talk + contribs) 17:20, 18 January 2025 (UTC)

If that's the case, I have striked my vote. Other comments by me should clarify my stance. ~/Bunnypranav:<ping> 17:56, 18 January 2025 (UTC)

 Support would be helpful, assuming the PII issue with election admins gets fixed. Alachuckthebuck (talk) 17:50, 17 January 2025 (UTC)

 Strong oppose This extension should not be used for non testing reasons, like community discussions. X (talk + contribs) 18:15, 17 January 2025 (UTC)

The “for everyone” part implies that everyone would be granted access to this extension though. VancityRothaug (talk + contribs) 18:59, 17 January 2025 (UTC)

Your original statement was “ SecurePoll is a tool usable by everyone, for both community discussions and for testing purposes” As long as the extension is being used for non-testing purposes, I oppose. X (talk + contribs) 20:13, 17 January 2025 (UTC)

You’re most certainly right hence why I have switched my support to the 4th option which excludes all usage from non-testing purposes. VancityRothaug (talk + contribs) 21:40, 17 January 2025 (UTC)

Option 3

This involves voting against the addition of SecurePoll.

 Support as requester. VancityRothaug (talk + contribs) 14:16, 17 January 2025 (UTC)

 Withdraw . VancityRothaug (talk + contribs) 17:58, 17 January 2025 (UTC)

 Support, avoiding redundant votes in other headers to explain my piece here. I do not believe SecurePoll brings anything to TestWiki. It is meant for specific use which I challenge even being overly suitable for Miraheze let alone a far smaller project. There is effectively nothing to be tested, nothing that is practical in the everyday life of MediaWiki that TestWiki is available for. There is less in this respect to test than say, CentralAuth, which itself has a host of (admittedly somewhat different) reasons it would not be suitable. Other extensions or features would make sense to me before this one. So SecurePoll is neither suitable for testing or non testing purposes. --raidarr (💬) 23:47, 17 January 2025 (UTC)

@Raidarr There is stuff to be tested right? SecurePoll has various poll types and voter suffrage requirements to name a couple. Could you explain how it'll harm by adding this extension? Thanks. ~/Bunnypranav:<ping> 03:16, 18 January 2025 (UTC)

My question with this extension is twofold; what is there worth to test, and what value is it to be tested. In the case of most other extensions there are utilities for everyday sysops where it makes sense to get the ins and outs of the behavior. SecurePoll is an obscure, involved extension best involved when keys are being handled by trusted third parties for poll integrity, and since this relates to PII and tech duty I don't see this being meaningfully tested in any graphical way. The result is a point and click extension with extremely low market use. Hence not much brought to the table for testing purposes to merit the care of addition and whatever quirks, known or unknown its inclusion may bring.

This is a single vote, perhaps two when considering Justa paired with five, so if this logic does not compell the mass it is fine, and I do not feel strongly enough to persist further as nothing is necessarily harmed by adding it. I simply wish for more than the slim explanation and 'meh why not' to merit addition.

As a completely off topic point I recommend withdrawn/modified votes be struck by the original voter when this is done, as the reply with 'withdraw' or reply that starts with a withdraw and makes a barely noticeable change to the vote strength can be mildly confusing. --raidarr (💬) 09:40, 18 January 2025 (UTC)

I was planning to close this, but I am going to support this option now, per the articulate reasoning of Raidarr. Justarandomamerican (talk) 00:09, 18 January 2025 (UTC)

Option 4

This would involve installing SecurePoll and using it only for testing, not community discussion.

 Support X (talk + contribs) 14:18, 17 January 2025 (UTC)

 Support Community discussion is a discussion for a reason, SecurePoll is a vote. With the limited participants (not in the order of hundreds) in discussions/sensitive perm requests here setting up a SecurePoll is a waste of time. ~/Bunnypranav:<ping> 15:26, 17 January 2025 (UTC)

 Strong support per Bunnypranav. VancityRothaug (talk + contribs) 19:12, 17 January 2025 (UTC)

 Withdraw , switching to  Strongest support. There’s no point in using SecurePoll for discussions. VancityRothaug (talk + contribs) 21:41, 17 January 2025 (UTC)

 Strongest support MacFan4000 ^{(Talk Contribs)} 21:33, 17 January 2025 (UTC)

 Strongest support DodoMan (talk) 07:53, 18 January 2025 (UTC)

 Support --TenWhile6 00:00, 20 January 2025 (UTC)

Discussion

@VancityRothaug: How are you supporting both option 1, 2 and 3, which from my understanding are completely opposite viewpoints. ~/Bunnypranav:<ping> 15:29, 17 January 2025 (UTC)

These are only my opinions on this matter. VancityRothaug (talk + contribs) 17:56, 17 January 2025 (UTC)

now that you mention this my votes don’t make sense. I have now corrected my votes. VancityRothaug (talk + contribs) 17:58, 17 January 2025 (UTC)

have you seen phab task about PII?Alachuckthebuck (talk) 18:04, 17 January 2025 (UTC)

Yes, I have - I’ll be leaving the rights assignments to the System Administrators. VancityRothaug (talk + contribs) 21:43, 17 January 2025 (UTC)

@VancityRothaug Could you also strike the votes using <s> and </s> for clear clarity. ~/Bunnypranav:<ping> 11:38, 18 January 2025 (UTC)

 Done VancityRothaug (talk + contribs) 13:57, 18 January 2025 (UTC)

---

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

NSS Removal Discussion: Bhairava7

Hello everyone. After a conversation with the steward team, I am opening a discussion about the removal of non-steward suppressor rights from Bhairava7 with the rationale that the user doesn't fully understand the purpose of suppression and what should be suppressed vs. public. Additionally, they have leaked their own information (not realizing that it is PII) and created more work for the rest of the suppression team. I would also note that warnings were issued privately to the user. I'll lay out a brief summary of some things that have happened, but it is difficult as the matter contains non-public log information.

First, Bhairava7 leaked their location information on an alt with this edit, which is now hidden from public view. For additional context, the user seemingly randomly said and described the area and city/country in which they live. This is an extremely poor example for a NSS to set, and Drummingman had to suppress the edit.

Second, he blocked his own IP address, which again leaked his personal information, including his location. (You can very easily geolocate IP addresses) When confronted about this, he seemed unaware of the consequences of such action. I had to suppress this one.

Thirdly, Bhairava has suppressed edits that don't require suppression, which is generally a simple mistake that we discuss as a team (I myself am guilty of this). However, combined with our other concerns of incompetence regarding suppression, this is concerning.

In conclusion, I am requesting that the non-steward suppression rights of Bhairava7 are removed for the above reasons. X (talk + contribs) 19:02, 23 January 2025 (UTC)

Vote explanation

 Support - You support removing NSS permissions

 Oppose - You oppose removing NSS permissions

Discussion

 Support, as proposer. -X (talk + contribs) 19:02, 23 January 2025 (UTC)

 Support per X. VancityRothaug (talk + contribs) 21:01, 23 January 2025 (UTC)

 Strong oppose; I have never abused the non-steward suppressor, and I am the person who blocked DisambiguousMonths first when they were trying to abuse their users permissions, and in order to block them, I added suppressor rights to your user accounts because they removed my admin and manager rights along with other members. I admit I made a mistake, which I shouldn't have done as a suppressor, because I didn't know about it, but it doesn't mean that my rights should be removed, but I tried to correct my mistake. I think X has some concerns regarding me. I was appointed as NSS after full community consensus, and if I felt I wasn't worthy of this right, I would have left it myself, and humans make mistakes. I should be given one last chance... Also, it is up to the will of the stewards and test wiki community... but one more thing: please remove my other rights also and block me from here. Happy testing! --- Bhairava7 • (@píng mє-tαlk mє) 03:07, 24 January 2025 (UTC)

Your actions in the situation with DisambiguousMonths didn’t reflect your use of the suppression tools. I have no doubt in your ability to perform regular actions, like blocking and rights changes. You were elected by community consensus, but based on your actions in the role, it is up to the community again to decide your suitability for the position. All of us make mistakes, but your show a lack of understanding of suppression, and an inability to recognize that lack of understanding.

Also, your last sentence is confusing, you want someone to remove all your rights, except NSS, and block you? X (talk + contribs) 03:31, 24 January 2025 (UTC)

What I mean to say is that I was not a suppressor on any other wiki before TestWiki. I meant that all my rights should be removed if I do not get a final opportunity to prove myself as a trustworthy member. One does not gain experience only by staying in his mother's womb, one gains experience by coming into this world.. I feel a little unhappy but I can prove that I've not use this right to prove anything wrong or to prove my own actions. And as far as the block is concerned, you have already raised a finger on my character and actions, so I will block myself of my own will forever.Happy testing!--- Bhairava7 • (@píng mє-tαlk mє) 04:03, 24 January 2025 (UTC)

 Oppose. I had said yesterday, in a private channel on Discord, that I think he should be given a last chance. And said that we should not go to the community portal, but apparently, that is not understood.That has now happened and I deeply regret that. So, I am against revoked his right in that way. He himself with his NSS right hindered that rights vandal until I could stop him. Let me say, that I also see that Bhairava makes mistakes, but I would like to help him learn. I therefore, ask the community to give him chance to learn. Drummingman (talk) 07:30, 24 January 2025 (UTC)