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
Restrict abusefilter-access-protected-vars and abusefilter-protected-vars-log to AFAs and stewards?
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,
--raidarr (💬) 17:23, 15 January 2025 (UTC)
Restrict removing bureaucrat rights to Stewards
Crat Abuse RFC
SecurePoll on Test Wiki
NSS Removal Discussion: Bhairava7
Please update markadmins.js as shown here, thanks. Bosco (talk) 07:50, 24 January 2025 (UTC)
- Done. --- Bhairava7 • (@píng mє-tαlk mє) 08:09, 24 January 2025 (UTC)
Test page policy
I propose this to you all, the test page policy. I know it's not a lot, but I believe that users should at least do it in an organized manner when it comes to testing. This policy is saying everything I should be telling you all here, but I'm giving it a chance to be read by you all to see if it is worthy of being a policy. Faithful (talk) 23:55, 2 February 2025 (UTC)
- Weak oppose, seems very unnecessary. We almost never have new test pages added, and if someone disagreed with one being added, they could simply just propose it be removed on the CP. X (talk + contribs) 23:56, 2 February 2025 (UTC)
- I see your point on the process of adding new test pages. This makes the process pointless from your POV because there could be someone who opposes it and has that page removed via the community portal. However, now I'm starting to believe that mainspace page creation should be restricted to a specific group level, so that users will not fill it with spam or vandalism, except on the abuse filter test. But primarily, because of the test pages. For now, since your point makes sense for the activity period of Test Wiki right now, which is that test pages rarely come up, I'll put it to the side. However, I do believe that users should properly do their test experiments on the right testing page. Hence, if you want to test deletion, go to Deletion test; if you want to test protection, go to Protection test, and so forth. That should be a policy. Faithful (talk) 01:10, 3 February 2025 (UTC)