Test Wiki:Community portal

From Test Wiki

Latest comment: 7 August 2023 by Piccadilly in topic Block review of Zippybonzo
The community portal is Test Wiki's village pump and noticeboards, two-in-one.

Archives: 123456789101112


Alternate proposal: Merging CheckUser and oversight to steward

Hello community! I’d like to propose an alternative to the proposal above about merging the rights. Here’s what I’d propose:

  • Stewards are granted the suppression-log, view suppressed, and CheckUser-log rights for accountability;
  • The CheckUser and Suppressor groups remain existent and aren’t removed;

This would allow for accountability amongst stewards and still allow non/stewards to be granted those rights if absolutely necessary. X (talk) 15:46, 26 June 2023 (UTC)Reply

  Support - That seems like a good and better proposal, which is why I withdrew my proposal. Drummingman (talk) 15:20, 27 June 2023 (UTC)Reply
  Support AlPaD (talk) 15:28, 27 June 2023 (UTC)Reply
  Support as proposer. X (talk) 20:58, 27 June 2023 (UTC)Reply
  Oppose viewsuppressed as it poses a confidentiality risk,   Support the rest. Zippybonzo (talk) 07:14, 28 June 2023 (UTC)Reply
Could you elaborate what you mean by “confidentiality risk”? @Drummingman requested I add “view suppressed” to list via Discord, so you may want to discuss with him. X (talk) 11:17, 28 June 2023 (UTC)Reply
The reason I want to include view suppressed is that the logs already show a (partially) suppressed version, but to check each other properly you need view suppressed, and otherwise you have to add suppression yourself. The rest has to do with trusting the stewards to keep suppressed versions secret, which hopefully is already the case. Drummingman (talk) 13:21, 28 June 2023 (UTC)Reply
What's wrong with adding the rights in that case? I don't view that as a significant imposition, and it aids public and community transparency. Dmehus (talk) 16:32, 1 July 2023 (UTC)Reply
I don't think you should be able to just view suppressed revisions without the community knowing. Zippybonzo (talk) 10:43, 2 July 2023 (UTC)Reply
  Support: per proposer. Whether non-stewards should be granted CU or SU is a question I will pose in another proposal if this one succeeds. Justarandomamerican (talk) 13:49, 28 June 2023 (UTC)Reply
  Oppose per Zippybonzo. Dmehus (talk) 16:29, 1 July 2023 (UTC)Reply
So would you support it without view suppressed? X (talk) 16:33, 1 July 2023 (UTC)Reply
Yes. There does seem to be unanimous consensus here to at least checkuser-log being added. Dmehus (talk) 22:16, 2 July 2023 (UTC)Reply
  Neutral - CU and SU practice for bureaucrats are optional, but I don't mind with CU and SU remain existent and not removed and steward having the CU and SU rights. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 23:47, 1 July 2023 (UTC)Reply

Possible close?

Drummingman, AlPaD, X, Zippybonzo, Justarandomamerican, and Tailsultimatefan3891, I'm involved, and though I am fairly certain there would be no objections to me closing in this way, I thought I'd {{ping}} you all here to receive your assent to this being closed as follows, as successful with checkuser-log added to the steward group and all other user groups remaining the same? Dmehus (talk) 21:52, 2 July 2023 (UTC)Reply

I agree. Drummingman (talk) 22:56, 2 July 2023 (UTC)Reply
I agree Zippybonzo (talk) 05:09, 3 July 2023 (UTC)Reply
I agree. AlPaD (talk) 15:39, 3 July 2023 (UTC)Reply
Filed pull request. So Template:Partially done Zippybonzo (talk) 13:33, 18 July 2023 (UTC)Reply

Potential RfS candidate

Hello. I'm considering running for Stewardship sometime in the near future. I would be assisted greatly by the Steward tools, given that my main edits and logged actions consist of preventing abuse. I also think the community needs another Steward due to the fact that we have 3 Stewards, and only 1 is fully active, and a person cannot manage every Steward-reserved matter by themselves. I would add additional coverage to spot and prevent complex disruption, such as by users who lack the skills necessary to edit. My question is, what does the community think? Add feedback here in the Survey section below. Justarandomamerican (talk) 01:30, 4 July 2023 (UTC)Reply

Survey

I would support. You have handled your tools well here and on other wikis, and are trustworthy. Piccadilly (My Contribs | Talk to me) 01:32, 4 July 2023 (UTC)Reply

I would not have any opposition to a potential run at some point in the near- to medium-term future. I would just recommend you articulate a clear need, invite questions from the community, and, perhaps, provide several situation-based examples to which you would articulate how you would handle those situations. As a Steward and an administrator of such elections, I will refrain from an expressing a view and stay neutral, so as to be impartial in any potential close. Dmehus (talk) 01:38, 4 July 2023 (UTC)Reply

“With Drummingman's recent election to Steward, they are quite active here. Combined with my own resumption of being semi-active here, as well as MacFan4000, I feel there isn't a sufficient need for an additional Steward.” How is that different here? “I am not comfortable granting restricted permissions to someone I don't know, at least not without some on-wiki confirmation that they've held restricted tools on a Wikimedia, Miraheze, Fandom, or other major wiki or wiki farm. For Test Wiki is a recent launch, initiated as a protest wiki by one user who took issue with the way Public Test Wiki and/or Test Wiki are run. I do not consider holding restricted permissions on For Test Wiki to be sufficient demonstration that the user can be trusted.” How is that different either @Dmehus? X (talk) 01:45, 4 July 2023 (UTC)Reply
The former: I have articulated a need for Stewards based on activity, as well as an individual need for the tools. The latter: I'm Justarandomamerican on Miraheze and Wikimedia, and collaborated with Dmehus on Miraheze. Note that this comment are my thoughts on the matter, not his. Justarandomamerican (talk) 02:06, 4 July 2023 (UTC)Reply
I know, but @Dmehus has expressed that he doesn’t think we need another steward, so I’m asking for clarification. X (talk) 02:16, 4 July 2023 (UTC)Reply
I said I think it would need to be well-articulated on what the requesting user plans to do. While ideally some sort of global role would be nice to demonstrate the user is trusted, I actually thought Justarandomamerican was a Wikimedia Global Rollbacker, but I think I was thinking of JavaHurricane, with whom I've also collaborated on Miraheze and Public Test Wiki. IMHO, it [rfc:2119 should] be some sort of local or global role on Miraheze, Wikimedia, or Fandom that demonstrates the user is sufficiently trusted. For Wikimedia, it can probably be a local role, whereas on Miraheze, I'd say either a Miraheze Meta Wiki local role, Public Test Wiki Consul, or a Miraheze global role (other than global IP block exemption). For Fandom, it should be a Fandom global community or staff role. Hope that clarifies. :) Dmehus (talk) 02:23, 4 July 2023 (UTC)Reply
I'm not a global rollbacker on WM as I have no need for that right at the moment, but I am an enwiki and simplewiki local rollbacker. I'm relatively trusted to prevent abuse. Justarandomamerican (talk) 02:27, 4 July 2023 (UTC)Reply

I would weak oppose, as you aren't super trusted on wikimedia, and there isn't a need, though I would consider supporting if you held a higher trust role on wikimedia (i.e template editor, massmessage sender, new pages reviewer, edit filter helper, page mover, file mover, autopatrol), or a high trust global role, as I'd rather see some form of trustworthy role, as rollback isn't that highly sanctioned. Zippybonzo (talk) 07:13, 4 July 2023 (UTC)Reply

The supposedly higher trust roles you describe are for a need and competency in entirely different areas: I'm not experienced enough to be a template editor, have no need to be a mass message sender, NPR is a user group assisting in dealing with content, not conduct, etc. Justarandomamerican (talk) 13:15, 4 July 2023 (UTC)Reply
That makes sense. I’d say wait. Given that my RfS just failed with multiple people expressing that they don’t think a 4th steward is needed at all. X (talk) 13:27, 4 July 2023 (UTC)Reply
Well, there appears to be, given the fact that there are only 3 Stewards and only 1 is fully active. I plan on waiting a bit anyways. Justarandomamerican (talk) 13:39, 4 July 2023 (UTC)Reply
Well, there are plenty of roles that aren't for an explicit need, they show you can be trusted, you have 2500 edits on wikimedia, which isn't very many, and I'd rather you had higher trust levels on other wikis. Zippybonzo (talk) 19:00, 5 July 2023 (UTC)Reply
How is making 2500 edits not very many? Only 30% of registered Wikipedia users ever make one. Justarandomamerican (talk) 19:39, 5 July 2023 (UTC)Reply
I've got around 6000 which isn't very many, I'd expect more like 7500. Zippybonzo (talk) 15:49, 8 July 2023 (UTC)Reply
I was inviting you to explain why that isn't enough, as that's more than 99.5% of all registered contributors, and I am seeking the position for an individual need for tools to prevent abuse. Justarandomamerican (talk) 15:56, 8 July 2023 (UTC)Reply
You don’t have a need for the tools, you have full access to the suite of admin tools which is enough to prevent abuse. I’m simply saying, that rollback isn’t that high trust, as they give it out to anyone who has a history of anti vandalism and meets the requirements, and 2500 edits is more than most users, but for a right giving access to look at IP addresses, I’d expect more trust on other wikis when the right isn’t entirely required. Zippybonzo (talk) 12:50, 9 July 2023 (UTC)Reply
I could say that nobody actually requires the tools. Dmehus doesn't actually have a need to look up IPs, but was given the toolkit anyways. Cross-wiki trust barely matters in a small community, or even a large one. Nobody judges a scowiki admin candidate on the basis that they only have rollback on enwiki. Nobody judges an enwiki admin for only having rollback and patroller on metamiraheze. Why is this required when I have a track record right here of making perfectly fine decisions? Simply put: if a candidate has a track record of making good decisions on the wiki they are requesting permissions, they are trusted, even if they have a bit lower trust elsewhere. Rollback on enwiki? Sure, it's a bit lower trust, but it does add to a case of a totality of the circumstances trustworthiness, which I say exists based on my track record here and elsewhere. Justarandomamerican (talk) 00:41, 10 July 2023 (UTC)Reply
IMO a few of your decisions are far from good, which is why I’d want a right on another wiki that needs you to make good decisions. You still have no need for the right though, as there is 1 active steward, 1 semi-active steward, and a rarely active steward. Zippybonzo (talk) 02:34, 10 July 2023 (UTC)Reply
Please point me to a diff of a poor decision I made so that I can improve. A semi-active steward and one rarely active steward? That's why I'm requesting, there needs to be at least a duo of active stewards to handle any requests, as 1 person who is active isn't enough in any circumstance involving CU evidence, LTAs, and other forms of abuse that cannot be combated with the admin toolkit alone. People need other people to ask for review actively, not just a pair of semi-active stewards.Justarandomamerican (talk) 03:39, 10 July 2023 (UTC)Reply
No, I also said an active steward as well, they are enough, the decision that was not great IMO was on FTW when you and X decided to take away IP privacy from abusive users, I’m not going to use it against you as I heavily doubt that you came up with the idea of it, but, there are a few conditions under which I’d support stewardship.
If any of the following conditions are met.
  1. The wiki grows to the point where MacFan, Dmehus and Drummingman can’t prevent abuse.
  2. You are more highly trusted on other wikis (not test ones or ones that just give out high trust permissions).
  3. You show that you can perform actions similar to steward actions without significant opposition.
However IMO, 1 is so close to being met, that I’d probably support. Though I do consider this discussion to be pre discussion canvassing, you are a pretty highly qualified candidate, who inevitably I would have to support. Zippybonzo (talk) 06:37, 10 July 2023 (UTC)Reply
Relating to the privacy policy change, if you had a problem with the change, you should’ve said so in the waiting time before the policy took effect. I don’t consider this to be canvassing, given that they weren’t asking for support and it’s all public. I was looking on Wikipedia and it appears to be similar to wikipedia:Wikipedia:Requests for adminship/Optional RfA candidate poll. X (talk) 10:56, 10 July 2023 (UTC)Reply
I did air the concern but it was ignored. Zippybonzo (talk) 11:48, 10 July 2023 (UTC)Reply
I believe your concern was addressed by compromise: We replaced IP addresses with ranges, which are vague as to specific location, and cannot be used to identify 1 person in particular. I understand the concern about privacy, but some form of amendment was required to prevent disruption, and immediately after your feedback I realized that blocking IP addresses may not be the best way to go about preventing disruption from sockpuppetry, so now the PP allows for range blocks of CU-found IPs, not specific ones like was originally planned by X. I used rather vague wording whilst discussing the topic of preventing disruption from sockpuppetry, resulting in a privacy concern. My apologies. I certainly didn't mean for specific IPs to be blocked. Justarandomamerican (talk) 14:42, 10 July 2023 (UTC)Reply

Amend Test Wiki:No open proxies to include colocation providers

Colocation providers also hide IPs, like proxies and webhosts, so they should logically be included. Change: "No open proxies, web hosts, or VPNs..." to "No open proxies, web hosts, VPNs, or colocation providers..." Justarandomamerican (talk) 18:45, 5 July 2023 (UTC)Reply

  Done as this is pretty uncontroversial and doesn’t warrant further discussion. X (talk) 16:21, 8 July 2023 (UTC)Reply

Addition of interface admin protection level

I am proposing that interface administrator protection is added to help protect sensitive interface pages, i.e the sidebar and sitenotice pages, and also for protecting highly used templates. Zippybonzo (talk) 06:47, 10 July 2023 (UTC)Reply

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

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)Reply
  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)Reply
  Oppose changing the block as per X's comment. Sav • ( Edits | Talk ) 12:46, 11 July 2023 (UTC)Reply
  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)Reply
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)Reply

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

@Piccadilly May I ask why you tested on talk pages again after many warnings? X (talk) 13:02, 12 July 2023 (UTC)Reply
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)Reply

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

  Neutral. X (talk) 12:40, 14 July 2023 (UTC)Reply
  Support as the least restrictive method of preventing disruption at the moment. Justarandomamerican (talk) 12:43, 14 July 2023 (UTC)Reply
  Support Piccadilly (My Contribs | Talk to me) 12:52, 14 July 2023 (UTC)Reply
  Neutral. Sav • ( Edits | Talk ) 15:31, 14 July 2023 (UTC)Reply
  Support AlPaD (talk) 08:16, 15 July 2023 (UTC)Reply
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)Reply
Implementing... could take a while as I haven't used filters like this in a while. Zippybonzo (talk) 04:04, 18 July 2023 (UTC)Reply
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)Reply
  Done Zippybonzo (talk) 04:25, 18 July 2023 (UTC)Reply

Proposal: Non steward CheckUser & Oversight/Suppressors

Hello, I am proposing non-steward check user and oversight/suppressors, whilst there isn't an active need for extra check users or suppressors as of now, in my opinion, if there are enough people able to perform the role, then they should be in the role as it's always better to have more people when you don't need them but to have none when you need them. Because the two roles are quite high trust, I am proposing the following requirements for each role.

Checkuser:

  1. Basic understanding of IP addresses and ranges and CIDR syntax.
  2. Pass a vote on the community portal with either 80% support, or 70-80% at a steward's discretion.
  3. Have a good understanding of account security.
  4. Performing unnecessary or abusive checks will result in having your access revoked.

Suppressor:

  1. Basic understanding of suppression criteria.
  2. Pass a vote on the community portal with either 80% support, or 70-80% at a steward's discretion.
  3. Have a good understanding of account security.

I believe that this is also a way for users to gain additional trust.

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. These groups may not be added immediately,


non-steward-suppressorNon-steward suppressor

With the following rights:

unblockable

Add groups to own account: Suppressor

Remove groups from own account: Suppressor


non-steward-checkuser Non-steward CheckUser

With the following rights:

unblockable

checkuser-log

Add groups to own account: Check user

Remove groups from own account: Check user

Thank you, Zippybonzo (talk) 13:00, 18 July 2023 (UTC)Reply

Please remove X'interface admin rights

Request for System Administrator: Zippybonzo

Block review of Zippybonzo

I'm not one to usually interfere with the runnings of other wiki's, however, it's come to my attention that Zippybonzo was blocked here for some schenanigans that went on last week on another wiki. I don't see a policy in place where harmless pranks can result in a block here, and I'd like to call the community's attention to the block and ask that it be lifted.

While it really shouldn't have happened, generally speaking I don't see off wiki conduct (like a prank) needing something as significant as an indefinite block labelled as a Steward action.

The user on the other end of the prank actually threatened Zippybonzo with violence, which resulted in an indefinite block on my TestWiki along with a lock of their global account. That conduct I can certainly see resulting in an indefinite block. Dusti (talk) 14:47, 7 August 2023 (UTC)Reply

I tend to agree with this assessment. Unless the off-wiki matter involves serious issues such as severe harassment or threats of violence, like noted above, I don't see how people's actions on one wiki should affect their standings on other wikis. Piccadilly (My Contribs | Talk to me) 14:51, 7 August 2023 (UTC)Reply
I oppose. The reason for said block is clearly stated and so, his block should remain active. Sav • ( Edits | Talk ) 15:57, 7 August 2023 (UTC)Reply
A prank requires the other party to laugh. Severely disrupting a wiki and then claiming it was a prank after the owner of said wiki repeatedly attempted to stop said disruption doesn't work. It's like playing a prank on the Wikipedia community as an admin by deleting an article on a president of the United States and then blocking Jimbo. This was intentionally inflicting emotional harm on (trolling) another member of this wiki, Cocopuff2018, and therefore I have no problem with the block. Justarandomamerican (talk) 16:26, 7 August 2023 (UTC)Reply
I simply don’t believe my actions on one wiki should be carried over to an entirely unrelated wiki. The actions were unwise, but I did not violate the policies of that wiki. Zippybonzo (talk) 16:57, 7 August 2023 (UTC) copied to the community portal by X (talk). Reply
This response is.. not good. A wiki or other community does not have to codify: "Disrupting us is prohibited." That is assumed to be the case. Justarandomamerican (talk) 17:05, 7 August 2023 (UTC)Reply
Whilst that is true, there is no reason the block from an entirely unrelated wiki should be carried over to this wiki. Zippybonzo (talk) 17:20, 7 August 2023 (UTC) - moved to the community portal by X (talk).Reply
There is a valid reason for extending the block to this Wiki. Even though this is a Test Wiki, we must uphold responsibility and avoid any form of abuse, a concept that seems to have been misunderstood in your case. Sav • ( Edits | Talk ) 17:31, 7 August 2023 (UTC)Reply
It's not being carried over. You intentionally inflicted emotional distress upon a fellow member of this wiki, which earned you a block on this wiki to prevent further problems and deter your disruptive behavior. Justarandomamerican (talk) 17:33, 7 August 2023 (UTC) (edit conflict)Reply
I tend to agree with Zippybonzo on this point. I think each wiki should be a "fresh start" so to speak, where as long as a user doesn't cause any serious disruption on this wiki, they shouldn't be blocked based on off-wiki matters. If we're going by the principle that Justarandomamerican suggests, then to be honest I would probably be blocked here as well because of issues from thetestwiki.org and Wikimedia. So why is it that off-wiki matters don't count against me but they do for Zippybonzo? Piccadilly (My Contribs | Talk to me) 17:34, 7 August 2023 (UTC)Reply