Test Wiki:Community portal

From Test Wiki
Jump to navigation Jump to search
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


"Grace Period"

Latest comment: 1 July 202333 comments8 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Greetings,

I hope this message finds you well. I wanted to draw your attention to an ongoing discussion on the User talk:Euphoria page regarding the Inactivity Policy. The conversation involves myself, @X:, @Justarandomamerican:, and @AlPaD:.

It appears that both "X" and "Justarandomamerican" hold the view that a "grace period" exists within the Test Wiki's process for removing permissions. However, it is important to note that no such provision is mentioned in the policy itself.

I have noticed numerous instances where "X" has repeatedly removed rights without following the established procedure, prompting my intervention to revert those actions.

I kindly request the community to provide their opinions on this matter, as I firmly believe that our actions should align with the guidelines outlined in the policy, rather than making assumptions based on its omissions.

Thank you for your attention and cooperation.

Best regards, Sav • ( Edits | Talk ) 18:25, 27 May 2023 (UTC)Reply

Obviously, I  Support the ability for bureaucrats to use grace periods to remove rights for a number of reasons.
  1. It notifies the user of their inactivity through email and allows them to regain their rights sooner, almost like a reminder if they forgot about the wiki.
  2. It allows inactive users to quickly regain their rights if they come back. Bureaucrat can just assign them back permanently and admins can just request it be made indefinite.
  3. If they don’t return to activity, it is a convenient way to remove rights, and the outcome is the same. The rights are removed on the same day.

X (talk) 18:37, 27 May 2023 (UTC)Reply

Whilst I  Support grace periods as a common sense measure, I do not understand what causes the absolute letter of policy, rather than the spirit, to be followed. The inactivity policy provides for removal of rights from inactive users. That is it. It does not explicitly disallow grace periods. Disallowing administration in the absence of policy by wheel warring is, more or less, making this wiki appear to be a bureaucracy when it is not. Justarandomamerican (talk) 18:48, 27 May 2023 (UTC)Reply
You both need to follow the policy, same as anyone else. Nobody has has decided that a "grace period" is necessary, so why should you? Even so, before making decisions like that, a vote should be made here, on the community portal. I'll be expecting a response from @Dmehus: to confirm my reports. Sav • ( Edits | Talk ) 18:49, 27 May 2023 (UTC)Reply
Please explain to me how we are violating policy. You have said that we are, so explain it. What policy am I violating by setting grace periods? The policy states that a users rights will be removed after 3 months of no edits/logged actions, and that is what I am doing. X (talk) 19:04, 27 May 2023 (UTC)Reply
@Justarandomamerican:, Expanding on your assertion regarding the absence of an explicit prohibition of grace periods, it is worth noting that there is also no explicit endorsement. Consequently, one must question the justification for unilaterally modifying the policy at will. Sav • ( Edits | Talk ) 18:52, 27 May 2023 (UTC)Reply
Does policy state that I can login? Does policy state that I can edit? Does policy state that I can breathe? No, but that doesn’t mean you can’t do it. X (talk) 19:04, 27 May 2023 (UTC)Reply
Again, this wiki is not a bureaucracy where rules providing for something must be made, and rules providing for something disallow all other handling of a situation, so administration in the absence of policy is allowed. We are not modifying rules, merely maintaining this wiki in the absence of them. The spirit of the Inactivity Policy does not disallow grace periods, in consequence. Justarandomamerican (talk) 18:57, 27 May 2023 (UTC)Reply
Again, you are modifying the rules by doing whatever you see fit. Clearly, we are at a crossroads and so, I'll leave this to Dmehus and/or @Drummingman: to decide. 18:59, 27 May 2023 (UTC) – Preceding unsigned comment added by Sav (talk • contribs)Reply
What rules are being modified? Policy states to remove rights after 3 months of not actions or edits. We have not altered this in anyway. X (talk) 19:04, 27 May 2023 (UTC)Reply

As I said above, I am not in favor of an "already lengthwise truncated user rights" where admin/crat rights are already truncated. I find that impolite and not inviting to test here. But giving a warning on the users' own talk page about 2 weeks in advance, "beware you are approaching the activity criteria", is sufficient as far as I am concerned. But what I find worse is wheel warfare with each other. I urge the users involved not to overrule each other and look for consensus. If you still can't come to a consensus, ask the stewards to get involved, and then do nothing until the steward has made a decision. Keep your head cool and let's keep it nice with each other. Greetings, Drummingman (talk) 19:16, 27 May 2023 (UTC)Reply

Hi, @Drummingman:. To put simply, that means no grace period, correct? We are okay to issue a friendly warning stating "You are approaching the activity criteria" yes? Regards. Sav • ( Edits | Talk ) 19:37, 27 May 2023 (UTC)Reply
As far as I am aware, this is a community discussion, and a Steward's decision is not final, as this wiki's decision making mechanism is not autocracy. We should continue to discuss this matter. I disagree as to it being unfriendly: How is it unfriendly when they are immediately notified by email and have a chance to request the rights be made permanent? Justarandomamerican (talk) 19:44, 27 May 2023 (UTC)Reply
I agree. Stewards don’t hold seniority in discussions. This is a community discussion. I also agree with Justa that it isn’t unfriendly. X (talk) 19:46, 27 May 2023 (UTC)Reply
Regardless if you don't like the decision, Drummingman has given the answer and until Mac or Dmehus gives their input, we should follow what Drummingman stated. Sav • ( Edits | Talk ) 19:48, 27 May 2023 (UTC)Reply
Elected Stewards have no say in community discussion besides what all other members of the community have, and their decisions are merely temporary dispute resolution. We shall continue to discuss this. Justarandomamerican (talk) 19:51, 27 May 2023 (UTC)Reply
What I would like to add here is that this is my own opinion, not a direct "steward decision" but a user who is also a steward. I have not talked to the other stewards about this yet. Moreover, I also think it is important to hear your opinions on this. So, this is not a final decision yet. Drummingman (talk) 19:54, 27 May 2023 (UTC)Reply
Thank you for correcting my assumption that you were acting under the color of your authority to resolve disputes. That was a wrong assumption. Thank you again, Justarandomamerican (talk) 19:57, 27 May 2023 (UTC)Reply
You're welcome. @X:. I really hope you stay active. Your work has been good so far. Don't let this discourage you. Drummingman (talk) 20:14, 27 May 2023 (UTC)Reply
I won’t. I just really hate conflict. I think that grace periods should just be optional. You can do them if you want, but you don’t have to use them either. This is a good compromise. X (talk) 20:24, 27 May 2023 (UTC)Reply
@X: That sounds good. I don't like conflict, either :-). What is most important to me is to respect each other's authority and not start a wheel war over this. I look forward to your opinions, feel free to add anything? Drummingman (talk) 20:54, 27 May 2023 (UTC)Reply
I agree. This isn’t really that important, and to wheel war about it was admittedly futile. I don’t think I have much more to add besides grace periods are an optional part of bureaucrat revoking rights. You can close this, if you wish. X (talk) 21:02, 27 May 2023 (UTC)Reply
  •  Oppose I believe that inactive users should be notified 1-2 weeks before their rights are removed but their rights should not be temporary, they should be removed completely after 3 months. AlPaD (talk) 06:49, 28 May 2023 (UTC)Reply
  •  Comment: I support Drummingman‘s opinion. Anyone can(≠must) give inactive user warning like ‘Your rights will be removed in 2 weeks unless’…, and it’s more kind.
  • Regarding ‘Grace period’, I’m not inclined to support this. because
    • If you set an inactive user's rights to expire and then they or requested crats revert them, they'll end up with two user rights logs. I don't like unnecessarily increasing logs and complicating records, except in cases where it can't be helped, such as adding a test group or adding a Bot flag instead of a Flood flag. As per Drummingman's opinion, if you give advance notice and the user edits in the meantime, there is no need to remove the rights, so there is no need for logs.
    • If it is chosen to set the expiration date of the rights instead of the permission removal notice on the talk page, the user must extend the rights himself or ask bureaucrats to do so. Whether or not it is a big deal depends on the person, but the only thing that is required in order not to be removed by Inactive Policy is 'edits or logged actions'. If you use the method of setting a expiry on the rights, for example, a user who only edits one week after the expiry is set will have the rights removed one week later. Is this in line with the spirit of the 'Inactive Policy'? (It is a different story if the user who set the expiry is responsible for confirming that it will not happen.)--Q8j (talk) 09:43, 28 May 2023 (UTC)Reply
  • I am honestly fine with having a grace period - it seems perfectly reasonable. That being said I do see that there is "edit warring" (with user rights) related to this. This needs to stop. Things should have been discussed further here instead of continuing to edit war. MacFan4000 (Talk Contribs) 14:06, 28 May 2023 (UTC)Reply
    I am inclined to agree with you: Further wheel warring should be sanctioned. Justarandomamerican (talk) 14:37, 28 May 2023 (UTC)Reply
    I am happy to compromise and agree that an inactive user warning could be issued, but not a "grace period" as Justarandomamerican suggested; it just complicates the matter as Q8j stated. Sav • ( Edits | Talk ) 03:59, 29 May 2023 (UTC)Reply
    Expanding upon my previous statement, I would support the inclusion of a grace period. However, I suggest implementing a courtesy warning prior to initiating the grace period. This would allow users to be notified in advance. If no edits are made within 48 hours following the warning, the grace period may be implemented. Sav • ( Edits | Talk ) 05:59, 29 May 2023 (UTC)Reply
    I would be fine with that, but I think 24hrs would be more appropriate. X (talk) 10:38, 29 May 2023 (UTC)Reply
    24hrs is fine with me. Sav • ( Edits | Talk ) 21:00, 29 May 2023 (UTC)Reply
    I also agree with you. AlPaD (talk) 05:00, 5 June 2023 (UTC)Reply
    I also now agree to allow a non-mandatory grace period. And also to wait at least 24 hours before it takes effect. Drummingman (talk) 11:05, 17 June 2023 (UTC)Reply
    I suggest that bureaucrats wait a 24-hour grace period before removing permissions, with exceptional cases. This discussion is to be closed as soon as possible. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 23:40, 1 July 2023 (UTC)Reply
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

CU Request

Latest comment: 1 July 20236 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Hello, may a steward, perhaps Drummingman, check and see if my recent range block on 38.153.169.128/25 would affect legitimate users? Thank you! Justarandomamerican (talk) 23:33, 27 May 2023 (UTC)Reply

What I can see is that the IP-range is an open proxy/VPN. That falls under no open proxy policy, so can just be blocked. Drummingman (talk) 12:34, 28 May 2023 (UTC)Reply
Thank you! Justarandomamerican (talk) 12:38, 28 May 2023 (UTC)Reply
Preferably, it open proxies [rfc:2119 should] be soft-blocked, so no existing users are affected. :) Dmehus (talk) 05:49, 7 June 2023 (UTC)Reply
I would soft-block if this were a open proxy with no history of abuse, but given that the range is used for spam, I hard-blocked it. Justarandomamerican (talk) 23:51, 7 June 2023 (UTC)Reply
Following that the discussion has not been active for more than 3 weeks, this discussion is to be closed as soon as possible. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 23:42, 1 July 2023 (UTC)Reply
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Extension of stewardship flag

Latest comment: 27 June 20239 comments6 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

With the new proposal below, I withdraw my proposal. Drummingman (talk) 15:15, 27 June 2023 (UTC)Reply

Dear, community, talking to the other 2 stewards, I wondered if the steward group could get permission to permanently bundle the user flags suppression and checkuser into the stewards flag? Then we could also see and check each other's actions faster, which is also a core policy on Wikimedia for those flags, 2. In short, this means that checkusser and suppression would thus be linked by default to the steward group. Which is partly already so, but now we have to temporarily assign the right to ourselves each time. Which I actually don't find very convenient, which is why I'm asking the community if you are comfortable with that? I would like to hear your opinions? Greetings, Drummingman (talk) 22:06, 2 June 2023 (UTC)Reply

Conditional  Support. Although, this does lose the community some knowledge of when checks are performed. If this change is made, stewards must frequently review the checkuser logs for accountability. If the stewards promise to do so, I support. X (talk) 22:26, 2 June 2023 (UTC)Reply
Of course: that is also one of the reasons why I request this extension of the flag. Drummingman (talk) 18:50, 16 June 2023 (UTC)Reply
  •  Oppose. CU and OS are a group of very sensitive rights, which means that high transparency is required. It is perfectly fine to briefly assign either of the rights with a small specific reason for assigning, so that the community can see what the tools are used for. This change erases this transparency, which is not good. — Summer talk 12:37, 4 June 2023 (UTC)Reply
  •  Support otherwise stewards can't see what the other stewards are doing when they self assign suppression/checkuser to themselves, which is a bit dodgy. Also, someone could make up a reason and nobody would really notice. Zippybonzo (talk) 13:03, 4 June 2023 (UTC)Reply
  • Partially  Support I think it would be better to add the permissions to the "stewards" group but I think the CU and OS groups should not be removed, because I believe it will be possible to promote users in CU and OS after vote like fortestwiki.myht.org. AlPaD (talk) 05:11, 5 June 2023 (UTC)Reply
  • Neutral, leaning  Oppose as written While I can appreciate it might be a bit cumbersome to add a checkuser or oversight hat, I also appreciate the value in the public transparency this provides. As well, X makes a supportive case for adding checkuser-log to the Steward group, which I could likely support, but I do think there is value in retaining the CU and OS groups as AlPaD describes above. For now, I would recommend no action at this point, on this proposal, but we could consider a subsequent proposal in the near- to medium-term future (i.e., 30-90 days after closing) to add the checkuser-log user right to the steward group. Dmehus (talk) 19:39, 17 June 2023 (UTC)Reply
    Yeah. I think add checkuser log to the steward group and keep the current groups existing separate. That’s how it’s done on most wikis, I think. X (talk) 20:14, 17 June 2023 (UTC)Reply
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Account rename

Latest comment: 1 July 20233 comments3 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

@MacFan4000:, could you rename my account to "Summer"? Thanks! Summer talk 12:39, 4 June 2023 (UTC)Reply

 Done MacFan4000 (Talk Contribs) 17:45, 4 June 2023 (UTC)Reply
Closed as the discussion has not been active for more than 3 weeks. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 23:43, 1 July 2023 (UTC)Reply
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Shorten Steward/system admin inactivity

Latest comment: 21 June 202311 comments3 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Withdrawn, no consensus. Drummingman (talk) 18:55, 21 June 2023 (UTC)Reply

I propose shortening the steward and system administrator inactivity time to encourage them to be more actively involved in the wiki. Arguably, they should be held to a stricter activity standards than admins/crats. I’m not sure what length is appropriate, so I’d like to hear the community thoughts. X (talk) 04:13, 19 June 2023 (UTC)Reply

 Oppose for now - This encounters practical problems. We are a small community with only 3 stewards and 1 system administrator. Especially in the case of the SA, there is no one else who has the rights. Stewards cannot grant and retake the rights, for example. And what do you do when you only have 1 steward left. In other words, this can become negotiable if you have more stewards and system administrators; otherwise it is not feasible, and you run the risk of having no stewards and system administrators anymore. Drummingman (talk) 07:20, 19 June 2023 (UTC)Reply
Yes, that’s a risk I hadn’t considered. But then a steward that makes 1 edit every year maintains their rights, but is no longer helping the wiki. I have changed this proposal to only include stewards until we have >1 system admin. X (talk) 10:58, 19 June 2023 (UTC)Reply
Personally, I agree with your idea that stewards should be active members of the community. I think much of my objection could be eliminated if the stewards, like system administrators, could change all user permissions. (On Wikimedia, stewards can do that too.) That also reduces the risk if the sole SA for some reason steps down or stops doing edits and there is no one to replace them. Drummingman (talk) 13:56, 19 June 2023 (UTC)Reply
I don’t know what the best answer is. I really doubt that @MacFan4000 would stop editing on the wiki and not appoint a replacement system admin. And if they do, we could always contact them cross-wiki about needing another system admin. X (talk) 14:14, 19 June 2023 (UTC)Reply
I think you could be right, but something unexpected can always happen, Unless a second system administrator is added, as far as I know, having 1 system administrator is a potential security risk for the site. You cannot replace him; therefore, which is why I think it's better to have more people (stewards and system admins) who can manage all permissions. Of course, you have to watch out for rogue individuals. But that is manageable if you only appoint strongly trusted people for the flags. Drummingman (talk) 14:43, 19 June 2023 (UTC)Reply
I find this interesting. Could we chat further on Discord about this, in a real-time format? Whats your Discord username? X (talk) 14:45, 19 June 2023 (UTC)Reply
My discord is Drummingman, also on IRC. Drummingman (talk) 14:49, 19 June 2023 (UTC)Reply
 Oppose per Drummingman. Zippybonzo (talk) 18:39, 21 June 2023 (UTC)Reply
Sorry, I should have already said this, but this thread is withdrawn. Drummingman and I already talked on Discord about possible actions we need to take before implementing this. I would oppose this now too. :) X (talk) 18:47, 21 June 2023 (UTC)Reply
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Alternate proposal: Merging CheckUser and oversight to steward

Latest comment: 2 July 202313 comments7 people in discussion

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

Requests for stewardship X

Latest comment: 2 July 202352 comments11 people in discussion

Nomination

Dear, community, I would hereby like to nominate user X as Steward.

It has now been a little over a month since X applied for Steward. Meanwhile, I see that X has developed positively and is very active. I think X could help the steward team with Test Wiki maintenance, so that an active steward is available more often to help this wiki. For example, to close community discussions that are still open. I hope you will join me in supporting X. Drummingman (talk) 14:33, 27 June 2023 (UTC)Reply

User X, please indicate here whether you accept the nomination?

Yes, I accept the nomination and sincerely thank Drummingman for his kind words. If a steward thinks I can assist the steward team, then I am up for it. :) X (talk) 14:37, 27 June 2023 (UTC)Reply

Support

  •  Support as candidate. I'm very active here and want to help out the current steward team. Ive performed most of the permissions requests since I joined the wiki, and Drummingman thinks I can help as a steward. X (talk) 14:37, 27 June 2023 (UTC)Reply
Struck as you cannot !vote for yourself. Zippybonzo (talk) 05:43, 28 June 2023 (UTC)Reply
Unstruck. A steward will decide that when closing. There is no policy saying you cannot. X (talk) 11:12, 28 June 2023 (UTC)Reply
No, but it's obvious, your support is automatically counted, it's common sense that you shouldn't vote for yourself, I'm going to strike it again as it's good practise to not vote for yourself. Zippybonzo (talk) 15:17, 28 June 2023 (UTC)Reply
As it is not forbidden by policy, you should go to the talk page for consensus instead of redoing your edit. Justarandomamerican (talk) 15:45, 28 June 2023 (UTC)Reply
And in addition, it appears that in the past users have voted for themselves, most recently @Drummingman in his successful RFS. X (talk) 15:57, 28 June 2023 (UTC)Reply
Deleting pages randomly isn't forbidden, but frowned upon, you started the edit war by reinstating a reversed edit. Zippybonzo (talk) 17:45, 28 June 2023 (UTC)Reply
We both know that unstriking votes and randomly deleting pages are 2 very different things. X (talk) 19:07, 28 June 2023 (UTC)Reply
No, my point is it doesn't say explicitly it's forbidden, but you get disciplined for it. Zippybonzo (talk) 07:09, 29 June 2023 (UTC)Reply

* Support why not? Zippybonzo (talk) 05:44, 28 June 2023 (UTC)Reply

  • Zippybonzo, I'm confused as to whether you are supporting or opposing here, given you've moved back and forth between support and oppose, and your argument on record still suggests an oppose. Can you please clarify this? Dmehus (talk) 16:08, 1 July 2023 (UTC)Reply
    Per the diff I’ve linked on your talk, Zippy has supported and struck their oppose vote. Please revert your unstrike. X (talk) 16:09, 1 July 2023 (UTC)Reply
    Yes, I can see that, but I'll decline to unstrike it for the time being, given that I've asked Zippybonzo to clarify already whether they are supporting or opposing currently and why, given their current argument on record suggests the latter. They may also wish to consider subsequent comments from users, given how they have gone back and forth. Finally, with so many users striking and unstriking comments here, I think it's best to leave it to them. Dmehus (talk) 16:14, 1 July 2023 (UTC)Reply
    You can’t just unstrike comments because that drastically affects the vote. And just because they might want to concierge other arguments isn’t a correct reason either; they will do that on their own accord. X (talk) 16:17, 1 July 2023 (UTC)Reply
  • Moved to oppose. Zippybonzo (talk) 10:40, 2 July 2023 (UTC)Reply

Oppose

  •  Oppose I don't think we need a new steward. LisafBia (talk) 06:49, 28 June 2023 (UTC)Reply
    Hello @LisafBia! Thanks for commenting on my stewardship request. I completely agree with the point you make. We don’t really NEED a new steward currently, but in my opinion, it would be very helpful. And considering that one of the stewards, @Drummingman, agrees with the need for another steward, it’s probably best to elect one. I’m not attempting to sway your opinion, just provide you with another point of view you might not have considered. Thanks for reading my long comment, sometimes I don’t know how to be less verbose. :) X (talk) 11:24, 28 June 2023 (UTC)Reply
  •  Oppose per LisafBia, and on other wikis, they have inadvertently leaked IP addresses when blocking users and the underlying IPs. Zippybonzo (talk) 07:10, 28 June 2023 (UTC)Reply
This is simply untrue. I didn’t “inadvertently leak” IPs. I blocked the IPs of blocked users after a steward discussion. @Justarandomamerican: can tell you that he agreed with the actions, I was just the one who performed them. And with our updated privacy policy to exempt socks, the actions are policy supported too. In addition, our community just reviewed the actions and thought they were appropriate. You were the only one who disagreed. I can definitely see how it would come off that way, but this was a carefully discussed action that the stewards thought needed to be taken. X (talk) 11:11, 28 June 2023 (UTC)Reply
Yes, but IPs were still released, whether it was permitted or not is a different question, and I'm leaving my vote as is, and we don't need a new steward in any case. Zippybonzo (talk) 13:18, 28 June 2023 (UTC)Reply
The argument that IPs that were released on another wiki after discussion to block them in order to prevent disruption doesn't seem to be taking the circumstances here into consideration. This is a wiki that permits Stewards to go beyond just releasing IPs to block them. It's fine if you oppose based on need, that's okay. But using the argument explained above as a secondary argument still doesn't make it a good argument. Justarandomamerican (talk) 13:36, 28 June 2023 (UTC)Reply
  •  Oppose possibly strong for multiple reasons. For one thing, as LisafBia has indicated above, 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. Secondly, 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. As well, I also see user conduct issues. While I do see some edit warring on Zippybonzo's part, I also see edit warring on X's part, including striking other users' votes. That should be left to other users to do; it's just not a good look, especially in one's own permission request. Even if it was justified, it's a potential conflict of interest. More problematic, though, it makes it difficult for other Stewards and community members to fully and easily assess the edits in editorial disputes. Additionally, in X's last Stewardship request, there was strong opposition to the request, to submit to or agree to another nomination so soon, disregards the community consensus formed in that discussion—a closure which was pre-empted by X's closing the request as withdrawn, which, too, is problematic from that perspective. Finally, I also have issues with the user's recent handling of Seiyena, proceeding directly to a longer term block and interfering with Justarandomamerican's handling of the situation, which included firm warnings. This makes me question their potential judgment as a Steward. Finally, their reaching out to me privately to request closure, for the sake of closing the discussion, which was barely opened four days ago also troubles me. I don't know whether X used Special:EmailUser to reach out to MacFan4000 as well, but I do know they reached out to Drummingman to close, and Drummingman closing as nominator would indeed by a highly involved, problematic closure, so I'm glad he declined that. Dmehus (talk) 16:03, 1 July 2023 (UTC)Reply
    I cannot see striking of other users' votes, can you please provide a diff? Thank you. Justarandomamerican (talk) 16:12, 1 July 2023 (UTC)Reply
    He may be referring to when I added an end strike when ZippyBonzo forgot to, although that was definitely a correct action. X (talk) 16:14, 1 July 2023 (UTC)Reply
    Justarandomamerican, yes, I believe I linked to it in an edit summary, no? I believe it may be the one X refers to. Whether it was a correct strike if Zippybonzo had withdrawn their !vote, they are also capable of fixing it themselves or, should they not be sufficiently active, letting an unconflicted user fix it. That's still problematic. Dmehus (talk) 16:24, 1 July 2023 (UTC)Reply
    Helping out another user is problematic? I was just trying to help. X (talk) 16:26, 1 July 2023 (UTC)Reply
    In your own permissions request. That's conflicted. You [rfc:2119 should] have left it to another user to fix. Dmehus (talk) 16:28, 1 July 2023 (UTC)Reply
    Okay. But I would also like to point out that undo-ing a strike that supports what you think is also very conflicted and problematic. X (talk) 16:30, 1 July 2023 (UTC)Reply
    I'm not too sure how adding an end-strike to a !vote amendment which resulted in the !voting user striking an entire part of discussion out is inherently problematic. It is a mere technical fix which should be uncontroversial. Justarandomamerican (talk) 16:31, 1 July 2023 (UTC)Reply
    I directly recall asking X to do it on my behalf off-wiki. Zippybonzo (talk) 10:34, 2 July 2023 (UTC)Reply
    I’m still trying to comprehend your entire reasoning, but I wanted to point out that @Drummingman was the one who asked me to email you requesting closure. He can confirm this. X (talk) 16:13, 1 July 2023 (UTC)Reply
    I don't know about that; all I do know is you e-mailed me. I'm sure Drummingman would have e-mailed me, as he has e-mailed me in the past with respect to other matters, if he felt closure was needed. Perhaps there could be a more justifiable case in the case of a permission request being outstanding for two or three weeks, but 3-4 days? That's quite quick, in my view. Dmehus (talk) 16:21, 1 July 2023 (UTC)Reply
  •  Oppose: I believe that this candidate having Steward rights may cause even further problems when they intervene in disputes. I have concerns about their independent judgment on second thought, due to working with them elsewhere. It appears they may not be able to make proper decisions independently. This !vote will likely be amended as I do further research. Justarandomamerican (talk) 17:08, 1 July 2023 (UTC)Reply
  •  Oppose: I'm going to add a fresh oppose as I'm fed up of striking and unstriking, but whilst I believe X is competent, I would like to see them holding advanced permissions somewhere like Wikimedia. I also find their conduct in this discussion to be confusing/concerning. The rest of my oppose !vote is summed up by Justarandomamerican and Dmehus. Zippybonzo (talk) 10:40, 2 July 2023 (UTC)Reply

Neutral

Questions

Result

Withdrawn by X (talk) at 12:39, 2 July 2023 (UTC).Reply

User:Example

Latest comment: 28 June 20233 comments3 people in discussion

Greetings, @Drummingman: @Dmehus:.

I have a query regarding tracking and identifying individuals who have accessed a particular user account and conducted unauthorized activities, specifically acts of vandalism. Considering the recent blocks on the user in question, I believe it is important to determine the individuals responsible for such actions. Is there a feasible method to achieve this? Sav • ( Edits | Talk ) 02:04, 28 June 2023 (UTC)Reply

I don’t think any action is needed at this time, considering the account hasn’t edited since March. If the account were to start vandalizing again, a CheckUser may want to take a look, but now I’m not sure it’s needed. However, it’s ultimately up to the stewards. X (talk) 02:10, 28 June 2023 (UTC)Reply
I agree with X. CU also no longer makes sense because the logs are only kept for 90 days. However, I did block the account indefinitely as a Steward action because it is indeed a site risk. Drummingman (talk) 14:01, 28 June 2023 (UTC)Reply

Block proxy 159.89.228.253

Status:  Done

  • 159.89.228.253 - A SOCKS4 open proxy. Port for this proxy is 38172. I am not an admin. Requested 19:57, 30 June 2023 (UTC).

Tailsultimatefan3891 (talk) (contribs) (rights) (block)

Block numberous proxies

Latest comment: 30 June 202310 comments2 people in discussion

Status:  Done

I am not an admin.

Tailsultimatefan3891 (talk) (contribs) (rights) (block) 20:07, 30 June 2023 (UTC)Reply

Also block: 13.81.217.201. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 20:08, 30 June 2023 (UTC)Reply

 Done X (talk) 20:09, 30 June 2023 (UTC)Reply

Also block: 51.38.191.151. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 20:09, 30 June 2023 (UTC)Reply

 Done X (talk) 20:11, 30 June 2023 (UTC)Reply

Also block: 162.144.233.16. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 20:13, 30 June 2023 (UTC)Reply

 Done X performed a range block including this, and a individual block for this proxy. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 20:17, 30 June 2023 (UTC)Reply

Also block: 72.195.34.59. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 21:28, 30 June 2023 (UTC)Reply

 Done performed by X. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 22:11, 30 June 2023 (UTC)Reply

Also block: 98.188.47.132. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 22:12, 30 June 2023 (UTC) Reply

Proxy bot

Latest comment: 1 July 20239 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Status:  Not done and withdrawn

Nomination

Hi, This is a nomination from Tailsultimatefan3891. Can any administrator have a proxy bot? It's the same, but with slight differences. Instead of blocking proxies manually, it's now automatically. It prevents proxies from further disruption and protects the wiki from disruption from proxies. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 20:25, 30 June 2023 (UTC)Reply

Note: Uses Special:Block to block proxies. The bot will check proxies at this link: [1]. Then will copy the selected IP and paste the selected IP at the "User/IP" section. Then it will block the proxy. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 21:22, 30 June 2023 (UTC)Reply

Please link the code. X (talk) 21:24, 30 June 2023 (UTC)Reply
What does it mean? Tailsultimatefan3891 (talk) (contribs) (rights) (block) 21:45, 30 June 2023 (UTC)Reply
A bot needs code to run… X (talk) 21:47, 30 June 2023 (UTC)Reply

Signature that belongs to the user that will own the proxy bot

Username for the proxy bot

Support

Oppose

Neutral

Comments

Result

Status as withdrawn. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 17:38, 1 July 2023 (UTC)Reply

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Rename Request

Latest comment: 1 July 20235 comments4 people in discussion

Hello! Would it be possible for a steward to rename me to Piccadilly? Thank you! Seiyena (My Contribs | Talk to me) 21:25, 30 June 2023 (UTC)Reply

 Support as it will create consistency with other projects. X (talk) 21:41, 30 June 2023 (UTC)Reply

Pinging @MacFan4000: @Dmehus: @Drummingman: Tailsultimatefan3891 (talk) (contribs) (rights) (block) 21:28, 30 June 2023 (UTC)Reply

 Done MacFan4000 (Talk Contribs) 15:44, 1 July 2023 (UTC)Reply
Thank you so much! Seiyena (My Contribs | Talk to me) 17:04, 1 July 2023 (UTC)Reply

Possible sockpuppetry

Latest comment: 1 July 20237 comments5 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

@Drummingman: @Dmehus: @MacFan4000: Is Seiyena (Now Piccadilly) and Cocopuff2018 socks?

If CheckUser evidence said they're sockpuppetry: Revoke their rights and block them indefinitely with email and TPA access not revoked. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 21:36, 30 June 2023 (UTC)Reply

Cocopuff is definitely not a sock of mine. They're a seperate person. Seiyena (My Contribs | Talk to me) 21:37, 30 June 2023 (UTC)Reply
  1. REDIRECT Special:MyLanguage/Template:Not done - It is abundantly clear that those 2 are not sock puppets. Drummingman (talk) 21:40, 30 June 2023 (UTC)Reply
Thanks. I was just about to say the same thing. X (talk) 21:40, 30 June 2023 (UTC)Reply
Cocopuff2018 is most definitely not a sockpuppet of Seiyena. Behaviourally, they are not even remotely similar, and Cocopuff2018 has also confirmed their Miraheze account. Dmehus (talk) 16:45, 1 July 2023 (UTC)Reply
Yeah. I’m not quite sure what gave @Tailsultimatefan3891 that idea. X (talk) 16:59, 1 July 2023 (UTC)Reply
That's an easy question to answer. Well, this discussion is to be closed. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 17:34, 1 July 2023 (UTC)Reply
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Block proxies, users, and IPs at the link below

Latest comment: 1 July 20231 comment1 person in discussion

Block proxies, users, and IPs: User:Tailsultimatefan3891/Block users and IPs requests

Note: I am not an admin. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 17:49, 1 July 2023 (UTC)Reply

Change group membership for user Example

Latest comment: 1 July 20232 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Status:  Not done

Change from: Example user

Change to: Example user, blocked from chat

Reason: Permanently blocked by Drummingman (autoblock disabled, account creation disabled, email disabled, cannot edit own talk page) as a steward action.

Thank you. From, Tailsultimatefan3891 (talk) (contribs) (rights) (block) 17:56, 1 July 2023 (UTC)Reply

 Not done as blocked users are automatically blocked from chat. X (talk) 18:02, 1 July 2023 (UTC)Reply
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Add IPBE privilege

Latest comment: 2 July 20238 comments4 people in discussion

Nomination

This is Tailsultimatefan3891. I'd like the wiki to have the IPBE (IP block exemption) privilege to Test Wiki. Unfortunately however, I can't do it immediately, as only system administrators can do it. The IPBE privilege can have the following right:

  • Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)

Update of 18:51, 1 July 2023 (UTC): Only in the case of an IP block, auto-block, and/or range blocks that anyone has logging to their user but not an admin.

From, Tailsultimatefan3891 (talk) (contribs) (rights) (block) 18:35, 1 July 2023 (UTC)Reply

Support

Oppose

Neutral

Comments

  •  Comment: I don't know if IPBE is very useful or not. While IPBE for admins is being redundant, it's not redundant for non-admins. But IPBE isn't totally useful because with just 1 person voting  Support (that was me) 2 persons voting  Support (that was Zippybonzo and me) and also 2 persons voting  Oppose (that was Sav and X). By the way, it's not extremely useful. Tailsultimatefan3891 (talk) (contribs) (rights) (block) 23:34, 1 July 2023 (UTC)Reply

Result

Retrieved from "https://testwiki.wiki/index.php?title=Test_Wiki:Community_portal&oldid=28472"