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 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)

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

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)

‪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)

Crat Abuse RFC

What should we do about the recent abuse of crat rights? Option 1: Do nothing. Option 2: Add the ability to remove crat rights to non-steward suppressors. Option 3: Create a Trusted user group, as described here. Justarandomamerican (talk) 17:56, 15 January 2025 (UTC)

 Support Doing nothing,  Weak support option 2,  Strong oppose Option 3. X (talk + contribs) 18:05, 15 January 2025 (UTC)

But what if the vandal goes at the peak of their rogue and no one takes action? Number 1 is a possible issue. Codename Noreste (talk) 18:35, 15 January 2025 (UTC)

 Strong support option 2 --- Bhairava7 • (@píng mє-tαlk mє) 18:21, 15 January 2025 (UTC)

 Strongest support Option 1,  Oppose 2 and 3. Given that this is the first such incident, I don't think we need to do anything right now. If this starts happening more often in the future, then maybe. MacFan4000 ^{(Talk Contribs)} 20:25, 15 January 2025 (UTC)

 Support per MacFan4000. VancityRothaug (talk + contribs) 22:03, 15 January 2025 (UTC)

 Oppose for option one, but  Strong support on options 2 and 3. It's better to be safe than sorry. Codename Noreste (talk) 15:20, 16 January 2025 (UTC)

1 ~ 3 ~ 2 : Doing nothing in this case is the best option as it was the first incident and I don't think that there would be more such incidents in future. The AP (talk) 02:38, 17 January 2025 (UTC)