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 |
Addition of interface admin protection level
Block review of Piccadilly
I'd like to determine whether consensus believes that Piccadilly creating a blank talk page for a test page is worthy of a 3 month block from talk namespaces. In my opinion a block from talk namespaces is unneeded but instead a final warning, and a filter to warn upon creation of talk pages with a size under 256 bytes (a signature and a few words). For the record, this wiki is a test wiki, not the English Wikipedia, meaning people can test, and they aren't random talk pages, they are talk pages of test pages. Zippybonzo (talk) 11:16, 11 July 2023 (UTC)
- Or possibly limit the creation to exclude certain words (I.e hello, hi, guys), also, blocking at the request of a steward is mad, as the stewards can block for themselves, they are sysops too and I'd like to see their name in the block log if they authorised the block, as you don't see MacFan telling someone else to update the wiki. Zippybonzo (talk) 11:21, 11 July 2023 (UTC)
- Oppose changing the block. We’ve given Piccadilly so many changes and so many warnings. Why must we give another? I think the partial block is a good alternative to a indef full block. And there’s nothing wrong with blocking on the request of a steward because maybe they can’t get to a laptop or they’re very busy. I’ve done it before and there’s nothing wrong with it. X (talk) 12:33, 11 July 2023 (UTC)
- Oppose changing the block as per X's comment. Sav • ( Edits | Talk ) 12:46, 11 July 2023 (UTC)
- Comment: -- The blockage was not entirely at my request, only the change from 1 year to three months was made by Justarandomamerican at my request. Drummingman (talk) 14:07, 11 July 2023 (UTC)
- Totally reasonable that they can somehow tell you to do it but not access their computer, I don’t think that’s a very good reason. Zippybonzo (talk) 02:12, 12 July 2023 (UTC)
- Oppose changing the block as per X's comment. Sav • ( Edits | Talk ) 12:46, 11 July 2023 (UTC)
- Oppose changing the block. We’ve given Piccadilly so many changes and so many warnings. Why must we give another? I think the partial block is a good alternative to a indef full block. And there’s nothing wrong with blocking on the request of a steward because maybe they can’t get to a laptop or they’re very busy. I’ve done it before and there’s nothing wrong with it. X (talk) 12:33, 11 July 2023 (UTC)
I'm neutral on the block, to be honest. I'm just glad it isn't an indefinite sitewide block. Piccadilly (My Contribs | Talk to me) 12:51, 12 July 2023 (UTC)
- @Piccadilly May I ask why you tested on talk pages again after many warnings? X (talk) 13:02, 12 July 2023 (UTC)
- I'm not really sure to be honest. I can say that I wasn't thinking about possible consequences of my actions, which I know isn't an excuse. I think I need to make more of an effort to slow down and think about doing things rather than just rush into them like I tend to do. Piccadilly (My Contribs | Talk to me) 13:54, 12 July 2023 (UTC)
Alternate proposal: Prevent creation of talk pages but allow editing
I have an alternative proposal, to use an edit filter to prevent creation of talk pages for the remainder of the block, but allow editing. Any tampering with the filter will result in a desysop and 6 month block from all namespaces. Zippybonzo (talk) 12:29, 14 July 2023 (UTC)
- Neutral. X (talk) 12:40, 14 July 2023 (UTC)
- Support as the least restrictive method of preventing disruption at the moment. Justarandomamerican (talk) 12:43, 14 July 2023 (UTC)
- Support Piccadilly (My Contribs | Talk to me) 12:52, 14 July 2023 (UTC)
- Neutral. Sav • ( Edits | Talk ) 15:31, 14 July 2023 (UTC)
- Support AlPaD (talk) 08:16, 15 July 2023 (UTC)
- I believe this can be implemented now, and anyone may remove the block as soon as it is implemented. If they edit existing talk pages to test editing functions, the block may be reinstated by any Bureaucrat. Justarandomamerican (talk) 16:19, 17 July 2023 (UTC)
- Implementing... could take a while as I haven't used filters like this in a while. Zippybonzo (talk) 04:04, 18 July 2023 (UTC)
- Should be done, give me a bit of time to test it and I'll be back with a full result. Zippybonzo (talk) 04:10, 18 July 2023 (UTC)
- Implementing... could take a while as I haven't used filters like this in a while. Zippybonzo (talk) 04:04, 18 July 2023 (UTC)
Proposal: Non steward CheckUser & Oversight/Suppressors
Please remove X's interface admin rights
Request for System Administrator: Zippybonzo
Block review of Zippybonzo
Request for Stewardship: Justarandomamerican
Proposal to merge editor and reviewer
1 year spam blocks- Automatic, or status quo?
Proposal: Remove the ability for IP editing
Category:Advanced users
Hello, I've observed that @Username: recently created this page and combined other sysop groups into it without prior discussion on the Community Portal. Both @Justarandomamerican: and I have since reverted these edits. Consequently, I'd like to open a discussion regarding the fate of this page—whether it should be retained or deleted. Warm regards, Sav • ( Edits | Talk ) 13:57, 5 October 2023 (UTC)
- I don't really see a problem with it. Doesn't seem to be a problematic category, but this function is already done by Category:Administrators and Category:Bureaucrats, and similar, so it's somewhat redundant. EggRoll97 (talk) 19:12, 5 October 2023 (UTC)
- I'd say it should be retained, and all the permissions categories should be put into it, to create a category tree. Although I can comprehend what Username was thinking, in that there should be 1 category, the better way to do that is to categorize all the advanced user categories into the advanced users category. Justarandomamerican (talk) 21:44, 5 October 2023 (UTC)
- I concur, so keep it as it currently is? Sav • ( Edits | Talk ) 07:01, 7 October 2023 (UTC)
Apologies
I deeply regret the oversight that resulted in some of you having your rights removed unfairly. In my sleep-deprived state, I misread "3 months" as "1 month." I want to offer my sincere apologies for any inconvenience this may have caused.
I have taken immediate action to rectify this mistake. All actions against you have been reverted, and your rights have been reinstated. While I won't mention names, I trust that those affected will know who they are.
Once again, I apologize for any frustration or confusion this may have caused. Thank you for your understanding.
Warm regards, Sav • ( Edits | Talk ) 03:26, 14 October 2023 (UTC).
Non-steward oversighters/checkusers - alternate proposal
I propose allowing non-stewards to access checkuser/oversight tools, similar to the above proposal, but without the unblockable right. Being that the implementation of this could result in a lack of transparency with the community, I think that 2 additional groups should be added.
non-steward-suppressor:
With the following rights: suppression-log
Add groups to own account: Suppressor
Remove groups from own account: Suppressor
non-steward-checkuser:
With the following rights:
checkuser-log
Add groups to own account: Check user
Remove groups from own account: Check user
These users can be appointed by either: 1) Community consensus, closed by a steward 2) Steward consensus, at least 2 stewards support giving the right
A user may not hold both suppressor and checkuser rights, unless they apply for steward. X (talk) 17:13, 16 October 2023 (UTC)
- Support: No inherent problems with this, although NSSs should have
suppressionlog
as Stewards do without the suppressor flag. Justarandomamerican (talk) 00:47, 17 October 2023 (UTC)- Amended X (talk) 01:15, 17 October 2023 (UTC)
- Partially supporting. With suppression, I have no problem granting it to non-stewards as well. I therefore support that part. Granting a checkusser to non-stewards is not a good idea in my opinion. That right is so sensitive with privacy that I prefer to keep that with the stewards and since we have 4 stewards of which 2 are active and 1 semi-active, I see no reason to grant it to non-stewards as well. And otherwise, steward elections can always be held. Drummingman (talk) 08:50, 23 October 2023 (UTC)
- I don't think there's a serious actual privacy issue, although I can see your point that someone with non steward checkuser access would be practically on the same level of trust as Stewards. Justarandomamerican (talk) 02:22, 26 October 2023 (UTC)
- Partially supporting. With suppression, I have no problem granting it to non-stewards as well. I therefore support that part. Granting a checkusser to non-stewards is not a good idea in my opinion. That right is so sensitive with privacy that I prefer to keep that with the stewards and since we have 4 stewards of which 2 are active and 1 semi-active, I see no reason to grant it to non-stewards as well. And otherwise, steward elections can always be held. Drummingman (talk) 08:50, 23 October 2023 (UTC)
- Amended X (talk) 01:15, 17 October 2023 (UTC)
Formalize Test Wiki:Blocks and bans as a guideline
This practically just formalizes practice and existing consensus. However, compliance with it should not be mandatory as with policies, but rather strongly recommended. This contains some things that simply aren't worthy of policy (see the blocks section), but it should be some form of community recommendation. Justarandomamerican (talk) 17:28, 21 October 2023 (UTC)
- Due to non-participation, I'll withdraw this within 4 days. Justarandomamerican (talk) 20:37, 11 November 2023 (UTC)
- Withdrawn. Justarandomamerican (talk) 23:31, 16 November 2023 (UTC)
Block appeal
Piccadilly sent this into the staff email address today: "The issues I have had on the wiki have been making random talk pages, using bad language in some of my edits, spamming random letters, and evading my block through IP addresses. I am not sure of all the reasons I thought any of that would be okay, but I do remember thinking at times "this won't hurt anything" or "I'll undo this right afterwards so nobody will even notice". I definitely should have been thinking more maturely or at least sensibly when doing any testing on the wiki. If I am allowed back, I will be extremely careful in all my tests on the wiki. I also promise to adhere to any conditions that might be set for my unblock, including when I can ask for administrator and/or bureaucrat." Are there any community objections or comments about her return? Justarandomamerican (talk) 23:31, 16 November 2023 (UTC)
Proposal: Ban Piccadilly indefinitely
I would like to propose a site ban of Piccadilly for an indefinite period of time, as the person who posted the block appeal and found CheckUser evidence. Piccadilly, you should take a break from wikis and prove you can stop socking. The fact that you used IPs to evade your block is utterly unacceptable, as you know the consequences of block evasion and sockpuppetry. You also seem to lack the ability to stop yourself, which is required if you want to be here, and you lacking it has caused severe disruption. Justarandomamerican (talk) 16:56, 17 November 2023 (UTC)
- Support as such behavior is really unacceptable. 64andtim (talk) 08:43, 24 November 2023 (UTC)
- I don't know the circumstances that gave rise to their original block, or whether the block was imposed by a mainly testing permissions bureaucrat or Steward. If, and only if, the original indefinite block was either (a) made by a Steward directly or (b) reviewed thoroughly and endorsed by a Steward, then I support an indefinite block (you can call it a ban, if you want, but I don't personally like the word ban as that implies permanence here and we also don't have a "site ban" policy (nor do I think we need one), provided it's a steward-imposed indefinite block/ban that carries the community's endorsement but would oppose any sort of "community ban" as, fundamentally, I tend to oppose community bans for the following several reasons, notably:
- Philosophically speaking, we elect amongst ourselves Stewards, whom we entrust to make these decisions. Each Steward has different criteria for effecting certain user control measures in terms of restriction, severity, and duration. Users are always provided an opportunity to appeal, then an uninvolved Steward should review the circumstances and decide whether the sanction is appropriate, restorative and protective but, crucially, not punitive. If we're to then second guess ourselves and defer to the community on every major user control decision, what is the purpose of Stewards after all?
- This is more of a Test Wiki-specific reason, but Test Wiki's community, aside from several core users is transitory in nature. Users come and go frequently and often have to "follow the herd mentality" of a few in community discussions, which is not a substantive community consensus
- I suspect the behaviour is more of Piccadilly's reversion to the mean of not being to help themselves. They're good-faith, have made positive steps in terms of reforming themselves and even been a constructive contributor for several months, but then they revert to non-constructive gibberish outside of their own userspace and clearly marked test pages. The sockpuppetry is more of a symptom of their self-disclosed ADHD + autism, in being frustrated by stewards not responding to their appeal. That's not to excuse it, but I do think it provides a mitigating circumstance
- In summary, subject to the conditions I described above, I think they need a clear break, so no objections from me in imposing a steward-imposed indefinite block/ban on Test Wiki, provided it's made clear that (a) the appeal venue is to
staff[at]testwiki.wiki
and to Stewards and (b) that an appeal will only be considered after a reasonable break (of say, a minimum of 1 and maximum of 6 months) from date of last confirmed sock. If the above is true, Justarandomamerican, please feel free to self-close this and impose the block/ban as such and make clear your appeal conditions. Dmehus (talk) 02:30, 26 November 2023 (UTC)