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)
- 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)
- 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)
- I agree with those options. Codename Noreste (talk) 09:00, 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)
- @TenWhile6: Hi there, What is the exact answer of this abuse.😅--- Bhairava7 • (@píng mє-tαlk mє) 08:52, 15 January 2025 (UTC)
- I don't think thats the right answer to this abuse. TenWhile6 08:49, 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)
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,
Restrict removing bureaucrat rights to Stewards
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- The proposal is Withdrawn by the requester. --- Bhairava7 • (@píng mє-tαlk mє) 16:11, 15 January 2025 (UTC)
Due to recent abuse, I propose restricting removing bureaucrat rights to Stewards, with Bureaucrats still able to resign through removing the right from themselves. This ensures that Bureaucrats cannot be removed by rogue Bureaucrats. If this proposal passes, please notify a Steward for any bureaucrat inactivity. Justarandomamerican (talk) 15:52, 15 January 2025 (UTC)
- Support VancityRothaug (talk + contribs) 15:55, 15 January 2025 (UTC)
Withdraw per recent discussion on discord. VancityRothaug (talk + contribs) 16:00, 15 January 2025 (UTC)
- Raidarr has pointed out disadvantages with this proposal on Discord, mainly that Bureaucrats cannot remove rogue Bureaucrats if this goes into effect. Justarandomamerican (talk) 15:59, 15 January 2025 (UTC)
- Proposal withdrawn. Justarandomamerican (talk) 16:01, 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.
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 oppose 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)- Strong 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)
- Oppose option 1; Strong support Option 2. Self removal of crat should exist, and removal of others crat should only be done by stewards. Support for option 3, that can also work. Prevention is better than cure, something should be done. ~/Bunnypranav:<ping> 10:36, 17 January 2025 (UTC)
SecurePoll on Test Wiki
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)
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)
- 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)
- The “for everyone” part implies that everyone would be granted access to this extension though. VancityRothaug (talk + contribs) 18:59, 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)
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)
- Strongest support MacFan4000 (Talk Contribs) 21:33, 17 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)
- 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)
