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:Kiteretsu/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.
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?.
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)
It happened to me too! Well, I am already an administrator, but not for 4 days! On the one hand, this guideline is a hindrance for serious users, but what if they are just spammers? Or something similar? One can trust me, but others... Justman10000 (talk) 11:21, 29 May 2024 (UTC)
You can always ping Stewards to make an exception for yourself. See the list of stewards to know who to ping The AP (talk) 13:02, 29 May 2024 (UTC)
I have already said that the user can start requesting crat rights in three days. It seems best to keep it that way. Drummingman (talk) 13:10, 29 May 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)~
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)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Done After 2 weeks and with 3 votes in favour and 1 in opposition and no comments by any other users even after pinging I am closing this discussion as successful Harvici (talk) 13:37, 12 May 2024 (UTC)
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: 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)
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 anadministrator 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)
Comment: It has been 2 weeks since the start of the discussion, and there are 3 votes in support and 1 in opposition. I wouldn't close this discussion today and wait for 24 hours more to see if anyone else wants to opine and also suggest others do the same.The following users were active in the month of May (5TH May) so pinging them if they want to opine: @Aviram7,Drummingman, C1K98V,Codename Noreste , DodoMan , Sav ,WüstenspringmausHarvici (talk) 14:05, 10 May 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Omnibus RfC: Unbundling abusefilter permissions from Administrators
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Closing. The first proposal has no consensus, and the second passes. Though there were alternates to the alternate proposal, they failed to gain sufficient consensus. I believe this is an action any reasonable Steward would take. Justarandomamerican (talk) 20:43, 19 May 2024 (UTC)
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.
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)
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)
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)
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)
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)
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)
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Umm....
I have another 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)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I have now been asked to review and close this request. Given people’s opinions, it seem like the consensus is for the indefinite block to remain standing. Per standard procedure, Piccadilly may appeal after six months. MacFan4000(TalkContribs) 13:52, 12 May 2024 (UTC)
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.wikionly 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 assumewrongly 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.
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)
There is no such thing as a 'permanent ban or block', on any mainstream, reputable wiki. I think a core part of the problem, aside from blocks by test bureaucrats early on that should've been left to Stewards, is that we haven't allowed a sufficient length of time to pass before assessing Piccadilly's capacity to heed instruction from Stewards, together with the community's advice. If you (or Sav) would like to have a constructive discussion on that timeframe is, I think that would be a productive discussion to have and I'm happy to have it. I think it's obviously longer than a month. Should it be three months, six months, or a year? Keep in mind, they haven't been able to go a month in recent months. And, what is your reason for choosing that timeframe? Dmehus (talk) 13:40, 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)
Maybe when the stewards forward my appeal to the community, we could include the condition that if I get blocked again, it will be almost guaranteed that no one would agree to unblock me if I were to get into trouble here again. Piccadilly (My Contribs | My Messages) 13:20, 8 May 2024 (UTC)
Almost guarantees haven't proven effective before. X (talk + contribs) 13:23, 8 May 2024 (UTC)
As a community-advised, Steward-imposed block, that would effectively be what we would do. It wouldn't be an up-or-down !vote, but rather, a series of questions asking the community's input on minimum timeframe before unblocking, conditions to be imposed by Stewards upon a conditional unblocking, and what penalties shall occur based on the level of infraction. I think, fundamentally, if the community is able to advise on minimum timeframe away from Test Wiki, that would satisfy all concerned. At the end of the day, time often heals all wounds (apologies for the cliché!) Dmehus (talk) 13:44, 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's 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)
So as I understand this discussion currently, it seems the ideal option right now is to agree on a minimum length of time before my appeal is forwarded to the community for consideration. That's fine with me, and I won't make any more evasion accounts or use IPs here any more. Piccadilly (My Contribs | My Messages) 20:33, 8 May 2024 (UTC)
If I were to say away from here for 3 months, until August, would that be long enough? Piccadilly (My Contribs | My Messages) 16:53, 9 May 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Question
Is thanking a user for an action related to right management considered a logged action? Harvici (talk) 12:44, 9 May 2024 (UTC)
Hey everyone I recently created a new template "Failed policy" which I moved from my user subpage to the template namespace.This template mainly uses the code already available on English Wikipidea. I think it is uncontroversial, but if you have any suggestions or concerns, please let me know. Harvici (talk) 16:39, 9 May 2024 (UTC)
I created this template mainly for this policy which clearly failed but the recent nominations of policies like crat policy and abuse-filter policy was also the reason for creation of the template :) Harvici (talk) 16:41, 9 May 2024 (UTC)
Permission revocation request and block request
Can anyone block me (until 5:00 UTC, May 12, 2024) as I have something important coming up and don't want to be distracted and kindly remove my permissions as well Harvici (talk) 15:36, 10 May 2024 (UTC)
So,it’s no sending the mail to my email adress.Help.DodoMan (talk) 16:50, 11 May 2024 (UTC)
@MacFan4000: I also noticed the feed of recent activity on the homepage wasn't working, so multiple issues seem to be occurring. Justarandomamerican (talk) 14:02, 12 May 2024 (UTC)
It's working again! Jody (talk) 02:07, 14 May 2024 (UTC)
Request for NSS: Aviram7
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I Withdraw this request for NSS. thank you to everyone to participated in this request.
Link to your account in other projects, e.g. Wikimedia, Miraheze, Fandom (optional): Wikipedia:User:Aviram7
[yes] I am familiar with all of Test Wiki's policies and agree to follow them completely.
[yes] I agree that I am entirely responsible for all actions done under this account, including actions performed under this account by someone other than myself.
[yes] I agree that if I misuse the tools, my access might be revoked and I may be banned from Test Wiki without prior warning.
Other comments: Hi! I like to help out to as NSS on test wiki and I'm willing to help with suppression when needed, and I am available/24/7 for help on testwiki or discord and I have read Test Wiki:Suppressors, and the privacy policy. Thanks ~~ αvírαm|(tαlk) 07:54, 13 May 2024 (UTC)
As I mentioned in previous requests, we don't need a new suppressor at the moment. There are already 5 stewards and 2 suppressors active on the wiki (7 in total), so I see no reason to become a suppressor. OpposeLisafBia (talk) 08:06, 13 May 2024 (UTC)
@LisafBia: Hello and Thank for making you're important comment on her and if a new NSS users are like to helping out to other NSS users and stewards; I like to help if i getting a chanced, I've 24/7 active on here. ~~ αvírαm|(tαlk)
I am not a steward but I propose to grant the status for one week like my admin interface status.DodoMan (talk) 15:41, 13 May 2024 (UTC)
Oppose Even though there is a need for a NSS (EPIC isn't really active), I think you are relatively new to the Test Wiki and don't hold advanced positions like Sysop or Crat at other wikis (wikis that are not test wikis). Harvici (talk) 16:36, 13 May 2024 (UTC)
Oppose Per Harvici and LisafBia. Jody (talk) 02:07, 14 May 2024 (UTC)
Neutral. Per Harvici and LisafBia. I know Aviram7 is a trusted and active user, but I think we've enough NSS. Wüstenspringmaustalk 06:35, 14 May 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
A newsletter?
What do you all think about creating a newsletter that tells you what changes have been made in terms of policies and technical changes and how many new users have been given crat and sysop rights (technically Wikipidea's administrator Newsletter)? Harvici (talk) 16:34, 13 May 2024 (UTC)
Support. I think, that would be a good idea. Wüstenspringmaustalk 06:24, 14 May 2024 (UTC)
Question
Is the "pywikibot" directory uploaded to the server? Harvici (talk) 15:40, 14 May 2024 (UTC)
And is it possible to get shell access? Harvici (talk) 15:44, 14 May 2024 (UTC)
Link to your account in other projects, e.g. Wikimedia, Miraheze, Fandom (optional):
[Yes] I am familiar with all of Test Wiki's policies and agree to follow them completely.
[Yes] I agree that I am entirely responsible for all actions done under this account, including actions performed under this account by someone other than myself.
[Yes] I agree that if I misuse the tools, my access might be revoked and I may be banned from Test Wiki without prior warning.
Other comments:I am requesting this right to import few gadgets from other wikis and write some gadgets on own.I have experience in Java,Python, a little bit of CSS, and some in JS. I am also testing a bot, which I will include to TestWiki on successful runs, as well as writing scripts for a bot on discord with DodoManHarvici (talk) 17:22, 16 May 2024 (UTC)
I can confirm Harvici have the competence for this role.He is dev with me a discord bot to possibly be deployed on the wiki test discord.DodoMan (talk) 17:26, 16 May 2024 (UTC)
Recently Aviram7 granted bureaucrat rights to his friend Rohit, but I removed it as it was a violation of the bureaucrat policy.Aviram7 is a trusted user with advanced rights like IA, and since he knew Rohit personally , I don't think there would be any disruption. Currently, the policy states that a Steward may exempt a user they deem trustworthy from the above requirements and I propose that it should be changed to A steward or a bureaucrat, as applicable, may exempt a user they deem trustworthy from the above requirements.Harvici (talk) 17:51, 18 May 2024 (UTC)
No, I believe it's suitable staying as it is. Sav • ( Edits | Talk ) 21:34, 19 May 2024 (UTC)
There are 4 stewards. Ping us to request an exemption. Justarandomamerican (talk) 21:41, 19 May 2024 (UTC)
@Justarandomamerican and TheAstorPastor: Hello there, I think it's need to change exemption, so, I request to you please change exemption. Thanks ~~ αvírαm|(tαlk) 02:39, 20 May 2024 (UTC)
You have your answer. Justa stated if you need someone exempted, ping a Steward. The policy won't be changed. Sav • ( Edits | Talk ) 11:01, 20 May 2024 (UTC)
Thank you for this information, so, I no need to request for exemption in crat's policy. ~~ αvírαm|(tαlk) 11:32, 20 May 2024 (UTC)
If you want to request an exemption, you need to ping a Steward, as I have already said. Sav • ( Edits | Talk ) 15:57, 20 May 2024 (UTC)
Rename request
Can my name be changed to "TheAstorPastor" as I adopted this name at Wikimedia projects and I plan to do so at Miraheze and similarly Harvicibot to APBOT Harvici (talk) 17:54, 18 May 2024 (UTC)
Also done now :). Drummingman (talk) 15:19, 20 May 2024 (UTC)
Thank you very much! The AP (talk) 17:06, 20 May 2024 (UTC)
Codename Noreste
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Done - Codename Noreste is trusted with abuse filter editing. The only objection is whether the user would be sufficiently active, but if the user remains sufficiently active it is not an objection. In short, there is consensus to grant Abuse filter administrator. Drummingman (talk) 14:57, 28 May 2024 (UTC)
Link to your account in other projects, e.g. Wikimedia, Miraheze, Fandom (optional): My Wikipedia user page
[Yes] I am familiar with all of Test Wiki's policies and agree to follow them completely.
[Yes] I agree that I am entirely responsible for all actions done under this account, including actions performed under this account by someone other than myself.
[Yes] I agree that if I misuse the tools, my access might be revoked and I may be banned from Test Wiki without prior warning.
Other comments: Hello, everyone. I have been creating and modifying abuse filters for quite some time now, and I would like to apply for the abuse filter administrator right to assist in doing non-controversial changes (such as cleaning up unnecessary syntax) to filters that use restricted actions such as blocking, and to enable such actions to existing filters only when there's consensus to do so on the community portal. I understand that misusing this very high-trust permission may lead to revocation with or without warning, and outside of Test Wiki, I assist with abuse filters on some Wikimedia projects. Thank you. Codename Noreste 🤔 La Suma 04:32, 20 May 2024 (UTC)
Comment: You should be a bit more active and make some more filter changes so that I know you know about the abuse filter. Thanks. LisafBia (talk) 08:31, 20 May 2024 (UTC)
Weakest oppose I know that you have experience with abusefilters here and on other wikis but I am only concerned about your activity levels, like in recent talk page messages to which you haven't responded The AP (talk) 10:34, 20 May 2024 (UTC)
Support I know that @Codename Noreste has a fair amount of experience with the abuse filter tool, but his ability to work here on a regular basis is not very high; if he promises that he will work on the test wiki regularly, but I guess I'd be happy to see how he works with the abuse filter here, then he might be granted abuse-filter admin permission for a limited time. ~~ αvírαm|(tαlk) 11:29, 20 May 2024 (UTC)
Support. One of our most trusted filter editors. The permission can be revoked if not actively used. Justarandomamerican (talk) 23:07, 20 May 2024 (UTC)
Support Per Justarandomamerican. Gepardtalk 10:27, 28 May 2024 (UTC)
I think a week has passed, would an uninvolved steward close this please? Thank you. Codename Noreste 🤔 La Suma 03:43, 28 May 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Internal error
Hello guys, when you open Newsletter:Administrators' newsletter you will notice an internal error is displayed, Does any one know about this or maybe it is an error developed during the addition of abusefilter groups to LocalSettings.php? The AP (talk) 05:31, 20 May 2024 (UTC)
Very strange. Unfortunately I'm not sure that I can fix it, I'm not seeing anything obvious. MacFan4000(TalkContribs) 17:17, 20 May 2024 (UTC)
@MacFan4000 I think there is some issue with content serialization.Just check if the Extension:Newsletter is upto date, and if possible, to get more insight to errors, please add the following lines to LocalSettings.php to enable detailed debugging
$wgShowExceptionDetails = true;
$wgShowSQLErrors = true;
$wgDebugDumpSql = true;
$wgDebugLogFile = "/path/to/debug.log"; The AP (talk) 12:32, 21 May 2024 (UTC)
Suggestions to the abuse filter administrator role and revocation criteria
Since the abuse filter administrator role has so many rights that administrators and stewards already have but the abusefilter-modify-restricted, I suggest we remove every right from that role but keep the abusefilter-modify-restricted right. I would also suggest the following to include the revocation criteria:
Has a pattern of activating restricted actions without first determining consensus
The abuse filter administrator fails to exercise sufficient care when creating or modifying filters with restricted actions, resulting in innocent users being blocked or their autoconfirmed rights revoked
Any suggestions in addition to my criteria addition, as well as making the abuse filter page an official policy? Thank you. Codename Noreste 🤔 La Suma 04:42, 21 May 2024 (UTC)
I am supportive of those revocation criteria being applied in a reviewable manner by individual Stewards. However, I would like to suggest that more information be added to the page before it becomes an official policy/guideline. Justarandomamerican (talk) 01:38, 26 May 2024 (UTC)
I think we could let the AFA vote go on for at least a week. Codename Noreste 🤔 La Suma 18:16, 26 May 2024 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
@MacFan4000: I would want to say that LisafBia, the two stewards (Drummingman and Justarandomamerican), and I, indicate that I voted, and all votes are oppose (formerly my vote was a neutral, but changed to oppose regarding most people's concerns). MacFan4000, you may have to close as unsuccessful. @Justman10000: If you have any further questions regarding this or want to vote on yourself, please state your questions below the votes in the "Questions by the candidate" section or take place of your vote here before MacFan4000 is closing it. Tailsultimatefan3891 (talk) 20:26, 2 June 2024 (UTC)
I would like to be a system administrator so that I can also support at system configuration level... In addition to managing permissions, I would also keep the software, extensions and skins up to date and optimise the configurations!
It would be really nice to get a chance 🙂 Justman10000 (talk) 16:28, 2 June 2024 (UTC)
Did you know how to use Git, PHP, and SSH, and you are active on this wiki? Please see Project:System administrators. Also, it would be really nice for you to be a system administrator if you know understanding of Apache and a server (MariaDB/MySQL/PostgreSQL/SQLite). Tailsultimatefan3891 (talk) 17:00, 2 June 2024 (UTC)
I already work with Linux Debian since 4 years! So yes 🙂 Justman10000 (talk) 17:03, 2 June 2024 (UTC)
Are you aware that this very high trust permission can cause great damage if it's improperly used? Codename Noreste 🤔 La Suma 17:05, 2 June 2024 (UTC)
I am aware of this! Yes Justman10000 (talk) 17:16, 2 June 2024 (UTC)
So, voting by the two stewards and by some users is required. If the votes are successful, then it goes to the system administrator to grant the permission or not. Tailsultimatefan3891 (talk) 17:20, 2 June 2024 (UTC)
The votes are all oppose that it is likely to be unsuccessful. Tailsultimatefan3891 (talk) 20:41, 2 June 2024 (UTC) (sorry for the late signing)
Voting
Support
Oppose
Weak Oppose Hi, thanks for volunteering. Unfortunately, I must weakly oppose your request at this time due to lack of necessary trust or track record. I do not think you would take the site down, abuse your power in some other way, or go inactive suddenly, but you do not hold Stewardship here or administratorship elsewhere, and you don't have that long of a track record, so I cannot be sure. Consider this a moral support of sorts; I have no objection to another run in the medium-term future. Justarandomamerican (talk) 17:32, 2 June 2024 (UTC)
Like I said, I'd be happy to get a chance, and if you don't think I would abuse my power (which I wouldn't too), then what's the problem? Justman10000 (talk) 17:44, 2 June 2024 (UTC)
This permission is very powerful, can lock the database and have access to PHP, SSH, Git, and Github and even Apache and the server (MariaDB/MySQL/PostgreSQL/SQLite). Tailsultimatefan3891 (talk) 17:47, 2 June 2024 (UTC)
System administratorship is a very powerful position. I prefer to err on the side of caution. Can you describe your previous experience with FiveM and Minecraft servers? Do you have PHP experience? Justarandomamerican (talk) 17:48, 2 June 2024 (UTC)
For the networks, I installed and configured web applications and Minecraft plugins Justman10000 (talk) 17:52, 2 June 2024 (UTC)
Please refer to the following questions:
Do you have PHP experience?
Do you have SSH experience?
Do you have Git/Github experience?
To make it easier, it is recommended to use MariaDB, MySQL, SQLite, or PostgreSQL server and use Apache. Do you have experience and understanding of that?
Oppose Hi, nice that you signed up and want to get more involved, I can only appreciate that. But unfortunately, here and for this reason, I want to cast my dissenting vote. I am very reluctant to assign this role to someone I don't know well. Anyway, are you already a system administrator, steward or admin on a major wiki project somewhere? On a Wikimedia, Miraheze or other large wikifarm. On these wikis, you become one only after a thorough review and vote. To me, that is a hard requirement for a system administrator. SA has the unlimited power to shut down an entire wiki (database lock and unlock) block anyone and deny or grant anyone user rights. Therefore, this right can only be granted to highly trusted users. Of course, this is separate from the technical side, which is also important. Drummingman (talk) 17:48, 2 June 2024 (UTC)
Of course, yes, I agree. I absolutely vote and agree on Oppose but I gave the very strong oppose, biggest, strongest, ever. Tailsultimatefan3891 (talk) 01:13, 3 June 2024 (UTC)
Strongly oppose It doesn't make much sense to give a user who has been a member for less than 1 month a higher level of authority than even the stewards such as the system administrator. You need to have 3 or more months of activity history. LisafBia (talk) 18:14, 2 June 2024 (UTC)
Nowhere does it say anything about that... So... And is it so difficult to give someone a chance? It's not really motivating Justman10000 (talk) 18:25, 2 June 2024 (UTC)
See what the text LisafBia and the 2 stewards said, plus the vote from me right below. Not satisfying and broken trust. Tailsultimatefan3891 (talk) 20:31, 2 June 2024 (UTC)
Strongly, very strong, extreme, intense, super, mega, kilo, peta, peta, tera, tera, mega, mega, very strong, strongly, bigger, longer, and absolute oppose that is the biggest, longest, and strongest oppose that I will ever give Seriously?!? This user has no long history, new to this wiki, despite knowing PHP, SSH, and Git and needs more experience with Apache and a server (PostgreSQL, MariaDB, MySQL, SQLite). System administrator is a very powerful right, even more than interface administrator and especially intended to be more powerful than regular stewards, including grant or revocate anyone user rights, disable OAuth for a user, locking the database and have access to PHP, site-sensitive files, SSH, and Git as well as the server such as MySQL, MariaDB, PostgreSQL, and SQLite and Apache. They'll have access to DefaultSettings.php, LocalSettings.php, and NoLocalSettings.php. This right is extremely powerful. I hope this will be absolutely rejected. You'll hear no complaints from me. Tailsultimatefan3891 (talk) 20:21, 2 June 2024 (UTC)
Strong oppose per Drummingman and Justarandomamerican; Justaman10000 joined on test wiki sice 28 May 2024 (7 days) and I don't think they are really eligible for system administrator privileges for at this time and I don't think they are currently fulfill system admin's requirements. Happy testing ~~ínfínítу • [@píng mє] 03:38, 3 June 2024 (UTC)
Do I speak Turkish when I say it would be nice to get a Chance? Justman10000 (talk) 14:06, 3 June 2024 (UTC)
Hey there, now you aren't being nice.Just to be clear and make you familiar with the community, the steward/system administrator is equivalent to a sysop, crat, or steward on Wikimedia or on big Wiki farms like Miraheze.You can't just go on those wikis and, in 7 days, request advanced rights.You need to build up a proper reputation here. In addition to it being a test wiki, we limit the testing rights to Sysop and Crat Bit.So I think you should try to spend more time here. :) The AP (talk) 14:39, 3 June 2024 (UTC)
@Justman10000: No! You are didn't talk me in Turkish languages but you have joined 7 days ago before on Test Wiki, so, I don't think now you're eligible for system administrator privileges because this permission is very high level trusted privileges on in test wiki and I don't seem you're demonstrated with SSL, php and MariaDB, MySQL, SQLite, or PostgreSQL server and use Apache and others, I suggest to you please spent a long time (1 year or 3 years) on test wiki; I think you try to Hat collecting on here, so, I fully Strong oppose for this permission. Happy testing ~~ínfínítу • [@píng mє] 15:25, 3 June 2024 (UTC)
Neutral
Neutral Used Linux Debian and may be trusted, but I don't know if completely trusted.Tailsultimatefan3891 (talk) 17:21, 2 June 2024 (UTC)
I would be! I have already system-administered around 20 Minecraft and FiveM networks! Sure, this has nothing to do with MediaWiki itself, but it's about the principle! As I said, I would be happy to get a chance Justman10000 (talk) 17:45, 2 June 2024 (UTC)
Possibly some enhanced trust would be needed. Try to think when you become a system administrator. Tailsultimatefan3891 (talk) 17:47, 2 June 2024 (UTC)
What is actually so damn hard to understand about the sentence, It would be really nice to get a chance? If you're only ever rejected, there comes a day when you don't want to do anything anywhere! Just give it a damn chance and let someone prove themselves... Is that so hard?
It is the unlimited power, yes! But that way I could have proved myself directly! It's extremely unmotivating to first have to do what I know how many weeks or even months of preparatory work, only to probably be rejected again! --Justman10000 (talk) 05:06, 3 June 2024 (UTC)
Hey there, I understand that it may be frustrating to you that you aren't getting a chance to be a system administrator, but this isn't the case for you alone. @Justarandomamerican had his request for stewardship denied once and withdrawn also.@LisafBia also had their request denied.I suggest you mingle with the community and try to spend more time here.Then, if you gain a fair position in the community, I will nominate you myself. The AP (talk) 06:31, 3 June 2024 (UTC)
Questions for the candidate
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Request for System administratorship
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Hello. I've been a Steward for around a solid year. I've also been involved in the behind the scenes technical stuff such as Phorge/Phabricator and GitHub for a while, writing requests and pull requests. I have basic technical knowledge as described in Test Wiki:System administrators. I think having an extra system administrator would speed things along on Phabricator, along with ensuring that there's a backup when MacFan4000 is busy. Feel free to ask any questions. Justarandomamerican (talk) 16:10, 8 June 2024 (UTC)
Questions for the candidate
Support
Support - You have been a steward with us for almost 1 year. This has given you the confidence to handle sensitive matters. You have also shown yourself to be a good steward. After all, we really need more System Administrators. Drummingman (talk) 16:30, 8 June 2024 (UTC)
Support per Drummingman Gepardtalk 16:50, 8 June 2024 (UTC)
Support Trusted user. I wish the candidate luck with MediaWiki and other technical tools. LisafBia (talk) 17:00, 8 June 2024 (UTC)
Support with no objections to you becoming a brand new system administrator. As you've been highly trusted for mostly a year, we wish you good luck having another very high-trust role here. Codename Noreste 🤔 Talk 17:49, 8 June 2024 (UTC)
Support no concerns, trusted User with stewards privileges.---Infínítybσy7 • [@píng mє] 03:20, 9 June 2024 (UTC)
Support - Fine by me! With the please that my PRs are better considered --Justman10000 (talk) 09:27, 9 June 2024 (UTC)
Support No concerns or complaints from this user, trusted user with Steward, bureaucrat, admin, and interface administrator privileges. As you have been a long-term legitimate user with being a Steward for at least an entire year, we wish you very good lock having you here as an extremely strong-trust role here. It's great if you know PHP, SSH, and Git (and to be even more trusted, Apache, Github, Phabricator, Linux Debian, MySQL, MariaDB, PostgreSQL, and/or SQLite), and you are so active here plus a trusted Steward. Tailsultimatefan3891talkcontribs 14:48, 9 June 2024 (UTC)
Support Looks good to me. DR (talk) 13:50, 11 June 2024 (UTC)
Support Trusted user The AP (talk) 06:21, 13 June 2024 (UTC)
Oppose
Neutral/abstain
Discussion
Oh, but I'm not allowed to be? Interesting... And if you get it, me too one day, then that would be three (if not more)... Justman10000 (talk) 16:13, 8 June 2024 (UTC)
I'm sure you can become one someday. Right now, it's your track record here on Test Wiki people are worried about, because you haven't been on here for all that long. All of our Stewards have had months to years of history here before becoming stewards, and there are no current non-founder sysadmins. I'd even encourage you to apply in the medium to long term future. We could use your help, but the community does not think you should be one right now. Justarandomamerican (talk) 16:18, 8 June 2024 (UTC)
I'm just afraid that too much could exist if I want to nominate myself for the second time! Justman10000 (talk) 21:55, 8 June 2024 (UTC)
I became a steward on my third request. When I put out a call for system administrators, there were no candidates. I doubt there will be too many system administrators by the time you try again. Justarandomamerican (talk) 22:08, 8 June 2024 (UTC)
Do you know enough about MediaWiki software and SQL? If yes, how will you use this knowledge? Thanks for your help. LisafBia (talk) 16:35, 8 June 2024 (UTC)
MediaWiki: Yes, I've been involved in various small projects, and so have enough knowledge to, for example, install extensions, manage them, and change configuration settings.
SQL: I have only a bit of prior knowledge of SQL (again, from the various small projects), but can probably figure out how to, for example, change namespaces DB side as required by T71 or remove protection as required by T60. Justarandomamerican (talk) 16:46, 8 June 2024 (UTC)
@Justarandomamerican: do you also intend to help with creating and modifying user groups? One example would be that admins can modify filters by default, and abuse filter admins (like me) and stewards can modify filters with restricted actions, as well as the ability to enable these actions. Thus, the AFA user right should only have one right, which is abusefilter-modify-restricted. Codename Noreste 🤔 Talk 17:41, 8 June 2024 (UTC)
Yes, I do intend to help out with that, and would be happy to remove redundant rights as required. Justarandomamerican (talk) 17:42, 8 June 2024 (UTC)
Just out of curiosity and if possible, can you provide the link of the projects you worked on The AP (talk) 06:21, 13 June 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Inactivity bot
Think about writing one! Should they revoke the permissions directly, or just notify? Justman10000 (talk) 16:18, 8 June 2024 (UTC)
I'd say it should send notifications to the community portal at first, and upon demonstrating it works, have it make rights temporary when the user will be considered inactive in 2 weeks. Justarandomamerican (talk) 16:23, 8 June 2024 (UTC)
Systemadminstrator... or steward?
When would one be willing to accept me as a system administrator? I would be extremely unhappy to have to work for many months, a year or more! And would I have to become a steward first? Or could I be nominated and elected directly as a system administrator! Actually, the work itself says something about someone! Not the duration of the work Justman10000 (talk) 18:10, 8 June 2024 (UTC)
This is probably due to your account age, and please do not take this for granted, but your suitability to those high-trust roles (non-test roles) are what might concern me. Codename Noreste 🤔 Talk 18:46, 8 June 2024 (UTC)
Why? I mean, rejecting someone just because their account is too young... Actions are what define one, not the duration of one's collaboration Justman10000 (talk) 18:55, 8 June 2024 (UTC)
System administrators can shut down the wiki at any time they please. They can also make decisions such as amending the privacy policy or blocking entire IP addresses from even being able to access the site. For this reason, the community wants to see quality and quantity of contributions from prospective system administrators. The same goes for prospective members of any non-test role that can make major decisions, such as AFAs and Stewards. Justarandomamerican (talk) 19:01, 8 June 2024 (UTC)
And how old should an account be? Justman10000 (talk) 18:55, 8 June 2024 (UTC)
Anywhere between 8 months to a year at least. Codename Noreste 🤔 Talk 19:06, 8 June 2024 (UTC)
How did you come up with exactly 8? Could be only 6 or 5 too Justman10000 (talk) 22:03, 8 June 2024 (UTC)
So, how about this, I recommend you have between 7 and 12 months of activity at least and know how to use PHP, Git, and SSH, and also recommend getting a Github account and sign in to it. If you don't have a Github account, you can register a Github account. I would also recommend to be active on the Wiki and be an administrator or bureaucrat and suggest for the best experience before system administrator, I would at least recommend requesting Steward permissions and also get a server from Linux Debian, MySQL, MariaDB, PostgreSQL, or SQLite and have an understanding of it. To be a Steward you can have at least 5 or 6 months of activity at least. I suggest you also have an understanding of Apache HTTP Server. Please read and heed any advice you need. Thanks. Tailsultimatefan3891talkcontribs 14:45, 9 June 2024 (UTC)
As I said, I've been working with Linux Debian for over 4 years! So I'm already familiar with everything mentioned! I've also had a GitHub account for years!
And do I have to wait the 7-12 months AFTER my successful election as a steward, or just add the rest from the 4-5 months after the steward election? Justman10000 (talk) 15:55, 9 June 2024 (UTC)
I'm sorry, you just joined late. In addition, I should say that you are too new there for Steward or System Administrator privileges. However, according to ChatGPT:
"Yes, MediaWiki supports Linux Debian Server. MediaWiki, the software that powers Wikipedia, is designed to run on a variety of operating systems, including Linux. Debian, a popular Linux distribution, is well-suited for running MediaWiki due to its stability, security, and robust package management system."
It is OK to use Linux Debian there on MediaWiki, but learn how to use Git, PHP, and SSH and also be active on this wiki. Please read and heed any advice. Thanks. Tailsultimatefan3891talkcontribs 20:38, 9 June 2024 (UTC)
I know that MediaWiki also runs on Linux Debian? Huh? You indicated yourself that test wiki runs on a Linux Debian machine? And as I said, I already understand all mentioned Justman10000 (talk) 06:34, 10 June 2024 (UTC)
Well, yep. Kinda so, according to ChatGPT. Just wait a few months and be active enough to become system administrator. You know? I'm not a system administrator either! Tailsultimatefan3891talkcontribs 20:11, 10 June 2024 (UTC)
But I am sorry, Justman10000, this is a high trust role. Try again next time... Tailsultimatefan3891talkcontribs 20:12, 10 June 2024 (UTC)
I don't want to say that, but somehow... you're playing yourself up Justman10000 (talk) 08:12, 11 June 2024 (UTC)
It's real, not fake. And for true, only 1 is currently system administrator. However, this makes no flexibility for a regular steward to be flexible with a user that jumped from being a non-steward to a system administrator. Tailsultimatefan3891talkcontribs 12:44, 11 June 2024 (UTC)
I'd like to clarify that this is a test wiki, which means that anyone can experiment with MediaWiki functionality here. Within this space, users can request various permissions except for sys admin and steward, specifically for testing purposes. Sys admin and steward rights are crucial for the smooth operation of this wiki and are not intended for testing purposes. Steward rights are granted to users who invest significant time here, and the community trusts their judgment for sensitive actions. Similarly, the system admin right is not given out for testing; it's essential for maintaining the wiki's smooth functioning. At the moment, we have one sys admin diligently fulfilling their duties. Should the need arise, the community or founder can nominate trusted and technically proficient users to take up the sys admin role. I hope this clarifies things. DR (talk) 13:37, 11 June 2024 (UTC)
Yes, this is correct, as gaining sysop and bureaucrat rights and being active for the wiki is the minimum for Steward or System Administrator rights, with additional System Administrators requiring know how to use PHP, Git, SSH, recommended MySQL, MariaDB, Linux Debian, SQLite, PostgreSQL, Apache, Github, and Phabricator and gaining Steward rights. Tailsultimatefan3891talkcontribs 13:46, 11 June 2024 (UTC)
Nothing I didn't already know Justman10000 (talk) 14:16, 11 June 2024 (UTC)
What does that have to do with my comment? Justman10000 (talk) 14:16, 11 June 2024 (UTC)
I still have no idea what you're talking about Justman10000 (talk) 16:35, 20 June 2024 (UTC)
@Justman10000: Here's the deal, you may have at least 7 months of activity and be active on this wiki to meet this criteria. You already meet other criteria, but I recommend yourself being a steward first. Tailsultimatefan3891talklogscontribs 17:31, 24 June 2024 (UTC)
Nominating Drummingman for system adminship
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Not done due to candidate non-acceptance. Justarandomamerican (talk) 21:22, 10 June 2024 (UTC)
I would like to nominate Drummingman because he's a trusted user with no concerns and he's here being a Steward for a little more than a year and active on this wiki. So what do you think of my nominal? Tailsultimatefan3891talkcontribs 20:43, 10 June 2024 (UTC)
Dear @Tailsultimatefan3891 thanks for your nomination, I can certainly appreciate it. But I have absolutely no ambition to become a System administrator. Therefore, I do not accept the nomination. Greetings, Drummingman (talk) 21:20, 10 June 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Wiki changes to propose upcoming
In the next few days somehow, I will post a bulk inserting of wiki changes here on the community portal. Tailsultimatefan3891talklogscontribs 00:26, 14 June 2024 (UTC)
Help to make an icon
Can anyone make a user icon for system administrator? As I am not good in that stuff and I need the icon to be added to the newsletters, I'm pinging @Codename Noreste as he previously updated some icons The AP (talk) 14:59, 20 June 2024 (UTC)
I joined the Discord yesterday but couldn't verify (see image). Could someone take a look? Thanks. '''[[User:CanonNi]]''' (talk • contribs) 03:54, 26 June 2024 (UTC)
Wait a little bit or try to refresh (especially if taking indefinitely long), if still not working, check your Discord settings, and then try to refresh again, if not repeat this cycle until you believe the Discord settings are correct, then if it still happens, check your browser settings and refresh, repeat this cycle, if it is not clear your cache, and if still not working try to restart your computer Tailsultimatefan3891talklogscontribs 14:29, 26 June 2024 (UTC)
It is already fixed by me. Greetings Drummingman (talk) 19:47, 26 June 2024 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I think it's fair to say that there is consensus for implementing this extension, due to the only negative argument being rebutted without response. I'll go ahead and implement this. Justarandomamerican (talk) 01:03, 6 July 2024 (UTC)
Justarandomamerican recently closed a task that intended to add Extension:NewUserMessage which would add a message to the talk pages of newly created accounts.The reason for closure was that he needed to see community consensus. Please note down your vote in suitable sections The AP (talk) 17:38, 28 June 2024 (UTC)
Support
Support I don't see any concerns about adding the Extension The AP (talk) 17:38, 28 June 2024 (UTC)
Support We pretty much welcome all new users anyway, might as well automate it. X (talk + contribs) 19:16, 28 June 2024 (UTC)
Support I think an automation is necessary to welcome new users and I support the extension because I requested it. LisafBia (talk) 19:48, 28 June 2024 (UTC)
Oppose Honestly, this extension should NOT be implemented. To all of the users who will register when this bot is in operation will have their talk pages created automatically by this extension's bot with the standard {{welcome}} template and signature. Who knows who the bot welcomes and what those users' intentions will be? Most of those users will not deserve a welcome on their talk pages because they'll be users who will never make a single contribution here, so what's the point in welcoming users like them? This includes the future spam-bots and vandals of course. I view what the bot will do as spam and excessive clogging to the User talk: namespace. I prefer that we, this time, stick to welcoming new users on our own, to the ones who'll register and actually make their first constructive edits, or other ways from them that show their deserving of these welcomes. Tsukushi (talk) 08:00, 29 June 2024 (UTC)
I would disagree. This Wiki is small and there are very little new users (only 13 accounts were registered last month). Even if certain users use their accounts for malicious purposes, they are easily blockable because, remember, almost everyone is an admin here. And if the extension does cause problems, it can be easily disabled. '''[[User:CanonNi]]''' (talk • contribs) 11:41, 29 June 2024 (UTC)
Furthermore, welcoming people and giving them quick links to request rights is helpful to new users that aren’t familiar with the layout of the wiki. There isn’t always someone online that will welcome them. X (talk + contribs) 01:30, 30 June 2024 (UTC)
Neutral per Tsukushi pretty much Tsukushi may be true but I arguably think that a bot may welcome new users or someone would like to use a different Welcome template. Tailsultimatefan3891talklogscontribs 22:43, 30 June 2024 (UTC)
Discussion
I would like to remind you all that consensus is !voting. The opposition argument above will be given significantly more weight, as will any well thought out supporting or neutral arguments. Justarandomamerican (talk) 23:06, 29 June 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Suggestion
Hey everyone, I've noticed that in the navigation section of the main menu on the left side, there's a link to test pages that redirects to a category of test pages. Instead of linking to the category, I suggest we create a list of test pages and include a one-line description for each page. This would be more helpful for new users. The AP (talk) 15:13, 1 July 2024 (UTC)
That seems pretty uncontroversial, go ahead! X (talk + contribs) 12:03, 2 July 2024 (UTC)
Why are my crat permissions not granted?
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Hi. You were not granted bureaucrat because there was community consensus against granting you the permission. Justarandomamerican (talk) 23:16, 12 July 2024 (UTC)
Fine, but I would say I would wait until 90 days, (oh, actually 3 months) passed. Tailsultimatefan3891talklogscontribs 23:17, 12 July 2024 (UTC)
Because the majority of votes were against Justman10000 (talk) 23:19, 12 July 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
My rights
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Done, rights revoked
Please remove all my rights except patroller. Thank you. PB2008 (talk) 08:04, 11 July 2024 (UTC)
Done by Justman10000. Thanks for your work here! Gepardtalk 08:09, 11 July 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Requests for approval (bot)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Hello all, I have created a bot account named User:DR bot for maintenance tasks on this wiki. The first task I want to perform with this bot is to archive discussions on pages like the community portal, user talk pages, and other discussion venues. Therefore, I am requesting approval from the community. I'm also happy to assist with other tasks as needed. DR (talk) 16:23, 4 July 2024 (UTC)
I am against a bot archiving user talk pages, people should and do have the freedom to archive whenever. Sav • ( Edits | Talk ) 20:48, 4 July 2024 (UTC)
I would assume such a bot would be opt-in, as I would oppose mandatory archival myself. Justarandomamerican (talk) 21:21, 4 July 2024 (UTC)
This seems very uncontroversial if user talks are opt-in. We don’t have a RfBA here, @DR, so you are welcome to move forward with your bot. X (talk + contribs) 23:26, 4 July 2024 (UTC)
@Justarandomamerican, @Sav, @X This bot will not archive user talk page messages on its own. It will only do so if the following template is present. Users can add this template if they want to archive messages automatically.
Well, in that case, I'll go ahead and give your bot the green flag. Justarandomamerican (talk) 03:11, 5 July 2024 (UTC)
Well, that changes my opinion. All good with me :) Sav • ( Edits | Talk ) 19:24, 5 July 2024 (UTC)
Great, I will work on the documentation for this template. After that, we can set up auto-archiving for the community portal and the permissions request page. DR (talk) 15:34, 7 July 2024 (UTC)
@DR Can you shed light on other tasks this bot will perform? The AP (talk) 12:14, 5 July 2024 (UTC)
I currently don't have any other tasks, but I am available to help with anything if someone needs. DR (talk) 12:55, 5 July 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Bureaucracy of Tailsultimatefan3891
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Not done. Consensus is clearly against TUF receiving 'crat rights. I suggest to Tailsultimatefan to take the feedback to heart and wait 2 weeks to a month before requesting crat here or to a Steward. Justarandomamerican (talk) 17:42, 12 July 2024 (UTC)
[I agree] I am familiar with all of Test Wiki's policies and agree to follow them completely.
[I also agree] I agree that I am entirely responsible for all actions done under this account, including actions performed under this account by someone other than myself.
[I also agree] I agree that if I misuse the tools, my access might be revoked and I may be banned from Test Wiki without prior warning.
[I also agree] Note this right can only be granted by stewards.
Other comments: I would suggest passing a vote here. I know what are the risks here. Tailsultimatefan3891talklogscontribs 20:16, 25 June 2024 (UTC)
Support
Support, like mines! MihaiAdmin1 (talk) 20:23, 25 June 2024 (UTC)
Sockpuppetry suspected. I assume the stewards are investigating. X (talk + contribs) 20:56, 25 June 2024 (UTC)
No relation between Mihai and Tailsultimatefan. Justarandomamerican (talk) 21:15, 25 June 2024 (UTC)
Is the vote still valid? Said user is blocked Justman10000 (talk) 20:10, 8 July 2024 (UTC)
Support They haven't created any problems since acquiring the rights. Let's give them a temporary crat bit which can later be extended to permanent The AP (talk) 15:14, 26 June 2024 (UTC)
Support If I recall correctly, this user has not done anything wrong recently, in the sense of violating policies. However, pretty much of what X said is true. But me personally, I don't have any problems with giving this user bureaucrat rights, but I'd also like to see them address the problems X has stated from the oppose and neutral sections. Tsukushi (talk) 08:40, 29 June 2024 (UTC)
Are you aware of the problems caused by the requester and still give your support? Justman10000 (talk) 20:11, 8 July 2024 (UTC)
Oppose
Strongly oppose Acts like he's a steward (always wants to lecture me), even if he means good, it's kind of annoying... For example this or especially this! As I said, even if it's meant good, one don't have to act like a steward if one isn't one! Furthermore, the requester assumes that he would be exempt from the inactivity policy (see behind Requested right) --Justman10000 (talk) 20:21, 8 July 2024 (UTC)
Oppose I haven’t seen a clear demonstration of maturity and knowledge of wiki norms to feel comfortable supporting this. X (talk + contribs) 17:11, 26 June 2024 (UTC)
For one, you “supported” your own rights request above. You also left a comment saying you supported a users block, which I reverted. I’ve been back from my wiki break for only 2 days and have already seen two things that don’t show knowledge of community norms. That is why I am not comfortable at this time. X (talk + contribs) 18:05, 26 June 2024 (UTC)
This, yet again, shows a lack of understanding of our policies. Non-sysops are permitted to voice their opinion in community discussions and their user rights hold no weight on their voting ability. Also, username is the alternative account of @Jody, a crat. X (talk + contribs) 01:42, 27 June 2024 (UTC)
Sometimes, I see some (if not most) of their edits in Abuse filter test trying to trigger and test some filters. Maybe you should do other non-test work here. Codename Noreste 🤔 Talk 23:30, 25 June 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Proposal
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I've decided my idea needs some work. Thanks to everyone for the advice. The AP (talk) 15:09, 9 July 2024 (UTC)
Just like we have a disqualification section in bureaucrat policy why don’t we have a steward policy that covers how does the rights of stewards and non-steward suppressor are removed.I have noticed that some users with advanced rights i.e, steward and NSS remain inactive most of the time and come by once to make some little changes or perform actions once in 1-2 months so they can retain their rights. For example EPIC Who is a Wikimedia steward and hold administrator right at Swedish Wikipedia, I think he’s a bit busy that he can actively contribute to this project and same goes with Doug a.k.a. Dmehus who is semi active at Miraheze and really inactive at this project.Additionally X has been active for past few days. With this in mind I think we definitely need a way where the community can remove such advanced rights from the users through voting. Such a resolution can be taken place when at least one or more steward and or 5 or more Crats are supporting that proposals.This way we can hold the users accountable for misuses also The AP (talk) 14:59, 24 June 2024 (UTC)
While this is happening, one of the bulk changes will be an addition of the consul permission, which can handle up to 6 months of inactivity to handle their rights and instead stewards can handle up to 9 months of inactivity to handle their rights. This may interfere with this discussion. Tailsultimatefan3891talklogscontribs 20:38, 24 June 2024 (UTC)
This needs to be fleshed out more: What sort of consensus is required to remove Steward rights? What sort of consensus is required to remove NSS rights? How will the system prevent trolls or people holding grudges from missing it? Justarandomamerican (talk) 04:10, 25 June 2024 (UTC)
Well it is not remove Steward rights. It is to add Consul rights between Bureaucrat and Steward rights.Tailsultimatefan3891talklogscontribs 11:35, 25 June 2024 (UTC)
@Tailsultimatefan3891 You should start a new section for discussion of consul permissions; please carry out only steward policy-related discussion here. The AP (talk) 14:41, 25 June 2024 (UTC)
Reasons for Removal
The rights for stewards and NSS can be removed only under two circumstances:
1.) Misuse of Rights: Any actions taken by a steward or NSS that are deemed as a misuse of their powers.
2.) Inactivity: A period of inactivity that is less than that specified in the inactivity policy.
Initiating a Resolution
To initiate the removal of rights, a resolution must be started at the community portal. The specific requirements for starting such a resolution are as follows:
For Stewards: The resolution must be supported by at least 2 stewards and/or 5 bureaucrats.
For NSS: The resolution must be supported by at least 1 steward and/or 1 NSS and/or 4 bureaucrats.
Discussion and Voting Period
Once a resolution is initiated:
Discussion Period: The discussion must last for a minimum of 14 days and can extend up to a maximum of 30 days. This period allows for a thorough and reflective conversation among community members.
Voting Period: Voting will commence after one week of discussion.
Voting Requirements
In order to vote in the redesign, the user must have bureaucratic rights and have made 50 edits since acquiring admin rights
To ensure the removal of rights:
For Stewards: At least 80% of the votes must support the removal.
For NSS: At least 70% of the votes must support the removal. The AP (talk) 14:55, 25 June 2024 (UTC)
@Justarandomamerican,this isn't perfect and it is just an idea of what purpose this would serve, if there is community consensus for the policy then I will proceed further The AP (talk) 18:13, 25 June 2024 (UTC)
Once I reach home I will make up the page as it seems there is community consensus for it The AP (talk) 04:08, 26 June 2024 (UTC)
I would Support it, but with the following additional condition: Only users who have at least the bureaucratic right, and who have made at least 50 (non-vandalistic) edits two weeks before the start of the discussion period, can vote during the impeachment process. This is to prevent trolls/vandals or troublemakers etc. from deploying sock puppets and/or meat puppets. Of course, other users who cannot meet those requirements are allowed to keep participating in the discussion of course they are not allowed to use sock puppets, and they are not allowed to vote. Drummingman (talk) 20:23, 26 June 2024 (UTC)
How does this apply to system administrators? Justarandomamerican (talk) 20:47, 26 June 2024 (UTC).
support provisionally crossed out due to practical concerns, from Justarandomamerican. Drummingman (talk) 21:57, 26 June 2024 (UTC)
@TheAstorPastor The only way I can think of is for stewards to have access to user rights and the server without being System administrators. This is to be able to add and remove rights; otherwise you have a system that is not foolproof. I honestly wonder if this is all well-thought-out now that I see these practical objections? We are a small community, this seems very difficult. A possible solution could also be, merge stewards and SA into the new users right 'Steward'. If 2 stewards or fewer remain, impeachment from the community is not possible. Drummingman (talk) 22:09, 26 June 2024 (UTC)
I still would Support this proposal, but for the resolutions, for the stewards, 2 stewards and/or 4 NSS and/or 4 AFAs, and/or 5 bureaucrats and/or 15 administrators, and for the NSSes and AFAs, 1 steward, 2 AFAs and/or 2 NSS and/or 4 bureaucrats and/or 12 administrators. But I am not sure because the upcoming consul permission may interfere with the requirements. Tailsultimatefan3891talklogscontribs 01:09, 27 June 2024 (UTC)
@Drummingman:Oppose the removal of system administrator right. As a steward combined they can be so powerful that they can lock the database or grant all user rights. However, later, I will announce the consul right as in between bureaucrat and steward, as an equivalent to sheriff on thetestwiki.org so system administrator rights will be slightly more rarely given than earlier to keep it balanced. Tailsultimatefan3891talklogscontribs 01:12, 27 June 2024 (UTC)
@Justarandomamerican and @Drummingman Well SA rights can be removed in a similar fashion i.e, 2 steward, and or 5 bureaucrat .We are a small community with 4 Steward,2 NSS and 2 SA.If there is 2 steward then definitely the impeachment is not possible but there is another way that is 5 bureaucrats. Existing steward may check user the votes so there is no sockpuppetry or meat puppetry. The AP (talk) 11:36, 27 June 2024 (UTC)
Another possibility is that SA rights can't be removed for inactivity, which is less than specified in TW:IP because we only have 2 SA, out of which MacFan4000 remains inactive most of the time. But they can be removed for misuse. The AP (talk) 11:44, 27 June 2024 (UTC)
@Justarandomamerican Do you think that I should proceed with the policy or wait a little bit longer? The AP (talk) 15:50, 28 June 2024 (UTC)
It would need to be closed by an uninvolved user, and I would not say that consensus has been reached yet. I would suggest taking all the feedback you’ve received and create a user subpage of what the updated rights pages would look like and create a new thread for the community to vote on. X (talk + contribs) 15:52, 28 June 2024 (UTC)
Thanks for the feedback. Would you care to close the thread? The AP (talk) 17:31, 28 June 2024 (UTC)
I am now also Neutral because, no practical solution has been found for the SA combination stewards. Drummingman (talk) 19:38, 28 June 2024 (UTC)
Sorry to argue about this, but system administrator rights are very powerful and I oppose on this decision. Like again:
"I still would Support this proposal, but for the resolutions, for the stewards, 2 stewards and/or 4 NSS and/or 4 AFAs, and/or 5 bureaucrats and/or 15 administrators, and for the NSSes and AFAs, 1 steward, 2 AFAs and/or 2 NSS and/or 4 bureaucrats and/or 12 administrators. But I am not sure because the upcoming consul permission may interfere with the requirements."
And another statement I made:
"Oppose the removal of system administrator right. As a steward combined they can be so powerful that they can lock the database or grant all user rights. However, later, I will announce the consul right as in between bureaucrat and steward, as an equivalent to sheriff on thetestwiki.org so system administrator rights will be slightly more rarely given than earlier to keep it balanced."
In addition, non-bureaucrats can vote during the impeachment process as long as they made at least 70 (non-vandalism) edits 1 week prior to, has been registered for at least 1 month, and needs to be an administrator. Tailsultimatefan3891talklogscontribs 22:39, 30 June 2024 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
Thanks ~~ αvírαm|(tαlk) 15:21, 10 April 2024 (UTC)
Done — You are free to reapply for user permissions when you return. Drummingman (talk) 08:52, 16 April 2024 (UTC)
Support Harvici (talk) 18:35, 27 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)
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)
has no consensus, and the second 
Neutral. Per Harvici and LisafBia. I know Aviram7 is a trusted and active user, but I think we've enough NSS. Wüstenspringmaus talk 06:35, 14 May 2024 (UTC)
Granted on probation. This just means that the right may be removed upon request by any bureaucrat in good standing. Justarandomamerican (talk) 20:45, 17 May 2024 (UTC)
Done - Codename Noreste is trusted with abuse filter editing. The only objection is whether the user would be sufficiently active, but if the user remains sufficiently active it is not an objection. In short, there is consensus to grant Abuse filter administrator. Drummingman (talk) 14:57, 28 May 2024 (UTC)
