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

Proposal

Hello, I happy to here to discuss on my new proposal to make a mediawikipage for this this JavaScript that help to easily block and oversight or suppress the revision of block user, spammers. etc, this script is originally based on User:WhitePhosphorus/js/all-in-one.js of metawikimedia, but this script needed to modified them, then it's script ready for use on Tesrwiki.

• I think User:Aviram7/js/all-in-one.js is move to mediawiki namespace, then add this script in gadget and allow to sysop, crats, stewards for use on you're preferences.

@MacFan4000, Dmehus, Drummingman, and Justarandomamerican: Thanks ~~ αvírαm|(tαlk) 08:36, 9 April 2024 (UTC)

I would be fine with adding this as a gadget, but not on the common.js. X (talk + contribs) 10:10, 9 April 2024 (UTC)

@X: Hello, Well! we have no probelm, If you like more gadgets for use, please see my common. js and this gadget is very helpful, firstly please test this js and then we think what can I do later?.

Thanks ~~ αvírαm|(tαlk) 12:41, 9 April 2024 (UTC)

This gadget would likely need to be restricted to stewards due to just how powerful it is. Being able to revert all of a users edits, delete all the pages they've created, and block them in one click is simply a lot. X (talk + contribs) 18:40, 9 April 2024 (UTC)

X, You're right this js script is very powerful Use of this JavaScript should only be allowed by stewards and not allowed to use by any other privileged persons. ~~ αvírαm|(tαlk) 03:56, 10 April 2024 (UTC)

I've commented it out of your common.js page for the moment, as it could cause some serious mayhem if used improperly. Ask me if you need a test performed. Justarandomamerican (talk) 14:42, 10 April 2024 (UTC)

@Justarandomamerican Hello, Thank you for removing this script from my common. js, I've already performed the after adding this script on my common. js, I think this js script is more useful for the stewards.  Thanks ~~ αvírαm|(tαlk) 15:21, 10 April 2024 (UTC)

Replace text

I've used it a lot in the past, and it saved a lot of time. But as of now, it's restricted to stewards. Why's that? Saint (talk) 04:43, 10 April 2024 (UTC)

It was found that a vandal who gained sysop rights could vandalize the Main Page or similarly important Steward protected pages using ReplaceText. I know it has a lot of utility for you, so feel free to send me a message on my talk page, or Drummingman on his with a request, ensuring that original text, new text, and namespace(s) are provided. Justarandomamerican (talk) 12:53, 10 April 2024 (UTC)

Is it possible to allow interface administrators to use it? X (talk + contribs) 13:16, 10 April 2024 (UTC)

I suggested that to MacFan when I originally opened a security task about the issue. Me personally, I think it would be better to create a separate group that's able to use it, as IA is primarily intended to allow editing of script pages, though I am fine with bundling it in to IA (and Stewards) along with creating a separate group. Justarandomamerican (talk) 13:19, 10 April 2024 (UTC)

'Crat sysop first requirement

@EPIC, X, and DR: as interested persons. Recently, upon DR requesting bureaucrat, they were given it without first being an administrator. EPIC removed the crat right, and X restored it, stating that the requirement was pointless. To prevent a wheel war, I think it's best to set down community consensus on the issue. What do you, the reader, think of the requirement to be a sysop before being a bureaucrat? Justarandomamerican (talk) 03:33, 11 April 2024 (UTC)

@Justarandomamerican: I've support you're thoughts, This is test wiki not Wikipedia, we are here to testing of specific permission, firstly If any new user request for both rights, then firstly grant only sysop permission but not crats, because sysop have more permission on his group, crats is most important permission on the wiki, I don't understand why both user's make editwar in removing or adding crats permission from @DR, who received both permission after reviewing his request by an other crats. ~~ αvírαm|(tαlk) 04:24, 11 April 2024 (UTC)

I personally think that just like on other test wikis, there should some kind of requirement before being able to request crat, either an edit requirement (maybe something like 10 edits before being able to request bureaucrat would be a fair requirement if so?), or a requirement of a specific amount of days of having sysop before requesting crat (a day or two perhaps), or maybe a mix of both of those requirements.

The reason I think so is because unlike on other test wikis, the crat permission is quite powerful and can remove both bureaucrat and sysop rights. If it's given very liberally it can be quite dangerous. Now, I know DR from Wikimedia and they are a trusted user who I certainly don't think would abuse the bureaucrat rights, so I have nothing against them having crat. But, I don't have any intents to wheel war, the permissions have been given back and it can remain so. EPIC (talk) 08:10, 11 April 2024 (UTC)

My intention was also not to wheel war. I know EPIC mentioned some suggestions for "requirements" for the 'crat role. However, as of now, those do not exist, making the rule about being a sysop first pointless. There is some Wikimedia essay about not following the policies if doing so would prevent you from improving the site, but I can't remember what it was titled. X (talk + contribs) 11:51, 11 April 2024 (UTC)

You can remove the bureaucrat right from my account since I won’t be using it. I have MediaWiki installed on my local machine for testing purposes, and I already have all the advanced rights there. Here on this test wiki, my goal is to assist others by deploying some important and useful scripts and translating help pages. Initially, I thought that crats have access to grant the interface admin right, but it appears they do not, so I no longer require this role. Could any Steward please grant the interface admin right to my account? I would like to deploy some useful gadgets. Also, for granting requirements, I believe granting the bureaucrat role should be discretionary. DR (talk) 09:52, 11 April 2024 (UTC)

We should definitely set requirements for gaining crat. It is a powerful position, and any disruptive user can easily misuse it. Since EPIC knew DR , there would not be a problem, but if a random user came and requested sysop and crat, there is a chance of vandalism or disruption. I propose that a user must wait 24 hours and make 10 edits before requesting crat rights Harvici (talk) 06:55, 12 April 2024 (UTC)

It's not a terribly powerful position, since it's mostly a testing right, but that being said, it does require an extra degree of trust as it includes extra permissions like nuke and import, which can cause vandalism that is time consuming to revert if used by unscrupulous actors. Since Justarandomamerican initiated the discussion, I will contribute here and allow Drummingman or MacFan4000 to close. Your suggestion of 10 edits is a good one, but I'd also add a time requirement and would suggest a minimum of a four day wait unless the user previously held user rights here, then the waiting period requirement is waived. We could also add in an alternate pathway to waive the waiting period requirement, such has having a confirmation edit from a mainstream wiki farm (Wikimedia, Fandom, or Miraheze) and being a known user in good standing there. Dmehus (talk) 01:31, 27 April 2024 (UTC)

Permission revocation request

Hello, I am currently suffering from high powerful stress which is impairing my ability to work on test wiki and elsewhere, hence, I request the admins of test wiki to please remove my sysop + crats permission on my account, I will try to come back and edit here. Thanks to all the editors of test wiki for giving me a chance to test the tools of sysop and crats and I hope I have not broken any rules and regulations of test wiki..  Thanks ~~ αvírαm|(tαlk) 04:40, 16 April 2024 (UTC)

 Done — You are free to reapply for user permissions when you return. Drummingman (talk) 08:52, 16 April 2024 (UTC)

Interface Right

Hello everyone, I try to re- modifying Twinkle tool for use, but I don't think Twinkle Tool are working on Test Wiki; If you like I like to fix Twinkle tool for working on Test Wiki, so, I needed, please grant me Interface right for permanently for successfully complete this work. Thanks ~~ αvírαm|(tαlk) 16:46, 18 April 2024 (UTC)

I think that for the moment you can rework this script into personal subpages and we will see later about the rights because other interface admins will be able to add it as a gadget.DodoMan (talk) 16:57, 18 April 2024 (UTC)

@DodoMan: Hello, Do you know Twinkle Tool are not currently available in gadgets section and it's subpages are not currently exist here, We recreating those pages and interface admin right are more help to edit and create js pages on Test Wiki.Cheers!~~ αvírαm|(tαlk) 17:04, 18 April 2024 (UTC)

@Aviram7:Yes I know the tool it’s inavailable but you can rework script on your subpages. At worst, I will create these mediawiki pages and rework them with you. And also you need to request rights to Test Wiki:Request Permissions.DodoMan (talk) 17:17, 18 April 2024 (UTC)

@DodoMan: That's Great! well I going to request for Interface permission on request page and try to creating twinkle subpages on userspace and I beleive our hard struggle will be positive result proved.~~ αvírαm|(tαlk) 17:33, 18 April 2024 (UTC)

I requested for Interface permission on TW:RfP. ~~ αvírαm|(tαlk) 17:40, 18 April 2024 (UTC)

Filter 120

I propose converting it to an abusive username prevention filter. Any objections? Codename Norte 🤔 talk 15:27, 25 April 2024 (UTC)

Nope,is good for me.(oh no is my bot account)BotRafdodo (talk) 16:38, 25 April 2024 (UTC)~

None. Justarandomamerican (talk) 21:46, 25 April 2024 (UTC)

Standby... writing the regex... Codename Norte 🤔 talk 02:16, 26 April 2024 (UTC)

and WHEW!!!  Done. Justarandomamerican, you might want to remove the account creation conditions from filter 92 since I implemented them to filter 120. Codename Norte 🤔 talk 03:31, 26 April 2024 (UTC)

Any objections if I set this to disallow? Codename Norte 🤔 talk 01:47, 27 April 2024 (UTC)

LGTM. I'm not sure the likelihood of LTAs and blocked users trying to use variations of known usernames, but it can't hurt, either. Dmehus (talk) 02:36, 27 April 2024 (UTC)

No, if there's a helpful message. Justarandomamerican (talk) 22:10, 29 April 2024 (UTC)

 Done. Codename Noreste 🤔 La Suma 02:50, 30 April 2024 (UTC)

Crat requirements's policy

As in the above discussion, I have established policy-related criteria for the CRT position, as previously stated by Dmehus, " It's not [...] require an extra degree of trust as it includes extra permissions like nuke and import which can cause vandalism [...]. Harvici (talk) 18:31, 27 April 2024 (UTC)

Adoption Discussion

As a policy, this would practically just codify community norms on how to grant crat rights. I propose (and support) adopting this as policy.

•  Support Harvici (talk) 18:35, 27 April 2024 (UTC)
•  Conditional support: I'll support this with the modifications I have made. There should be some level of discretion granted to Stewards, as this is a test wiki, and trusted users should be able to bypass the requirements, along with Stewards being able to requalify a person. Otherwise, I'd say this is a reasonable security requirement. Justarandomamerican (talk) 18:59, 27 April 2024 (UTC)
•  Conditional support The draft policy isn't exactly as I would've liked, but it's reasonable. Justarandomamerican's reason for additional, common sense exceptions by Stewards is also reasonable, and so I support that. It arguably goes without saying Stewards are able to do this anyway, but I support making this a conditional requirement for my support. Dmehus (talk) 19:12, 27 April 2024 (UTC)
• What do you guys think about Dmehus suggestion to waive the waiting period requirement, such has having a confirmation edit from a mainstream wiki farm (Wikimedia, Fandom, or Miraheze) and being a known user in good standing there.Should we make a change with respect to this? Harvici (talk) 02:07, 28 April 2024 (UTC)
•  Comment: Changed the criteria from "must have been a registered user for a minimum of 4 days" to "must have been an administrator for a minimum of 4 days"As any user can ask for crat rights before they even get sysop (the registered criteria is also mentioned on the top) Harvici (talk) 13:11, 29 April 2024 (UTC)

  I'd prefer that, Harvici. I would've preferred your language originally, but wasn't enough to cause me oppose the proposal. Dmehus (talk) 23:22, 29 April 2024 (UTC)

•  Strong oppose How long has it been since someone has abused their bureaucrat permissions? Months, at least. This simply makes it harder for users to test, and as such, I oppose. X (talk + contribs) 13:27, 29 April 2024 (UTC)

  This isn't about adding revocation criteria, X. As it stands, if you're an existing bureaucrat, you meet the exception criteria to have the bit re-added without the waiting period requirement. I would, however, potentially suggest adding a requirement that the bureaucrat user group is limited to the user's main account only. Justarandomamerican, thoughts? Dmehus (talk) 23:24, 29 April 2024 (UTC)

  I do suppose that could be added, but how would we handle legitimate test (such as testing the bureaucrat right on its own, without sysop) or cratbot accounts? Justarandomamerican (talk) 00:33, 30 April 2024 (UTC)

  We wouldn't be able to technically restrict it, no, but, rather, it would provide automatic revocation criteria for the bureaucrat bit if Stewards suspect the two users are the same, or where the user has confirmed the two accounts are the same. That is, the bit would be removed from the legitimate sockpuppet accounts and a Steward would remind users to pick one account they want their bureaucrat bit on. Dmehus (talk) 02:14, 8 May 2024 (UTC)

  With the provisions for common sense exceptions by Stewards, that's fine. Justarandomamerican (talk) 13:11, 8 May 2024 (UTC)

Omnibus RfC: Unbundling abusefilter permissions from Administrators

I would like to propose all of the following: 1: Unbundle all abusefilter-related (excluding basic rights already included in * or user) from the sysop group. 2. Bundle these rights into the Steward group. 3. Create a new abusefilter-edit group with these rights, and a abusefilter-helper group with view-only access, both grantable by a Steward upon request. Though this would be taking away a permission used by many, the AbuseFilter extension is a very powerful tool: There is the potential for evasion of restrictions imposed on specific users by the ability to view private filters, let alone the fact that a vandal that gets access to it could actually block innocent, or even potentially all edits. If this is implemented, I plan to grant the edit right to those who already work with our edit filters. Justarandomamerican (talk) 21:43, 27 April 2024 (UTC) withdrawn, see my comment below Justarandomamerican (talk) 22:00, 29 April 2024 (UTC)

This sounds good to me. Thanks for starting the RfC. I'd only suggest a small change, by allowing any sysop to view the abuse filters; they just wouldn't be able to edit them unless they have the abusefilter-helper group. I'd also suggest adding both a time-based inactivity requirement (something like 30-90 days) whereby someone not having used the permission in the given time period can lose the permission and also broad Steward discretion to remove the permission where it's either misused or no longer used recently. Dmehus (talk) 00:06, 28 April 2024 (UTC)

That sounds good to me. I only added the "view private filters" unbundle because with a bit of knowledge of the language of abuse filters, you could probably bypass a filter restricting you, but I suppose there isn't a problem with that yet. Justarandomamerican (talk) 00:22, 28 April 2024 (UTC)

 Comment: I am not a sockpuppeteer or something, and I assist with abuse filters almost all the time, but is the abusefilter-edit group not allowed to have the abusefilter-modify-restricted because of the potential of actions that can impact actual users? Codename Norte 🤔 talk 03:20, 28 April 2024 (UTC)

I don't have strong feelings about that. Justarandomamerican (talk) 03:55, 28 April 2024 (UTC)

Should the abusefilter-edit group have the restricted action modifcation right, community consensus or similar is mandatory. Codename Noreste (talk) 03:59, 28 April 2024 (UTC)

The abusefilter-modify-restricted user right is currently restricted to Stewards for mainly security and abuse reasons. I suppose we could sub-delegate this user right, but I'd rather see it be a separate user group, like abusefilter-sysop or something, that would also require a community vote (like non-Steward suppressors) (since it requires an extra degree of trust and also has some real, non-test administrator responsibilities). Dmehus (talk) 16:24, 28 April 2024 (UTC)

I would propose all of the following in addition:

• All admins should keep the abusefilter-log-detail right.
• The abusefilter-helper group should only have the abusefilter-view-private and abusefilter-log-private permissions.
• The abusefilter-edit group should just simply have the name abusefilter, and have the following rights (in addition to having a community vote requirement):

1) Create or modify abuse filters (abusefilter-modify) [this may or may not need the two rights listed on the abusefilter-helper permission since this permission allows you to view the filters and their logs, whether public or private]

2) Create or modify what external domains are blocked from being linked (abusefilter-modify-blocked-external-domains)

3) Modify abuse filters with restricted actions (abusefilter-modify-restricted)

4) Revert all changes by a given abuse filter (abusefilter-revert)

• Stewards do not need to assign the abusefilter or abusefilter-helper permission to themselves, but they can assign and remove either of the two to trusted users following a community vote.

Codename Noreste 🤔 La Suma 17:27, 28 April 2024 (UTC)

A community vote and/or Steward discretion (for helper, or granting edit to those who have worked on abuse filters before) or consensus (for neither of those cases), I presume? Appointment by community vote only would be a higher bar than we set for our non-steward suppressors. Justarandomamerican (talk) 18:24, 28 April 2024 (UTC)

 Conditional support per my comment above. Justarandomamerican (talk) 18:25, 28 April 2024 (UTC)

I am writing a proposed policy about the abuse filter and their proposed user rights; anyone can help. Codename Noreste 🤔 La Suma 01:20, 29 April 2024 (UTC)

 Strong Support I support this proposal. ~~ αvírαm|(tαlk) 09:28, 29 April 2024 (UTC)

How long has it been since someone has abused abuse filter access? Months, years? I don't ever recall this being an issue. Like the above proposal, this simply makes it harder for users to test and I will always  Strongly oppose that. X (talk + contribs) 13:29, 29 April 2024 (UTC)

This also makes it extremely difficult to make small changes to abusefilters, or fix bugs. This is a solution looking for a problem, in addition to being extremely bureaucratic. Must I remind everyone that this is a testwiki, where people test tools like abusefilter? X (talk + contribs) 17:09, 29 April 2024 (UTC)

 Strong Support I added a lot of content to the policy; feel free to add your own suggestion :) Harvici (talk) 14:49, 29 April 2024 (UTC)

 Oppose I haven't found any vandalism in the abuse filters so far. It seems unnecessary to make such a change when there is no vandalism. Therefore, I am opposing this proposal. LisafBia (talk) 17:16, 29 April 2024 (UTC)

I now  withdraw my proposal and oppose the policy proposal upon reading the two rational oppose comments. Justarandomamerican (talk) 21:57, 29 April 2024 (UTC)

Alternate proposal: Restricted group and abusefilter sysop group

Rather than the above: Create a abusefilter-restricted group, grantable and removable only by Stewards at their discretion or upon a community partial ban from the abuse filter, with rights related to modification and private filters actively revoked. This would curb abuse (such as of the guidance filter), whilst making allowance for testing. In addition, I will also propose the AbuseFilter sysop group mentioned above in this proposal too, with the modify-restricted right, grantable upon consensus of at least two stewards or of the community. Justarandomamerican (talk) 21:55, 29 April 2024 (UTC)

@X, LisafBia, Dmehus, Codename Noreste, and Harvici: as participants in the RfC above. Justarandomamerican (talk) 22:05, 29 April 2024 (UTC)

I'd support that. X (talk + contribs) 22:47, 29 April 2024 (UTC)

So what will we name this group? Codename Noreste 🤔 La Suma 23:07, 29 April 2024 (UTC)

In terms of human readable language, something along the lines of "Users restricted from editing the edit filter" (or a shortened version that conveys the same information) would be the first choice for a name (to me). Justarandomamerican (talk) 00:36, 30 April 2024 (UTC)

How about "Users blocked from the abuse filter" for the abusefilter-restricted right, and "Abuse filter administrators" for abusefilter-sysop? The former would be useful for say, Piccadilly if they have one more chance (which I doubt) while they may not edit any filter or view any private filters, including one that restricts their disruptive actions. Codename Noreste 🤔 La Suma 01:20, 30 April 2024 (UTC)

Both of those sound good. Justarandomamerican (talk) 01:21, 30 April 2024 (UTC)

Abuse filter administrators have the additional ability to modify filters with blocking abilities in the same fashion as stewards do, while users blocked from the abuse filter may not edit any filter or view private filters; however, they can still see said public filters and the abuse log. I will update my proposed policy on the abuse filter. Codename Noreste 🤔 La Suma 01:24, 30 April 2024 (UTC)

It is also possible that users blocked from the abuse filter will be able to view private filters to learn from their mistakes/abuse, seeing my discussion with Doug below. Justarandomamerican (talk) 01:26, 30 April 2024 (UTC)

Couldn't we simply revoke the abusefilter-view-private and abusefilter-log-private in the abusefilter-restricted right, and that trusted users experienced with abuse filters should take care not to discuss private filters in public? Codename Noreste 🤔 La Suma 01:29, 30 April 2024 (UTC)

That is one of three possibilities. I would be more supportive of a separate group restricting view access or of not doing so and simply restricting edit access, due to the rational possibility of a restricted user looking at a filter to learn from their mistakes. Justarandomamerican (talk) 01:36, 30 April 2024 (UTC)

 Support LisafBia (talk) 08:59, 30 April 2024 (UTC)

That could be a good way of doing it. So you're proposing to use $wgRevokePermissions essentially, to revoke all abuse filter permissions normally granted to the sysop group by way of a new user group, though I'd suggest a friendly amendment, if you're amenable to it, of permitting view only access to the filter (so such partially blocked/banned users could use it to actually learn from their mistakes)? You would then propose to give access to the restricted abusefilter permissions as part of a new group? If so, I'm in favour of the former, but a little lukewarm on the latter. Not necessarily against it, but also not entirely sure the need, given the level of active stewards we have now and being concerned with regard to hat collecting. I'd be more favourable, if we added some removal criteria (i.e., unused completely in the last 30-60 days), by community revocation with a 75% net support ratio, or by consensus of two or more stewards. Dmehus (talk) 23:18, 29 April 2024 (UTC)

I would support the removal criteria for the modify restricted right (or abusefilter sysop). Though I am definitely amenable to view only access for the group restricted from modification, I am also thinking of how that could be abused by a user with a certain level of knowledge. Perhaps that could be left out for now, to avoid creating 2 separate groups? Justarandomamerican (talk) 00:30, 30 April 2024 (UTC)

I propose that we create three seperate rights abusefilter-sysop, abusefliter-restricted ,abusefilter-view-restricted .If the crat policy passes then we could remove all the abusefilter rights from the sysop and bundle them into abusefilter-sysop which would only be granted if the user is a crat (since to become a crat they have to prove us that they are trustworthy). abusefilter-restricted only let the user only view the abuse filters (steward will only place this right if a user has misused the abusefilter or the user just wants to view and not edit) and abusefilter-view-restricted will not allow the users to even view any abuse filter (this would only be placed if the user has caused serious disruption ) Harvici (talk) 01:50, 30 April 2024 (UTC)

Sorry, but I'm gonna have to disagree. I would NOT suggest removing the abuse filter modification rights from the sysop toolset, and if an admin only wants to view abuse filters, including private filters, then they should not edit said filters at all. As for the revocation of viewing abuse filters, I think you meant the revocation of viewing private filters and editing all filters, which should probably be merged to the abusefilter-restricted right. Codename Noreste 🤔 La Suma 02:01, 30 April 2024 (UTC)

Well, then we can create one right: abusefilter-sysop.We would remove all the abusefilter filter-related rights (except the ability to view) from sysop toolset.All the users don't have experience with abuse filters (they can also cause disruption even in good faith), and there is no need to give them until they request abusefilter-sysopwhich would have the ability to edit the filters and it would be granted by stewards Harvici (talk) 13:18, 30 April 2024 (UTC)

We should add some criteria for granting and removing. Codename Noreste 🤔 La Suma 22:15, 4 May 2024 (UTC)

Umm... removing criteria would be misuse or inactivity or both and granting can be passing a vote of community portal or steward deems the user trusted or both Harvici (talk) 05:07, 5 May 2024 (UTC)

Non-controversial changes to filters with restricted actions are allowed such as simplifying filters, but controversial changes such as enabling those actions on filters without determining consensus are not. Codename Noreste 🤔 La Suma 17:57, 5 May 2024 (UTC)

Are we circling back to the above proposal which was pile-on opposed? Justarandomamerican (talk) 00:27, 6 May 2024 (UTC)

I meant the alternate proposal. Codename Noreste 🤔 La Suma 04:57, 6 May 2024 (UTC)

Umm....

I have one last account rename request for the stewards: Jody. Saint (talk) 00:08, 28 April 2024 (UTC)

 Done. Feel free to come back and request another, within reason. Justarandomamerican (talk) 00:19, 28 April 2024 (UTC)

One more rename request

I actually intended to put Noreste instead of Norte; therefore, I am requesting a rename to Codename Noreste one last time to match Wikimedia and The Test Wiki. Thank you. Codename Norte 🤔 talk 03:26, 28 April 2024 (UTC)

 Done. Justarandomamerican (talk) 03:53, 28 April 2024 (UTC)

Request for Block Against Piccadilly

Good morning,

I am writing to bring attention to a matter concerning User:Piccadilly and to propose a necessary course of action. This individual has been afforded numerous opportunities to rectify their behavior on The Test Wiki, as evidenced by their extensive history. Unfortunately, they have repeatedly demonstrated a pattern of abusing these chances.

Given the circumstances, it is my firm belief that allowing such behavior to persist undermines the integrity of our community and the principles it stands for. Therefore, I urge you all to consider this matter seriously and contribute your opinions on the appropriate action to be taken.

Your cooperation and thoughtful input in this regard are greatly appreciated.

Thank you.

Warm regards, Sav • ( Edits | Talk ) 01:05, 6 May 2024 (UTC)

Statement from Piccadilly

Hello Test Wiki community,

I realize that I have caused unnecessary and unacceptable issues here with my behavior, and it will not happen anymore. And I will behave myself elsewhere too, such as not sending unnecessary messages to anyone regarding my sanctions on other projects.

My proposal: I am unblocked one final time. If I cause even the slightest disruption, I am automatically "community-banned", no exceptions. I understand most people here have had enough of the disruption I have caused, but I would like one last opportunity to show that I can test constructively here.

I will answer any questions or concerns to the best of my ability. Piccadilly (My Contribs | My Messages) 23:10, 7 May 2024 (UTC)

You have an active, current, and indefinite Steward-imposed block. I am unsure as to why Sav raised this discussion, but your proposal is unnecessary, in my view, because you are not yet ready to be unblocked by Stewards. As I stated below, this is a matter for Stewards, and neither one of us would unblock you unilaterally (at least I know I wouldn't). As well, we have yet to fully implement the restricted user group to revoke abuse filter editing or creating user rights, so from a technical perspective, any conditions of such a theoretical conditional unblock could not yet be implemented. But as I say, you have an active appeal in to Stewards, but we have not yet replied because we, or at least I think we, feel you're not yet ready to be unblocked. Why don't you go read a book, play a computer game, take an online course (your local public library likely offers free access to LinkedIn Learning for Libraries!), go for some hikes, and so forth, for at least three months. Do not touch testwiki.wiki, Miraheze, or English Wikipedia. Add their domains to your Windows Hosts file (Google that if you aren't sure what it is), pointed to 127.0.0.1 so you technically can't access them, then e-mail staff[at]testwiki.wiki only after at least three full months has elapsed. I,, Justarandomamerican, and many other users, I'm sure, want to help you, so this is the best advice I can offer. :) Dmehus (talk) 01:46, 8 May 2024 (UTC)

Discussion

• Due to previously filing one of these myself, I should not close this, and hence will leave a comment. There have been 2 previous discussions. The second resulted and later unblocking her, and the first resulted in implementing an abuse filter which attempted and failed to resolve the problem . I think it is time for the wider community to have a say in any future appeals, as this is either a very egregious case of not having necessary competence, or an attempt to troll and evade scrutiny. Therefore, I support a community ban/block, or, at the very least, an automatic community ban upon an unblock and reblock by a steward of the current block. Justarandomamerican (talk) 02:41, 6 May 2024 (UTC)

  Thank you for your input! Sav • ( Edits | Talk ) 03:52, 6 May 2024 (UTC)

• First, I'm curious as to what prompted you, Sav, to make this request for a 'community block'? Piccadilly is currently indefinitely blocked; they recently had attempted to contravene the indefinite block by created a an illegitimate sockpuppet account, which they promptly e-mailed Stewards about in good-faith. This shows continued capacity for learning. Separately, they have appealed their block, but, as Stewards, your elected non-test administrators and bureaucrats on this wiki, I believe I can say there is fairly good consensus that this is a not yet situation with respect to an unblock. Piccadilly has made some progress in terms of continuing to demonstrate, very modestly, capacity to learn, which is good, but it needs, I think, at least several more months before considering a provisional and conditional unblock. As well, technically speaking, we also need to put in place community-advised recommendations with respect to mechanisms to prevent editing restriction-restricted users from editing abuse filters. The community, last I checked, seemed to be leaning towards a restricted user group that revoked certain user rights related to editing or creating abuse filters.
• Secondly, I would also note that there is no official policy with respect to 'community blocks or bans'. It's good that you phrased this as a block, though, since bans aren't something we do here fundamentally because bans, by their very nature, aren't preventative. As well, we're not English Wikipedia; we're a low barrier test wiki, not a wiki with a bunch of policies or content here. We have to provide guidance to users who don't understand or comply with our policy-light testing wiki sometimes when required, of course, so as to maintain user harmony. As well, our community is quite a transient community. Users come and go, check in periodically, and spikes in activity from temporarily returning users occur. As such, this makes it exceptionally difficult to facilitate true due process with respect to indefinite blocks applied by the community.
• Thirdly, the community elects Stewards to make these decisions for them. If the community were to see fit to micro-manage every administrative decision, then what is the point of Stewards?
• That being said, that's not to say currently active members of the community cannot advise Stewards on the type of editing restrictions, blocks (partial or sitewide), or other types of restrictive measures and their duration, conditions for restriction removal, etc., etc., but the key is that it is advice. It is not binding as, ultimately, it is up to Stewards. With respect to Piccadilly, I don't believe it would be appropriate for a single Steward to unblock them unilaterally, and so I would personally commit to ensuring at least two Stewards agree, unconditionally, on any terms for unblocking, timing of unblocking, and any other preventative measures to put in place. Dmehus (talk) 01:30, 8 May 2024 (UTC)

  I believe what Sav intends here is to actually resolve the high level of controversy and back and forth that has gone down because of this one user. If we allow her to be ROPE unblocked repeatedly, as we have done in the past, and may do in the future, the disruption may continue. There is no concrete evidence of significant change, rather, we assume wrongly that any marginal change is enough to unblock. Clearly, to prevent further disruption, the community (and I see little issue with it being transient, so long as users are willing to review the case) needs to hear further appeals (which is what a ban would do in this instance). I am willing to help under reasonable conditions, but my main instinct is to prevent disruption at this time. Justarandomamerican (talk) 03:05, 8 May 2024 (UTC)

  I could not have said this better myself, Justarandomamerican. The ongoing back and forth with this user proves a conflict in opinions regarding the appropriate course of action.

  PSA for @Dmehus:, this request was discussed between myself and Justarandomamerican on Piccadilly's talk page. X was indirectly involved with this request. Sav • ( Edits | Talk ) 03:10, 8 May 2024 (UTC)

  I really would have to disagree with you on point #3, Dmehus. This is not a simple decision, it has been a continuous point of contention and issue for years on TestWiki. The community and stewards have seen many false promises and appeals over this time and it appeared that the stewards were going to listen to another appeal. I don't want to speak for Sav, but I can say that I was shocked to hear that an appeal was even being considered after the consistent disruption for years that Piccadilly has caused. Thus, I think enforcing a community block is a great option so that the stewards cannot unblock without consulting the broader community.  Support. X (talk + contribs) 12:46, 8 May 2024 (UTC)

  First of all, as a point of clarification, nothing in policy provides for the community to impose or mandate a block or ban, but Stewards will take into consideration from the community prior to unblocking. Secondly, as I've noted elsewhere in this discussion, part of the problem with respect to Piccadilly is test bureaucrats, such as yourself, proceeded immediately to a sitewide block earlier on rather than a rights revocation. Thirdly, perhaps I misspoke when I said the appeal was being currently considered; no, what I meant was that Piccadilly had an active but currently deferred appeal before Stewards. None of us were prepared to unblock at this point, and we wouldn't do so without agreement with other Stewards. Moreover, as I've said, we would seek the community's feedback through community discussion, but not simply a !vote (as we don't do that here), with respect to conditions for unblocking, minimum timeframe for unblocking, and what other parameters Stewards should impose. Dmehus (talk) 12:54, 8 May 2024 (UTC)

  Justarandomamerican and Sav, I'm not suggesting continuing to extend 'rope' indefinitely. The reality is, Piccadilly is blocked indefinitely, and currently has their user talk page access revoked as well. They know they have an appeal in to Stewards, but it isn't being considered now because they're not ready. We don't want to just keep unblocking and reblocking Piccadilly. That being said, I'm willing to consider that there have been a number of procedural mistakes with respect to Piccadilly (i.e., test bureaucrats and administrators blocking Piccadilly unnecessarily when they should've left sanction to Stewards, not putting in place technical mechanisms to revoke their ability to edit abuse filters, etc.). I'm also willing to consider Piccadilly's neurodiverse condition that causes them to act in an immature and, at time, gross manner in terms of type of edits, so they require technical measures to control that (when they're not blocked). Sav hasn't proposed anything here beyond the status quo (i.e., they're currently blocked indefinitely). I cannot understand what this discussion aims to accomplish. Stewards will and should continue to decline the appeal until we have both the technical measures in place and feel Piccadilly has demonstrated sufficient ability to operate within the minimal community norms of community. Dmehus (talk) 12:46, 8 May 2024 (UTC)

  I'm going to go out on a limb here and say that everything would be much simpler if we simply stuck to what we said before: "One chance and no appeals if conditions are at all broken." (They were broken) It would be extremely easy to just say we're never going to consider an appeal from Piccadilly ever again and leave it at that... X (talk + contribs) 12:56, 8 May 2024 (UTC)

  Simpler, maybe. But is it procedurally just and fair? No. So far, they haven't been able to go a month recently without contravening user accounts policy. Let's see if they can even go three months, okay? If not, you have my promise Stewards will keep blocking any sockpuppets as crosswiki or long-term abuse. :) Dmehus (talk) 12:59, 8 May 2024 (UTC)

  They've been given countless chances and appeals that were just and fair. Enough is enough. X (talk + contribs) 13:01, 8 May 2024 (UTC)

  We don't want to keep unblocking and reblocking Piccadilly Unfortunately, I believe the ship of expressing a desire not to has sailed. That is what has happened. If the majority of us can promise that community consensus will be required for an unblock, that's great, and is an alternative way of resolving this discussion's aim. I'd be fine with that resolution. Justarandomamerican (talk) 13:05, 8 May 2024 (UTC)

  I'm curious for your thoughts on simply not allow Piccadilly to ever appeal again, given you did make this comment. X (talk + contribs) 13:11, 8 May 2024 (UTC)

  I did not necessarily say that no appeals would be allowed. Rather, I extended rope. Even if community or steward consensus would be required for an unblock, reasonable appeals should be considered, except in the case where no reasonable person would be willing to accept the appeal. We are an open wiki, not a corporate community with irrevocable blacklists. Justarandomamerican (talk) 13:17, 8 May 2024 (UTC)

• So I see now that Sav just wants everyone to be on the same page in regard to this issue, which is understandable. How about the following proposal:

When the stewards feel I'm ready to be unblocked, which will most likely not be until at least August, they forward my appeal to the community, so they can all vote on it and can share any concerns or issues they may have with it? I'm willing to accept whatever is decided on by the stewards and community when that time comes, whether that means a full unblock, partial, or even no unblock. Piccadilly (My Contribs | My Messages) 12:01, 8 May 2024 (UTC)

That's the status quo. You're currently blocked indefinitely by Stewards. Given your past disruption, Stewards would likely seek feedback from the community with respect to minimum timeframe for an appeal to be considered and to the technical measures that need to be put in place as well as conditions of such an unblock. Dmehus (talk) 12:48, 8 May 2024 (UTC)