TestWiki:Community portal

From TestWiki
Community Portal

Archives: 1 | 2 | 3
Shortcut
Welcome to our Community portal. Post your questions, issues, or problems below by clicking either here or the Start a new topic big blue button to the immediate right.



TestWiki:Request permissions[edit source]

Hello. One user requested permissions without having written what permissions. In case he does not answer in how many days the request must be closed? Thanks! Fffv7787 (talk) 14:43, 27 August 2021 (UTC)[reply]

@Fffv7787 I think such those request should be closed immediately. I did not find much in the policy --MdsShakil (talk) 14:43, 28 August 2021 (UTC)[reply]
@MdsShakil Thank you! Fffv7787 (talk) 14:47, 28 August 2021 (UTC)[reply]
Hello. Fffv7787 and MdsShakil, no! Such requests should not be closed (declined) immediately. The best practice to deal with such requests is to ask which permissions they want and put the request on hold. If they didn't reply close the request as stale after the few days (preferable after 4-5 days). --Mazzaz (talk) 14:55, 28 August 2021 (UTC)[reply]
@Mazzaz Hello. I reopen this request. Fffv7787 (talk) 15:15, 28 August 2021 (UTC)[reply]
AlPaD, Magogre, and MdsShakil, I thought I'd jump in to clarify the uncertainty in response to AlPa's question. Magogre's response is generally correct, but there's not a specific timeframe. It really depends. It could be two or three days, or 4-7 days, and then closed as stale, but yeah, basically (a) don't close it immediately and (b) don't close it as declined; rather, use stale. Hope that helps. :) Dmehus (talk) 04:48, 12 October 2021 (UTC)[reply]

Request for Consul: Magogre[edit source]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
This is a good-faith and intentioned request for Consul from a generally helpful, active, and positive bureaucrat and sysop on TestWiki, so the candidate is thanked both for their activity, continuing to help users, and for putting their name forward for consideration for Consul. There is consensus here that the candidate is generally helpful, active, and pleasant; however, as to whether there is a need for additional need for additional Consuls, given that we currently have six Consuls, five of which do hold other global roles, there's no consensus, given the workload required of Consuls, some of which is partially automated as Naleksuh notes. As well, there's not yet consensus here that the candidate is sufficiently experienced to undertake those duties. That being said, the candidate is encouraged to being active on TestWiki, and to notifying any Consuls should there be the rare occasion where they can't undertake a certain action (namely, ManageWiki-related actions or interface-admin permissions requests). Where a user requests, and qualifies for, interwiki-admin on TestWiki, the candidate can reach out to any of three of the Consuls to effect in their Steward capacities. Dmehus (talk) 04:41, 12 October 2021 (UTC)[reply]

Startus · talk · contribs · deleted contribs · logs · edit filter log · block user · block log.

Hello, I am Magogre. I have been around since the past few months translating and assigning permissions to users at TestWiki:Request permissions. I would like to request the consul rights to help out in removing the rights of the inactive admins, thereby, helping to reduce the workload of the current consuls which are stewards or sysadmins. Thank you for considering, --Magogre (talk) 08:03, 10 September 2021 (UTC)[reply]

  • SupportVery helpful and friendly user. Fffv7️⃣7️⃣8️⃣7️⃣ (talk) 11:51, 10 September 2021 (UTC)[reply]
  • BA candidate.svg Weak oppose - really you are a good contributor but I think you have needed little more experience for this role. Your 1st edit in this wiki only 2 months ago --MdsShakil (talk) 13:53, 13 September 2021 (UTC)[reply]
    Thank you for expressing your opinion. The edit you are referring to, was made on 14 June and it has been 3 months since then. I know this may be an early case but keeping in view the work stewards and sysadmins regularly do on meta, phab and elsewhere, I can help help to perform the consul duties on this wiki to ease their work here. --Magogre (talk) 16:53, 13 September 2021 (UTC)[reply]
  • Support Friendly and helpful 🌸 Sakura emad 💖 (talk) 05:33, 27 September 2021 (UTC)[reply]
  • I oppose, there is certainly not any "strong workload" and I've never heard of you until this request. Also, the removal of inactive sysops is done once a month and partially automated. Naleksuh (talk) 08:43, 27 September 2021 (UTC)[reply]
  • Support I agree there is no strong workload but it never hurts to have more volunteers. I patrol TestWiki from the shadows and Mazzaz is incredibly helpful in fulfilling rights requests and not only that, he's helpful across Miraheze globally. Currently, though we have 6 consuls, none of them are active on TestWiki (understandable, most of them occupy global roles) and I believe the addition of Mazzaz would be beneficial to the local community. For this reason, I support this request. Agent Isai (talk) 04:38, 30 September 2021 (UTC)[reply]
  • Weak oppose While I admit I don't know Magogre, I have seen from his contributiona that he has been generally helpful on TestWiki. Nonetheless, I don't really think there's another need for a Consul at this time as the workload is manageable by the current consuls. Reception123 (talk) 07:32, 10 October 2021 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Inactive Rights Removal - 2021-10-7[edit source]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
This has been done  done by a Consul, so this effort, while in good-faith albeit incorrect, from a procedural point of view, is moot. Dmehus (talk) 22:18, 9 October 2021 (UTC)[reply]

The rights of the following users will be removed on or after 2021-10-7 if they do not return to activity:

Thanks,

🌸 Sakura emad 💖 (talk) 04:02, 30 September 2021 (UTC)[reply]
on Behalf of Consul Team
2021-10-7
Hi, you are not a consul and by policy unable to do this. RhinosF1 (talk) 15:55, 30 September 2021 (UTC)[reply]
Hey sorry can you do that then? I think I will withdraw if we switch places. 🌸 Sakura emad 💖 (talk) 16:42, 30 September 2021 (UTC)[reply]
@RhinosF1 🌸 Sakura emad 💖 (talk) 21:18, 1 October 2021 (UTC)[reply]
@RhinosF1 hey I am really waiting for your answer Face-smile.svg Thank you 🌸 Sakura emad 💖 (talk) 12:36, 5 October 2021 (UTC)[reply]
hello @RhinosF1 I need to take action, Please let me know if what I am doing possibly is wrong. Face-smile.svg Thank you 🌸 Sakura emad 💖 (talk) 12:16, 7 October 2021 (UTC)[reply]
per policy mission dismissed 🌸 Sakura emad 💖 (talk) 03:47, 9 October 2021 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Inactive Rights Removal - 2021-10-09[edit source]

The rights of the following users will be removed on or after 2021-10-16 if they do not return to activity:

Thanks,

Dmehus (talk)
For the Consul Team
22:13, 9 October 2021 (UTC) Dmehus (talk) 22:13, 9 October 2021 (UTC)[reply]
 Rights removed from ten (10) users, noting that HeartsDo was given a temporary, three-month inactivity exception, with Consul discretion due to their activity from StructuredDiscussions seemingly not counting. Dmehus (talk) 23:46, 16 October 2021 (UTC)[reply]

New policy for abuse filter[edit source]

Hello guys, I am Matttest. I have created a new proposed-for-policy page for abuse filter. In fact now there are no policies or guidelines related to the abuse filter test, and I think it’s better to create one. Currently, I think this page can be merge into the TestWiki policy TestWiki:Main policy. What do you think? Please give some suggestions for the community. You may also change this proposal page. Regards, —-Matttest (talk) 09:45, 8 November 2021 (UTC)[reply]

P.S. I think the testing of abuse filter is a serious action, and it may be misused. It has its importance to be part of the policy of TestWiki (and maybe by merging to TestWiki:Main policy or TestWiki:Testing policy). I hope you guys can give out some opinions concerning this. Matttest (talk) 10:26, 10 November 2021 (UTC)[reply]

TNT module[edit source]

Why does my module that works good in meta doesn't work here? The imported module here links to Module:TNT for some reason, TNT does nothing for the template, and there's not even an invoke code or require code in lua Anpang (talk) 08:49, 19 November 2021 (UTC)[reply]

Inactive Rights Removal - 2021-12-27[edit source]

The rights of the following users will be removed on or after 2022-01-02 if they do not return to activity:

Thanks,

Dmehus (talk)
For the Consul Team
03:15, 28 December 2021 (UTC)
 Rights removed from fifteen (15) users. Dmehus (talk) 07:07, 3 January 2022 (UTC)[reply]

How do I restore this page?[edit source]

https://publictestwiki.com/w/index.php?title=Main_Page/fi&action=edit&redlink=1 I deleted this as a test but can't figure out how to restore it. Lugia Ann (talk) 03:36, 28 December 2021 (UTC)[reply]

Lugia Ann, that is a translation subpage, so you cannot/should not restore it in the traditional way. You have to either import the translations using the Translate extension, or just retranslate it. Dmehus (talk) 03:39, 28 December 2021 (UTC)[reply]
Okay, I will see if I can use those ways to restore the page. Lugia Ann (talk) 03:45, 28 December 2021 (UTC)[reply]

Consul request - unprotect[edit source]

These pages should be unprotected. They were protected back when crats could assign interface-admin as a security precaution, but now only consuls can assign it. They should be unprotected so authorized interface-admins can edit them. Naleksuh (talk) 01:49, 23 January 2022 (UTC)[reply]

Though the CSS and JS script pages are sensitive from a security standpoint, I'd be willing to lower protection for the skin-specific CSS/JS pages to interface-admin, on a provisional basis; however, the reasons by which MediaWiki:Sitenotice, MediaWiki:Sidebar, MediaWiki:Common.css, and MediaWiki:Common.js are Consul-protected is because these either control the sitewide CSS/JS for everyone or they relate to matters which are within the purview of the non-test bureaucrats on TestWiki, Consuls. Dmehus (talk) 22:47, 23 January 2022 (UTC)[reply]
@Dmehus: First, Common.js and Common.css are protected for security reasons (infact, they were incorrectly protected before until I had Void fix it), second, interface admin is a non-testing group, and non-test edits are permitted. It is the same reason I have interface admin. Naleksuh (talk) 23:30, 23 January 2022 (UTC)[reply]
Naleksuh, yes, I remember that the pages in question were protected with creation protection rather than as blank pages with edit protection, and I thank you for your report. However, interface-admin is not, strictly speaking, a non-test permission. It is somewhat of a hybrid test/non-test permission. Regardless, it is nonetheless a Consul-delegated role, and I'm both (a) not seeing a high volume of edit requests that Consuls cannot handle for these pages and (b) given the widespread end user impacts MediaWiki:Common.css, and MediaWiki:Common.js can have, I'm inclined to defer to the pre-existing Consul practice of maintaining these at Consul protection. Dmehus (talk) 23:41, 23 January 2022 (UTC)[reply]
​ If that's the case, then there's no reason to have the interface-admin group at all, might as well delete it. Right now, interface-admins can editsitejs except for the part where they can't because it was protected, and was only protected back when it could be assigned by anyone. Naleksuh (talk) 23:43, 23 January 2022 (UTC)[reply]
Well, the group was deleted before, but I can see a valid reasons for non-Consuls to be able to perform gadget maintenance, upgrades, and various other tasks on TestWiki. I can also see a weaker case for it being used for testing changes before deploying to a non-TestWiki Miraheze wiki or another wiki. The idea is that it can be used for both testing and non-testing purposes, but rather than the permission being granted by any bureaucrat, which any user can request, in theory if not in practice, after they have made at least ten (10) editing contributions and had an account for at least four (4) days, it was felt that was too weak of a granting criteria. For those reasons, I see a case for maintaining the group, but I'd certainly be open to hearing what other users, and especially interface administrators, have to say on the matter Dmehus (talk) 23:54, 23 January 2022 (UTC)[reply]
I was not suggesting deleting the group, that was rhetorical. Naleksuh (talk) 00:19, 24 January 2022 (UTC)[reply]

Inactive Rights Removal - 2022-02-19[edit source]

The rights of the following users will be removed on or after 2022-02-26 if they do not return to activity:

Thanks,

Dmehus (talk)
For the Consul Team
23:10, 19 February 2022 (UTC)
 Ten (10) users removed per the above, with an administrative note to Ugochimobi. Ugochimobi, please note that, going forward, StructuredDiscussions activity is not counted as activity, pending a fix to the the inactivity script by Void, so you will need to demonstrate some other form of activity by the next time the script is run later in March. Thanks. Dmehus (talk) 23:04, 26 February 2022 (UTC)[reply]
@Dmehus: for example, the edit I made here ? Thanks :) Ugochimobi (talk) 23:36, 26 February 2022 (UTC)[reply]
Ugochimobi,  Exactly. Face-smile.svg Thank you. You are now active for three (3) more months. Dmehus (talk) 23:40, 26 February 2022 (UTC)[reply]
Thank you very much Doug :), it's been a while we actually chatted but I'm sure you're okay 😊 Ugochimobi (talk) 23:43, 26 February 2022 (UTC)[reply]

Minor amendment to the TestWiki:Inactivity policy[edit source]

I've made the following minor amendment to the TestWiki:Inactivity policy, mainly due to the way in which the findInactiveSysops.js script works. Unfortunately, it is not able to consider StructuredDiscussions activity, or is it able to consider edits which are subsequently deleted by another administrator. Views from the community are welcome on this, but do note that the alternative would be to revert to determining inactivity based on Consul discretion, rather than a semi-automated activity based process. Dmehus (talk) 23:51, 19 February 2022 (UTC)[reply]

It's possible to take into account deleted edits by updating the script to make use of mw:API:Alldeletedrevisions, and it should also be possible to take into account StructuredDiscussions activity via parsing the HTML of Special:Contributions/Special:DeletedContributions as a final check. — Arcversin (talk) 01:04, 20 February 2022 (UTC)[reply]
Arcversin, yeah, Void said on IRC he figured he'd be able to correct the deleted contributions issue, but hadn't yet found a way to resolve the StructuredDiscussions issue. If you have a way of correcting the latter, I'm sure we could probably temporarily lower protection on User:Void/findInactiveSysops.js for you. Dmehus (talk) 01:32, 20 February 2022 (UTC)[reply]
What can be done is directly requesting Special:Contributions and Special:DeletedContributions without using the API so that the Structured Discussions contributions are added, then looking over that in the script to check if the last contribution by the user was via Structured Discussions, and if so, check the timestamp. This should get everything except deleted topics. — Arcversin (talk) 02:04, 20 February 2022 (UTC)[reply]
That's not a bad idea, but it's much harder to implement than it sounds, especially considering the likelihood that this would not be consistent for all users. Instead, I have the much more interesting idea of having the API parse {{Special:Contributions/<username>}}. This, when combined with a few specific options should produce consistent results for all users, provided I can figure out an accurate method for parsing out the timestamp. -- Void Whispers 03:30, 20 February 2022 (UTC)[reply]
Sounds interesting. — Arcversin (talk) 04:30, 20 February 2022 (UTC)[reply]

Request to enable extension[edit source]

I'd like to request that the TemplateSandbox extension be enabled. — Arcversin (talk) 02:58, 20 February 2022 (UTC)[reply]

Arcversin, sure, that extension could be quite useful here, so  done. Dmehus (talk) 06:07, 20 February 2022 (UTC)[reply]

CheckUser[edit source]

Hello, for test and information on MediaWiki is it possible for a CheckUser to check User:Naleksuh BOT and privately send the results back to me? This would need to be done by a consteward, so User:Dmehus or User:Void can help, if this is allowed. Naleksuh (talk) 02:41, 27 February 2022 (UTC)[reply]

Naleksuh, getting to your DMs on IRC as I suspect this is what they are about. Dmehus (talk) 03:10, 27 February 2022 (UTC)[reply]
This is permitted, per Data Request Process. Let me clarify with Owen whether he'd prefer Trust and Safety or Stewards to handle this request. It's essentially a limited in scope private user data request. Dmehus (talk) 03:12, 27 February 2022 (UTC)[reply]
​I don't remember any previous conversation but it is not "about" anything I've mentioned to someone else before, it is about something contemporary. I do wish you would stop "getting to" real-time communication though, it defeats the purpose of it. Naleksuh (talk) 03:13, 27 February 2022 (UTC)[reply]
Yes, I saw your DMs and that was unrelated to this request. Dmehus (talk) 03:15, 27 February 2022 (UTC)[reply]
Naleksuh, I have received clarification from Owen on this. Either role is capable of handling such requests. It depends on the channel in which was requested. Since you've made the request of Stewards, then it is fair for Stewards to handle it. Would you be able to direct message me on IRC your preferred method of private data delivery? I assume you'd probably prefer e-mail, but I'd prefer you didn't share your e-mail address publicly. If you have a different preferred private data delivery method, then you can also share that privately as well. Dmehus (talk) 09:42, 27 February 2022 (UTC)[reply]
​Basically I just want anyone with CheckUser access here to load the IP addresses for User:Naleksuh BOT (as many as can be fetched, 5k in 3 months) and send back the results, either via IRC or email, whichever works. Naleksuh (talk) 10:18, 27 February 2022 (UTC)[reply]
Naleksuh, this has now been  done, but is just awaiting further response from you on IRC to see if you need additional data returned. I'll leave my checkuser flag on for a little bit longer, to provide you an opportunity to reply privately. Thank you. Dmehus (talk) 18:25, 27 February 2022 (UTC)[reply]

Cannot delete a file[edit source]

I uploaded File:Test png.PNG for test use,but when I done my test,I cannot delete it.The page tell me "Deleting page: An unknown error occurred in storage backend "local-backend"."How can I do then? SD hehua (talk) 06:31, 6 March 2022 (UTC)[reply]

@SD hehua: I've opened a ticket on Phabricator regarding this error, please see T8913 for further details. — Arcversin (talk) 19:40, 9 March 2022 (UTC)[reply]
Thank you. SD hehua (talk) 17:19, 11 March 2022 (UTC)[reply]

Admin Training/School[edit source]

After looking at the main page and finding it talks about a possible admin school existing in the future, I think that we should spend some time creating one, I have an idea currently but it would help if others helped with it, currently my draft of what it could look like is stored in userpage as User:Zippybonzo/Admin School and I would appreciate if you had time to drop by and help or give some feedback, Thanks, Zippybonzo Zippybonzo (talk) 19:51, 14 March 2022 (UTC)[reply]

I'm wanting to import admin guide from Wikipedia which is more information. Thingofme (talk) 12:51, 5 April 2022 (UTC)[reply]

User:Sysop[edit source]

Hello. This userpage is owned by a user who does not have a local TestWiki account. That's why I suggest deleting it or creating a local account. Thank you! AlPaD (talk) 12:07, 2 April 2022 (UTC)[reply]

AlPaD, thank you for noting this. I'm not sure what the story is here, as it was from something like five years ago, but if I had to logically guess from WikiHow Contributor's local TestWiki contributions, this was likely their sockpuppet, except they didn't ever use it on TestWiki, so no local account was created. Given that an user page was created, though, I've  done this for you. I actually contemplating giving this account a courtesy global rename, but on the other hand, doing so could allow the username to be recreated on a wiki where a local bureaucrat has the user right to override the title blacklist, so likely will leave as is. I'm not sure what point there is to keeping the user page on TestWiki, though. So, if you want to delete it, that'd be fine, but do remove the page protection first before doing so. Thanks. Dmehus (talk) 22:57, 17 April 2022 (UTC)[reply]
@Dmehus: Hello! Global hide (centralauth-oversight) it's a good idea? Thank you! AlPaD (talk) 06:03, 18 April 2022 (UTC)[reply]

De-Sysop Request[edit source]

Considering some not-so-wise things I have done here lately, I think it would be best if I take a step down for a bit. I will be blocking myself from some namespaces until May 1, and I would appreciate it if someone could remove my sysop permissions for now. When I come back on May 1, I will re-ask for both sysop and bureaucrat (assuming that's okay). My talk page will be open for any questions or comments. If anyone feels the need to adjust the block in any way, feel free to do it.

Thank you and I'm sorry for the trouble I've caused here so far. I hope that after this break things will go more smoothly. ApexAgunomu (My changes here | Drop me a line) 16:33, 20 April 2022 (UTC)[reply]

@ApexAgunomu:  Done HeartsDo (talk) 16:38, 20 April 2022 (UTC)[reply]

TestWiki:Consuls[edit source]

Hello! Could you inform on the page that bureaucrats aren't allowed to grant a bot flag? Thanks! AlPaD (talk) 16:18, 23 April 2022 (UTC)[reply]

AlPaD,  Done. Thank you for identifying this. Dmehus (talk) 18:14, 23 April 2022 (UTC)[reply]

MediaWiki version[edit source]

I think we should upgrade this wiki to 1.39. LisafBia (talk) 06:45, 29 April 2022 (UTC)[reply]

Absolutely not. That's an alpha version. Have you seen how many bugs are caught each train week? RhinosF1 (talk) 06:51, 29 April 2022 (UTC)[reply]
Maybe we should wait for Miraheze update. SD hehua (talk) 15:24, 11 May 2022 (UTC)[reply]
@LisafBia: I guess you should check out this first. This version is not a stable version - the latest stable version is still 1.37.2 (even 1.38 is in beta version). Furthermore, upgrading mediawiki versions is a global issue, so it should be posted at meta. --Matttest (talk) 07:58, 12 May 2022 (UTC)[reply]
I suggested this idea because this is a test wiki. I knew the version was unstable. LisafBia (talk) 15:41, 12 May 2022 (UTC)[reply]
This is not where we test that MediaWiki works. It's to allow users to work out how to use the software. RhinosF1 (talk) 21:04, 12 May 2022 (UTC)[reply]

PageImages extension[edit source]

Can the mw:Extension:PageImages extension be enabled here? It's part of MediaWiki, but needs to be enabled in LocalSettings.php. --Ahecht (TALK
PAGE) 20:38, 12 May 2022 (UTC)[reply]

 Done via ManageWiki, we don't use LocalSettings.php for most changes at Miraheze RhinosF1 (talk) 21:05, 12 May 2022 (UTC)[reply]
@RhinosF1 Thanks. I can't seem to get it to recognize Mediawiki:Pageimages-denylist. If the settings at https://github.com/miraheze/mw-config/blob/master/LocalSettings.php are current, it looks like wgPageImagesDenylist is disabled everywhere but gratispaideiawiki. Can the settings from gratispaideiawiki be copied to testwiki? --Ahecht (TALK
PAGE) 14:06, 13 May 2022 (UTC)[reply]
This should be  Deployed within 30 minutes. RhinosF1 (talk) 09:15, 14 May 2022 (UTC)[reply]

New policy about protection for non-test pages[edit source]

Hello, I am Matttest. Currently there is no policies about which non-test pages should be protected at which protection level, but I think it is important given that there are disputes on protecting non-test pages, so I drafted this policy. Any comments on this policy will be appreciated and feel free to change this proposed policy. Regards, Matttest (talk) 05:17, 14 May 2022 (UTC)[reply]

Inactivity[edit source]

User:Zfshuo This user has not edited in over 3 months. @RhinosF1 @Dmehus LisafBia (talk) 13:55, 17 May 2022 (UTC)[reply]

I will run the report at the weekend. Please don't remove rights without giving proper warning. RhinosF1 (talk) 14:19, 17 May 2022 (UTC)[reply]
@LisafBia: Please consider this case in the community portal. Users who are inactive for 3 months should be reminded at their talk page, before removing his/her rights (should be done a week later after the warning according to the policy). The action should also be done by a consul, not a bureaucrat. --Matttest (talk) 06:32, 18 May 2022 (UTC)[reply]
LisafBia,  Done. Thank you for the reminder! Dmehus (talk) 23:16, 21 May 2022 (UTC)[reply]

Inactive Rights Removal - 2022-05-21[edit source]

The rights of the following users will be removed on or after 2022-05-28 if they do not return to activity:

Thanks,

Dmehus (talk)
For the Consul Team
23:14, 21 May 2022 (UTC)
@Dmehus: Please, don't remove my rights right now. I'll increase my activity next month. Although, since last March I have been almost inactive on all wikis. খাত্তাব হাসান (talk) 08:23, 22 May 2022 (UTC)[reply]
@খাত্তাব হাসান: Your comment in reply is enough to stop you going inactive. Your rights will now remain for another 3 months. Please try and make an edit at least once every 80 or so days. RhinosF1 (talk) 09:08, 22 May 2022 (UTC)[reply]
 Eighteen (18) inactive user permissions removed from this batch. A forthcoming notice of the current inactive users will follow shortly. Dmehus (talk) 01:18, 12 November 2022 (UTC)[reply]

Community Ban Request: ApexAgunomu[edit source]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
Keeping in mind the comments made by John in his revert of the original close, I am now reclosing this discussion as successful. There are 8 support votes and 0 opposes, therefore making support unanimous for the proposal. In terms of due process, ApexAgunomu is free to appeal this ban to the community at a later time. Reception123 (talk) 05:45, 8 June 2022 (UTC)[reply]

Hello all,

I'm left with bringing this to the community as it's been actioned by Consuls only on various occasions and the current status is not doing us much good.

Apex was unlocked and had their ban removed on TestWiki by Dmehus (talk · contribs) and was given a very generous chance by myself to allow them to quickly get to testing.

Since then, Apex has ignored every piece of advice & restriction put in place. Today, they moved to posting comments with swear words to avoid getting caught by the abuse filter supposed to be their to give guidance which has numerous hits showing them breaking policy.

Apex has been blocked & unblocked since the unlock on numerous occasions with the most recent being removed by Doug way before expiry.

I am therefore asking the community to present their opinion on Apex's sanctions and proposing an indefinite community ban as I do not believe simply adding restrictions for every time something inappropriate is done will be sustainable.

As a community ban, it would only be appealable via a community discussion where consensus was reached.

Thanks, RhinosF1 (talk) 09:04, 4 June 2022 (UTC)[reply]

Reply from ApexAgunomu[edit source]

I am honestly surprised to see this proposal since I honestly was trying to make good edits earlier today, and while I realize it has 100% support for going through, I would be very grateful if I could have one last chance to test here and show that I can obey the rules here. I thought that since my disruptive actions were being stopped by the filter, there was no harm if I "slipped up". But I see that I need to show that I have actually changed my behavior, by not setting off the filter in the first place.

Here are my proposals to remedy this situation.

  1. Modify the filter to only allow userspace edits (for however long is necessary)
  2. Restriction from requesting admin or bureaucrat for whatever time
  3. A clear understanding that attempts to edit around the filter or triggering the filter will result in the ban being placed.

If this proposal is accepted, I will abide by these restrictions and understand very clearly that this is my last chance to test on this wiki. ApexAgunomu (My changes here | Drop me a line) 02:27, 5 June 2022 (UTC)[reply]

Support ban[edit source]

  1. As proposed RhinosF1 (talk) 09:04, 4 June 2022 (UTC)[reply]
  2. Apex's actions speak far louder than their words. They claim to want to do better, but every time they are unlocked/unbanned, they go right back to the same behaviors that got them banned in the first place. I believe it is time to treat these actions for what they are: trolling. Apex should be indefinitely blocked just like any other troll would be. Sario528 (talk) 16:07, 4 June 2022 (UTC)[reply]
  3. Support I've been watching this user for a solitude of 2 ½ months now, and all I have seen was nothing but disruption over and over again. --DarkMatterMan4500 (talk) 16:15, 4 June 2022 (UTC)[reply]
  4. Support Just be able to send email and write on her talk page. AlPaD (talk) 19:41, 4 June 2022 (UTC)[reply]
  5. Per above, I have nothing to add and per my obversavtion after the unblock, nothing have really changed (just stopped by the filter) HeartsDo (talk) 19:54, 4 June 2022 (UTC)[reply]
  6. Support I tried to assume good faith, but the fact is that everytime he is unblocked, the policies are violated and almost all the log actions done are disruptive behaviours. Matttest (talk) 03:37, 5 June 2022 (UTC)[reply]
  7. Support Regrettably, I see no other way forward. The user has been given enough chances to abide by the polices. Universal Omega (talk) 06:55, 5 June 2022 (UTC)[reply]
  8. Support per above. MacFan4000 (Talk Contribs) 16:45, 5 June 2022 (UTC)[reply]

Oppose ban, support other restrictions[edit source]

  1. I understand that the user has made many mistakes (inappropriate commentsand etc), but she has also made good-faith actions. I believe that there should be restrictions, although my indefinite ban seems excessive. AlPaD (talk) 13:51, 4 June 2022 (UTC)[reply]
    @AIPaD: Can you please explain why you think other restrictions might work as opposed to a ban? We've already tried putting them in place a few times. RhinosF1 (talk) 15:06, 4 June 2022 (UTC)[reply]
    @RhinosF1: I still hope that at some point she will be able to follow the rules. AlPaD (talk) 18:22, 4 June 2022 (UTC)[reply]
    So do I but to suggest implementing restrictions then they need to be defined or it becomes a proposal that's not actionable. RhinosF1 (talk) 18:41, 4 June 2022 (UTC)[reply]
    I'm thinking of Consuls blocking her from the Wiki, but to able to write on her talk page and send emails. AlPaD (talk) 18:54, 4 June 2022 (UTC)[reply]
    Then why not support a ban but just put a condition that talk page is left open. The only difference between a ban and block is how it can be appealed. RhinosF1 (talk) 19:31, 4 June 2022 (UTC)[reply]
    OK thanks! AlPaD (talk) 19:42, 4 June 2022 (UTC)[reply]
    I see you voted support after this comment, will you use the <del> tag on the oppose vote to avoid confusion? Matttest (talk) 03:32, 5 June 2022 (UTC)[reply]
    @Matttest: Yes, I add tag. AlPaD (talk) 04:13, 5 June 2022 (UTC)[reply]

Support Status Quo[edit source]

Oppose restrictions[edit source]

General comments[edit source]

I have two questions.

  1. How long will this discussion be open for?
  2. Is there any minimum length of time I have to wait before I can appeal this sanction?

ApexAgunomu (My changes here | Drop me a line) 07:52, 5 June 2022 (UTC)[reply]

3 days minimum and no, there is no minimum time until you can appeal. RhinosF1 (talk) 07:56, 5 June 2022 (UTC)[reply]

I have one more question @RhinosF1:. Why not just block me if there are problems with my editing here? Why is this being turned into a community ban instead? ApexAgunomu (My changes here | Drop me a line) 14:32, 5 June 2022 (UTC)[reply]

I chose to request a community ban as there has been disagreements among both consuls and involved community members as to what sanctions are appropriate. A community endorsed sanction. This ensures the community can be clear on the best approach. RhinosF1 (talk) 15:36, 5 June 2022 (UTC)[reply]

Reverted Closure[edit source]

While "community bans" on TestWiki may have been done in the past, they are not supported by official policy. Consuls can seek the TestWiki community's input, of course, on a non-binding and advisory basis. Likewise, the same is true for Consuls seeking input on an unblock. The reason for this is because this is two-fold. For one thing, TestWiki, save for its Consuls and a handful of users, is a dynamic community that has high turnover. For another, it provides all users with proper due process, ensuring that Consuls, as the non-test administrators on this wiki, balance the community's frustrations with due process whilst ensuring local control. In other words, a wiki that did not have appropriate due process processes in place may well give rise to the user having standing for a complaint under the a global process Stewards took over from the former Code of Conduct Commission. In terms of this proposal, it is also noteworthy that RhinosF1 has seemingly been left with no other apparent option, despite not making a single attempt to modify and add to the abuse filter Chrs created. It also noteworthy that no other Consul has supported this proposal. Likewise, perhaps the strongest arguments come from AlPaD and Universal Omega, which are more supportive of a Consul blocking the user indefinitely than for any sort of ban, which, as mentioned, does not exist in official policy. Secondarily, RhinosF1 has not proposed any other alternate proposal, and has almost seemingly held a grudge against ApexAgunomu (nee Bugambilia) since day one. This is evidenced by him ignoring ApexAgunomu's alternate proposal. Finally, because of this lack of due of process and alternate proposals, I will initiate a community discussion, on a non-binding and advisory basis that proposes several options and invites discussion on a fourth unforeseen option. Dmehus (talk) 04:49, 6 June 2022 (UTC)[reply]

I have been asked to review this in Steward capacity and having looked at it in some detail, I have made the decision to revert this closure on two grounds;
  1. It does not clearly take into account the community's expressed wishes so far,
  2. It is a non-sensical closure in favour to promote another vote where the tide of voting seems more leading to a certain resolution in response and contrary to the existing discussion.
I will respond to the closure line by line to explain my neutral stance on it and why I believe Steward intervention here was appropriate.
"While "community bans" on TestWiki may have been done in the past, they are not supported by official policy."
I concur there is no policy in place, however written under the main policy is: "And for the rest, just use common sense!", which to me means a community discussion about actions should be respected - this is backed up globally in that Stewards have a main responsibility to ensure community consensus is respected, except where policy explicitly prohibits certain actions. I can not see any policy locally or globally which prevents community bans - therefore the discussion surrounding one should be allowed unless the local community have explicitly voted that community bans shouldn't be used or discussed.
"Consuls can seek the TestWiki community's input, of course, on a non-binding and advisory basis."
This discussion sounds like it is doing this, as the prose reads, "I am therefore asking the community to present their opinion on Apex's sanctions and proposing an indefinite community ban".
"In other words, a wiki that did not have appropriate due process processes in place may well give rise to the user having standing for a complaint"
This is indeed true - however a community discussion in the absence of due process sounds like something you can dispute with? Afterall, if the community voted to introduce a ban policy, and then banned them - this would still be dependent on community consensus and would likely end in the same way. One could argue ignoring and preventing community discussion being had could be cause for a complaint under global processes - one which has lead to this decision being reviewed externally and neutrally by myself in my Steward capacity.
"It also noteworthy that no other Consul has supported this proposal."
Can you link me to the relevant policy that states a Consul must approve all community discussions taking place?
"Likewise, perhaps the strongest arguments come from AlPaD and Universal Omega, which are more supportive of a Consul blocking the user indefinitely than for any sort of ban"
They both supported the ban in this discussion, and neither strongly provided an argument for a limited block over a ban - in fact Universal Omega made no distinction in his comment for either - AlPaD did make a distinction that sounds more like a block than a ban, but didn't make any strong argument for a block over a ban.
"RhinosF1 has not proposed any other alternate proposal"
I don't feel in a discussion about whether to ban a user, another alternative is required - either the community support a ban or do not support a ban.
"I will initiate a community discussion"
You are free to, however, you can not close an active discussion against the consensus that has formed on it just because you do not like the consensus starting to form on it because it does not fall in line with your idea of a "perfect resolution".
Based on all of this above, I have made the decision based on numerous requests by local testwiki users to intervene and revert this closure to allow the community to discuss the proposal. This can be re-closed based on either consensus or a procedural manner (policy prevents this discussion, the requesting users withdraws it fully, etc.). John (talk) 18:28, 6 June 2022 (UTC)[reply]
Also just reviewing the discussion below, one of the main reasons for the closing this discussion was that a community ban is not grounded in policy - yet below in your proposals, you propose a 2 way interaction ban. Could you enlighten me on the policy that gives rise to this? John (talk) 18:46, 6 June 2022 (UTC)[reply]

Closure Request[edit source]

I apologize if I'm not supposed to do this, but I'd rather not have this discussion be dragged out for days on end. And while I really don't want to be banned, it seems unavoidable. So seeing as this discussion has been been open for three days and a clear consensus has been reached, I would ask that both discussions here about me be closed and the agreed-upon remedy be enacted (as much as I don't like it), so we can all move on past this whole thing. Thank you. @RhinosF1: @Dmehus: ApexAgunomu (My changes here | Drop me a line) 04:04, 8 June 2022 (UTC)[reply]

It's rare to see a closure request from the recipient of the request but acceptance is good. Most active consuls have already !voted. I'll ping User:Reception123 and User:Void as uninvolved consuls. If it is still open in 24 hours let me know and I will close as an uninvolved bureaucrat (as far as I know, that is allowed in clear cases like this one). Naleksuh (talk) 04:35, 8 June 2022 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Community advisory opinion to Consuls regarding ApexAgunomu[edit source]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
There is no consensus for Proposals 1, 2 and 3. There are 4 votes in favour of Proposal 4 however given that the community ban above has already been enacted and this proposal doesn't seem to differ, there is no need to further implement anything. Reception123 (talk) 05:52, 8 June 2022 (UTC)[reply]

RhinosF1 initiated a community ban proposal re: ApexAgunomu the other day. Granted, in the past, community "bans" may have taken place, they are, not, however, supported by official policy. Reception123, as one of two TestWiki co-founding Consuls (alongside NDKilla), and I are wanting to retain TestWiki's spirit of assuming good faith, having only a a very few official rules.

The excellent abuse filter Chrs created, at my request and having had the support of Reception123 and Agent Isai, seems to be, for the most part, doing its job. If RhinosF1 is bothered by seeing abuse log hits in the #miraheze-feed-test on IRC, he can easily instruct StreamBotMH to !ignore ApexAgunomu in the channel. Or, alternatively, he can add the flood to ApexAgunomu. Crucially, though, as I and Reception123 have said elsewhere, any bureaucrat can feel free to tweak the abuse filter in question, to catch anything we've not yet identified.

Secondarily, as RhinosF1 has not demonstrated a good-faith and -intentioned effort to propose alternative solutions for discussion, on a non-binding and advisory basis, of course, he has not met the high burden such a block would need. Likewise, he has similarly ignored ApexAgunomu's offering of other alternate solutions.

AlPaD and likely HeartsDo's comments above show frustration, but do show that willingness to accept good-faith and to being amenable to alternative solutions. Thus, taking that all into account, I'm proposing the following proposals, each with support sections. Oppose sections are unnecessary, as each proposal would be mutually exclusive of each other, and Consuls would take both the number of support !votes and the quality and strength of any arguments into consideration in effecting any outcome. Dmehus (talk) 05:21, 6 June 2022 (UTC)[reply]

Proposal 1: Status quo + extension of abuse filter restrictions[edit source]

ApexAgunomu is subject to the strict abuse filter restrictions, originally slated to lapse this week, for an additional thirty days. Consuls will consider the severity and number of hits after thirty days in determining whether there has been sufficient improvement to warrant easing or removal of the abuse filter restrictions. Any bureaucrat may add to the abuse filter where ApexAgunomu is getting through the abuse filter.

Support[edit source]

Proposal 2: Proposal 1 + !ignore ApexAgunomu on IRC[edit source]

Rationale: To ease RhinosF1's stress of seeing abuse filter hits by ApexAgunomu. For greater clarity, this is a StreamBotMH command.

Support[edit source]

  1. ApexAgunomu (My changes here | Drop me a line) 06:01, 6 June 2022 (UTC)[reply]

Proposal 3: Proposal 1 + 2 + two-way interaction ban between ApexAgunomu and RhinosF1[edit source]

Rationale: Given the history between ApexAgunomu and RhinosF1, and RhinosF1 leaping to a community ban not supported by official policy and not having made any attempt to modify the abuse filter Chrs so awesomely created. This would not preclude any other Consul from blocking ApexAgunomu, if required.

Support[edit source]

Proposal 3: Block ApexAgunomu for 30 days[edit source]

Rationale: The abuse filter may have become untenable and the user's good-faith repeated abuse filter hits are continue to demonstrate that they're not making progress required to restore sysop and bureaucrat. That being said, the user is making very good reports on IRC to the CVT team and to Stewards on Test Wiki, which has to be taken into consideration. As such, if they can go thirty (30) calendar days from imposition of the block, that alone should demonstrate enough capacity to warrant disabling of the abuse filter and full restoration of the sysop and bureaucrat permissions. As such, if this proposal passes, they are blocked for thirty (30) calendar days and, if they go the full thirty (30) days, without sockpuppetry, they are unblocked by a Consul and their rights restored.

Support[edit source]

Proposal 4: Block ApexAgunomu indefinitely[edit source]

Rationale: Consensus is consensus, and Dmehus's actions are a w:Project:Supervote. It shouldn't be necessary to create an edi filter to stop wide-scale disruption from one person (and much less, the disruption being such a repetitious pattern that automated software is able to detect it).

Reply by ApexAgunomu[edit source]

I know I have caused a lot of trouble here, and I apologize sincerely for that. However, I would really appreciate it if I could have one last chance to test here. I am not a troll, and I will show that I can obey the rules here.

Also, now that I think about it, I'm not sure what exactly I did to warrant an indefinite block. I made some edits that were disruptive, but they were stoped by the filter. And when I tried to edit in other ways that wouldn't set off the filter, I didn't know what exactly I could test without having the admin powers, but I wanted to show that I can test here without triggering the filter. However, that testing of mine led to an indefinite block being proposed and seemingly supported by everyone, which I just don't feel is warranted yet. I thought that since my disruptive actions were being stopped by the filter, there was no harm if I "slipped up". But I see that I need to show that I have actually changed my behavior, by not setting off the filter in the first place. ApexAgunomu (My changes here | Drop me a line) 16:12, 6 June 2022 (UTC)[reply]

@ApexAgunomu: What happened is that you used numerous swear words and racial/sexual slurs in a fashion that resembled referring to the community as a whole as those words. When you put "hello fuckers" onto a new page, you're calling the whole community "fuckers", and that, alongside the use of actual slurs (not just benign profanity like "fuck" or "shit") is what the community is taking offense to. — Chrs (talk) 18:41, 7 June 2022 (UTC)[reply]
I absolutely don't blame them for being offended. And I guess this whole discussion is the outcome of my whole history here, not just my most recent actions (which to me were the only things leading up to this discussion). ApexAgunomu (My changes here | Drop me a line) 19:53, 7 June 2022 (UTC)[reply]

Support[edit source]

  1. I didn't vote on the original proposal because I am interaction-banned with the user who started it, but I am tired of the constant abuse of wiki resources and what don't even really read like mistakes. I got tired of seeing ApexAgunomu abuse page moves, so I edited the filter to prevent them from moving pages other than Move test. Just minutes later, I got a notification that a filter I recently edited was activated, and the log showed that it blocked ApexAgunomu from moving Change content model test to TestWiki:Change content model test (there have been plenty of other moves like moving one page around to templates, categories, talk pages, and moving people's user pages into article space). If eight people supported the ban, with no-one opposed, I think there's a very clear consensus and closing it as unsuccessful on a technicality is overly bureaucratic and a supervote. Naleksuh (talk) 07:17, 6 June 2022 (UTC)[reply]
  2. In my opinion, the goings on between the Consuls is irrelevant, because Apex refuses to change their behavior. Apex has been given more warnings and more second chances than anyone I've ever seen on any wiki project, and every time they go right back to trolling. It is far past time to stop giving Apex special treatment and just ban them. Sario528 (talk) 11:18, 6 June 2022 (UTC)[reply]
  3. Support assuming my request for John to review as an independent steward doesn't make this moot anyway. I note for the record as well that I thank Naleksuh for their compliance with the IBAN but I do not feel it precludes them voting in the discussion in anyway. RhinosF1 (talk) 11:24, 6 June 2022 (UTC)[reply]
  4. Support per above. MacFan4000 (Talk Contribs) 12:33, 6 June 2022 (UTC)[reply]

General comments[edit source]

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

Decrat for Example2[edit source]

Experimented with which direction "back" and "forward" counts as with expiring user groups that can't be changed. Because I had to test this on a group I cannot remove, I used the bureaucrat group. Any consul may now decrat Example2 as test done. Naleksuh (talk) 07:24, 6 June 2022 (UTC)[reply]

 Done Reception123 (talk) 05:55, 8 June 2022 (UTC)[reply]

mh:meta:Requests_for_Comment/Global_ban_for_ApexAgunomu[edit source]

mh:meta:Requests_for_Comment/Global_ban_for_ApexAgunomu is now in progress - required to notify as one of the wikis that user was involved in Naleksuh (talk) 07:44, 15 June 2022 (UTC)[reply]

Template displaytitle[edit source]

This template currently doesn't exist (it just redlinks). Is there anything we could do about it? According to Special:Undelete it was never deleted. In the edit history I can see that this problem goes quite a while back. Szczot3k (talk) 06:20, 17 June 2022 (UTC)[reply]

Never mind. Trying to use it via {{DISPLAYTITLE|Something}} is the reason why. It should be used with : instead of | Szczot3k (talk) 06:27, 17 June 2022 (UTC)[reply]

Never, never mind. I was just using it wrong the whole time.
Maybe it would be beneficial to at least add a documentation to this template? Szczot3k (talk) 06:46, 17 June 2022 (UTC)[reply]

Bureaucrats - two different sets of requirements[edit source]

TestWiki has inconsistent requirements for bureaucrats.
Per TW:RfP - one has to be an Administrator for at least 24 hours, have at least 10 edits, and be "trustworthy".
On the other hand TW:B states that the user should be an User for at least 24 hours, have at least 10 edits an be "trusted by the community".
Being an user, and an administrator on TW are two different things. From what I can see the RfP's "Admin for at least 24h" requirement is the one enforced, but that doesn't mean that technically it's different from TW:B. Being trustworthy, and trusted by the community can also be interpreted twofold. The second one could mean there should be a consensus, and not just one TW:C judging that. Szczot3k (talk) 12:46, 17 June 2022 (UTC)[reply]

Using MediaWiki 1.39[edit source]

In general, test wikis run the latest alpha/developer release of MediaWiki, which is currently 1.39. Cigaryno (talk) 07:52, 18 June 2022 (UTC)[reply]

This is for people mostly learning how to use mediawiki. It is not a developer test wiki.
We have beta which will run 1.39 as soon as it moves to beta.
Running 1.39 would be impossible currently due to the number of breaking changes, very few extensions actually work. We don't have the resources anyway to deploy a production standard 1.39 server. RhinosF1 (talk) 08:22, 18 June 2022 (UTC)[reply]
1.39 should reach beta/RC in September 2022. Cigaryno (talk) 16:24, 19 June 2022 (UTC)[reply]
I can host a wiki myself running MediaWiki 1.39 to see if there are known issues. Cigaryno (talk) 15:44, 26 June 2022 (UTC)[reply]

Proposal : Demo bot proxy blocking on test wiki[edit source]

Hello. There's currently an actively ongoing request to block many more proxies globally across all of Miraheze, it's supposed to be done already but in practice hasn't been taken care of that well. There's a new system upcoming designed to block more proxies by using Wikimedia's list. I would like to demo this on test wiki given that 1) it is a test wiki after all 2) there is a huge spam problem here. Any objections? Also, thoughts from consuls User:Reception123 User:Void Naleksuh (talk) 21:03, 29 June 2022 (UTC)[reply]

I don’t believe this is a vote, but I would Support this request. We can test this out here, and if it works we can expand to the rest of Miraheze in time. If not, no skin off our backs. I have faith this will work as we haven’t been great about blocking proxies in the past. BrandonWM (talk - contribs) 23:48, 29 June 2022 (UTC)[reply]
I would ideally like at least one consul to input before I place 40000+ blocks, that kind of thing is not easy to reverse. (Though they can be short i.e. ~1 week during the trial period, and only longer during longterm use). Any thoughts from uninvolved users so far? Naleksuh (talk) 19:18, 30 June 2022 (UTC)[reply]
Strong oppose I can not support this, a bot like this should ONLY be ran by a user whom has experience with global permissions on Miraheze, for example current or former CVT, Stewards, sysadmins, ect. A bot of this type has severe consequences if it has to many false positives, one that only those people would have experience handling. At this moment, Void has been working on a bot to handle this sort of thing. I have also been doing separate work on reviving Proxybot. This request is a complete no from me, and this vote will not change. Zppix (Meta | talk to me) 20:31, 1 July 2022 (UTC)[reply]
Void's sources missed proxies, which is why this request was started. There is currently only an import task, which I asked Reception123 to comment on. Also, this isn't a vote, so there's no vote to change. Naleksuh (talk) 21:58, 1 July 2022 (UTC)[reply]
Also Zppix, I will note that you don’t have the authority to single-handedly overrule this request. Your comment is noted and has been added to the record, but you cannot overrule this request just because you oppose it. BrandonWM (talk - contribs) 22:21, 1 July 2022 (UTC)[reply]
They actually weren't trying to overrule it, they were just "voting" on a thing that wasn't a vote. Though I do note that they specifically defined experience as "current or former CVT" so that they would qualify but not me. Naleksuh (talk) 22:24, 1 July 2022 (UTC)[reply]
The reason I specified what I did is because those peoples would have experience with global permissions on Miraheze. Zppix (Meta | talk to me) 22:51, 1 July 2022 (UTC)[reply]
Not the only one who doesn’t like this idea, consuls do talk to each other you know. Zppix (Meta | talk to me) 22:50, 1 July 2022 (UTC)[reply]
From a technical perspective it is almost 100% impossible to not miss open proxies. Simply taking WMF’s block list is disruptive, as there are no checks in place to make sure said blocks are still valid. Zppix (Meta | talk to me) 22:54, 1 July 2022 (UTC)[reply]
The entire point of a test wiki is to test. I wouldn’t be opposed to trying it out and seeing if it works. BrandonWM (talk - contribs) 19:16, 3 July 2022 (UTC)[reply]

Consul request[edit source]

Hello, I am asking if I could become a consul or not because I have done a lot of things. Cigaryno (talk) 17:49, 1 July 2022 (UTC)[reply]

Users can become consul after being elected. Your request however is very early and much more experienced and users who have been here for a long time aren't consuls. There are probably enough consuls right now as well so there's not really a need for any more. I'd advise against hat collecting. Reception123 (talk) 18:09, 1 July 2022 (UTC)[reply]
I will request in 3-6 weeks. Cigaryno (talk) 19:49, 1 July 2022 (UTC)[reply]
I really wouldn’t recommend that. You’d likely need at least 3-6 months of experience, as well as being an extremely trusted member of the community. BrandonWM (talk - contribs) 22:22, 1 July 2022 (UTC)[reply]
Either way, as I say there's really no need for other Consuls right now in my opinion. Consul isn't something you set a 'target date' to become. As I say, please do resist the temptation to hat collect. Reception123 (talk) 13:43, 3 July 2022 (UTC)[reply]

Users unblocking themself[edit source]

Hi all,

Recently a user has been evading their topic ban multiple times, without any regard for the seriousness of this and reinforcing why it was made in the first place. I temporarily blocked this user for 3 days, and considered removing their sysop permissions to prevent them from unblocking themself but decided not to because I thought I could trust them not to.

Apparently not, because they ended up unblocking themselves.

While sysops do have the unblockself permission, my understanding of this is that it is supposed to be because of test blocks by sysops. I certainly don't think it is OK for users to be unblocking themselves as the recipient of actions, and I don't think anyone else would either.

It doesn't appear anyone else has commented on this problem, as due to the recent stepping down of the two most active consuls. The only user who had a chance to review this problem only reviewed the technical aspects of it. As a result, I think the community should make a plan on how to handle this situation.

Since there isn't an active community at this time, if there are not any objections from anyone (other than BrandonWM themself) I will reinstate the block as an emergency measure. While I was initially under the impression that this would constitute wheel warring, I realized that the policy generally only applies to other sysops reversing actions, and is not intended to apply to users receiving blocks, and this would almost certainly be considered block evasion by any reasonable person. However, I don't have any plans on how to solve this problem long-term, other than either via removing unblockself from sysops (might cause problems for testing blocks?) or a bot that removes them (depending on who blocked). Naleksuh (talk) 03:39, 19 September 2022 (UTC)[reply]

I suggest that only bureaucrats and consuls have this right. AlPaD (talk) 18:12, 19 September 2022 (UTC)[reply]
We may create another blocking level rather than current blocks which only available for crat's and consuls. Current blocks may use for testing purposes. —MdsShakil (talk) 05:16, 20 September 2022 (UTC)[reply]
Since I don't think another blocking level is possible, my suggestion would be to use wgRevokePermissions and to create a new group that can be assigned to users blocked for serious reasons so that they are unable to unblock themselves. Reception123 (talk) 06:24, 20 September 2022 (UTC)[reply]
It's a good idea, I agree! AlPaD (talk) 11:32, 20 September 2022 (UTC)[reply]
At that point, why not simply remove the sysop permissions? Naleksuh (talk) 16:27, 20 September 2022 (UTC)[reply]
Also, does the community believe BrandonWM's block was valid? I had said before if there were no objections I would reblock them. One user claimed the block was a "clear error" but did not have a convincing case as to why. I think the topic ban violation is clearly verifiable, see talk page for that, and does not appear to be in error. I would assume by the comments the community agrees it is valid but most people are talking about the problem in general and not this specific case. Naleksuh (talk) 16:28, 20 September 2022 (UTC)[reply]
I forgot to mention, that even if admins don't have the right to unblock themselves, if it's a partial block the user isn't considered "blocked" so they can still do it. Probably only removing administrator permission is feasibility. AlPaD (talk) 16:35, 20 September 2022 (UTC)[reply]
It's also worth noting that it appears that if you have talk page access on you can also delete and protect your talk page. Also also, a blocked user who is a sysop can still block the person who blocked them, this change is because of compromised sysop accounts. Naleksuh (talk) 16:40, 20 September 2022 (UTC)[reply]
Again, you seem to be ignoring the fact that Void had the hard-line restrictions removed. BrandonWM (talk - contribs) 23:40, 20 September 2022 (UTC)[reply]
BrandonWM, you are correct, as per what is clearly stated on your talk page both by myself and Void.
Everyone else, please check his talk page before jumping to conclusions and give him a break. I regret blocking him. Kiko4564 (talk) 07:41, 21 September 2022 (UTC)[reply]
Void did not remove the restrictions. They removed Kiko4564's block and suggested reducing the restrictions. You are ignoring the fact that you violated your topic ban and also unblocked yourself, which is a much more important problem. In addition, a consul has already participated in this discussion and proposed a solution to the problem of users unblocking themself, despite Kiko4564 pretending it was completely fine for users to do that as long as they themself believe the block was wrong. And even if they were removed, you still violated them prior to that comment. Trying to excuse the fact that you violated the topic ban and also the fact that the edits were disruptive just reinforces why there was a need for a topic ban to have been made in the first place. Naleksuh (talk) 16:01, 21 September 2022 (UTC)[reply]
Per our conversation on IRC, I am posting my rationale for using the unblockself permission. I believe the block was wrongly made and poorly justified. I had received messages of support from other crats in the hours before using the permission, and as such I felt comfortable in using it. If I had been alone in believing the block was wrong, I wouldn't have removed it, and instead elected to wait for another member of the community to remove the block. Void had also removed the hard-line restrictions, and as my edits were non-disruptive, there was no need for a block. BrandonWM (talk - contribs) 04:44, 22 September 2022 (UTC)[reply]
This is not true at all.
I had received messages of support from other crats in the hours before using the permission Actually, no, you received no such messages between being blocked and unblocking yourself. There were no messages of support from other crats when you decided on your own it was wrong and removed it. Even after the fact only one person agreed that it was OK for you to unblock yourself (not "other crats" plural) - with four users including a consul agreeing it was not OK.
and as such I felt comfortable in using it You shouldn't have. It will never be OK for a user to unblock themself, especially as seen in this discussion. If it was really that bad someone else will. There's no need for you to remove it yourself.
If I had been alone in believing the block was wrong, I wouldn't have removed it You were. And if you weren't, why didn't those people remove it?
Void had also removed the hard-line restrictions Again, Void did not remove the restrictions. What Void actually said was: I propose the restriction be reduced down to a general recommendation against making any "official" style changes without prior on-wiki approval, and an understanding that less leniency will be given in the event of future disruption. - the restrictions were not removed and remain in effect. In addition, I would call this the less leniency in the event of future disruption, as will be seen soon.
s my edits were non-disruptive Firstly, it doesn't matter whether they were disruptive. You violated your topic ban and that's not okay. Topic bans are enforced by blocking the user if they violate it. If you believed you could have made good edits in those areas, you should have requested removal, not simply violated it. As explained before, A ban is not merely a request to avoid editing "unless they behave". The measure of a ban is that even if the editor were to make good edits, permitting them to edit in those areas is perceived to pose enough risk of disruption, issues, or harm, that they may not edit at all, even if the edits seem good.. Amen. I don't think I could have said it better myself.
And secondly, they were disruptive. For example this unnecessary removal, this innapropriate self-handling, and interacting with other users.
Because of this, I do not see any valid justification for your actions. In addition, several users have agreed it is not okay for recipients of non-test blocks to unblock themselves, instead taking any of their concerns to a bureaucrat or consul. In addition, the original block has not been proven to be incorrect, and continues to only show to be more and more justified with the user attempting to justify their topic-ban evasion and justification of self-unblocks, repeating the behavior that led to that in the first place and reminding me of why they were blocked and locked originally in 2020, despite their claims to have changed. Because of this, I propose that the original block is reinstated. Please leave your thoughts and / or concerns below. Naleksuh (talk) 04:58, 22 September 2022 (UTC)[reply]
In which case User:Naleksuh, please wait for a Consul to attend to this incident and deal with this directly, instead of wheel warring with a Consul over whether or not User:BrandonWM ought to be blocked or not, even partially. I've blocked User:BrandonWM myself, and all I said was that if User:Void deemed it fit to remove the block I imposed, then so be it, and if you don't think that User:BrandonWM should've been unblocked, then you were in the wrong to engage in a wheel war, and therefore (on this occasion) User:BrandonWM was right to remove the block because: 1) it was wrong, having resulted from clear cut wheel warring and based on restrictions which had already been removed and 2) I agreed that it was right to remove it since I believed that it was a clear cut mistake. If the incident isn't serious enough to warrant desysoping, then my opinion is that it cannot serious enough to warrant a serious block. However I could be wrong. If you disagree, then please discuss the matter civilly instead of wheel warring. I never pretended that it was OK for an admin to unblock themselves just because they disagree with the block. If it were, then almost everyone would unblock themselves. Thanks. Kiko4564 (talk) 23:11, 23 September 2022 (UTC)[reply]
discuss the matter civilly instead of wheel warring I did not wheel war. BrandonWM removed the block, and it has not been reinstated since. It may be reinstated when this discussion is closed, as consensus is that it is not okay for users to unblock themself. But I certainly have not wheel warred. In fact, this thread was specifically to avoid doing so.
BrandonWM was right to remove the block Consensus is in this thread that it is never okay for serious-blocked users to unblock themself. There will never be a situation in which the user who was blocked was right to remove the block. And even if there was, this situation would not be one of them.
restrictions which had already been removed For the third time, Void specifically said they proposed removing the restrictions, which did not gain much support and I personally would oppose. As of now the restrictions remain in effect. Please stop saying they were removed both because Void did not say that and even if they did I'm not sure consuls are allowed to unliterally do that.
To any uninvolved consuls now is a good time to close this discussion which has already run its course. Four users including a consul agree that self-unblocks are not OK, and by extension I believe they should be considered block evasion. In the words of Reception123 one of the uninvolved participants and a consul, [They] should've just asked another bureaucrat or consul though, not taken things into [their] own hands Naleksuh (talk) 00:51, 24 September 2022 (UTC)[reply]
Alright, we'll agree to disagree then. I'm just saying that had you continued, the result would've been a wheel war. Thanks for not doing that. I'll let Void explain their actions personally. Kiko4564 (talk) 11:14, 24 September 2022 (UTC)[reply]

AutoImport and old requests for permissions[edit source]

Hello! This bot has archived the topics in Archive 12 instead of archive 13. Could someone please see it? Thanks! AlPaD (talk) 06:25, 28 September 2022 (UTC)[reply]

Request for Consulship[edit source]

Hi everyone, I'm Agent Isai and I'm requesting local consul here on testwiki. While I'm not the most active here on TestWiki due to my other global responsibilities such as being a Steward, I do check in every so often and generally have to look in to this wiki every few days due to other cross-wiki cases such as abuse by socks and so on. The reason for requesting the bit is because the current Consuls seem to be inactive. Dmehus used to be the main handler of things like inactivity demotions but he, nor has anyone else, handled this since May which is concerning. There are also a few other tasks which sometimes seem to drag on due to the inactivity of the current consuls so I'd like to help the upkeep of this community which is vital to Miraheze as it serves as a testbed for many users. Thank you for your consideration. Agent Isai Talk to me! 14:46, 4 November 2022 (UTC)[reply]

  1. Support Trusted, experienced, active user and steward. AlPaD (talk) 14:53, 4 November 2022 (UTC)[reply]
  2. Support --Syunsyunminmin (talk) 14:59, 6 November 2022 (UTC)[reply]
  3. Question: Regarding RFP, you declined an RFP who used the reason For testing asking what testing they wanted to do, but accepted an RFP with the reason Testing with no questions just 27 hours later. Any reason for the inconsistency? Naleksuh (talk) 00:17, 10 November 2022 (UTC)[reply]
    As I said on #miraheze-cvt, I asked for clarification about the first user's RfP as they already had an account with bureaucrat and sysop so I was wondering what they needed to test with yet a second account. As for accepting the second user's RfP, our standards for accepting RfPs are rather low. We do seem to grant users sysop (and even bureaucrat it seems) if users request it with a one or two word request. I did also note that I did it in part to see what the second user would do as it was suspected that they were a sockpuppet of a community banned user and it did end up that they were a sock. Agent Isai Talk to me! 03:07, 12 November 2022 (UTC)[reply]
  4. Support Since activity doesn't really apply here, then AI is good to go. Ugochimobi (talk) 09:31, 12 November 2022 (UTC)[reply]
  5. Strong support Steward, trusted user. They’re an exceptionally good caretaker of the community. Happy to support. BrandonWM (talk - contribs) 00:17, 27 November 2022 (UTC)[reply]
  6. Support Zppix (Meta | talk to me) 00:38, 27 November 2022 (UTC)[reply]
  7. Support Universal Omega (talk) 00:40, 27 November 2022 (UTC)[reply]
  8. Support Blad (talk) 12:54, 2 December 2022 (UTC)[reply]

Enable PortableInfoboxCreator[edit source]

I would like to request that a bureaucrat enable this as I need it for template testing and I lack bureaucratic rights. Blad (talk) 23:44, 7 November 2022 (UTC)[reply]

@Blad, do you mean you want bureaucrat permissions? If you want it, you can request it at TW:RfP after 3 more edits. Syunsyunminmin (talk) 06:26, 8 November 2022 (UTC)[reply]
I am not. I was requesting a bureaucrat to enable an extension as I lack those rights. If I were able to request bureaucrat, I would've gone there instead. Blad (talk) 11:48, 8 November 2022 (UTC)[reply]
sorry. I don't understand exactly what you want. I expect a response by other crat or consul. Syunsyunminmin (talk) 13:08, 8 November 2022 (UTC)[reply]
Aright, that's fine. Blad (talk) 13:23, 8 November 2022 (UTC)[reply]
What extension is PortableInfoboxCreator? It doesn't seem to exist. Agent Isai Talk to me! 13:28, 8 November 2022 (UTC)[reply]
It should be this one. I had made an error in the extension name. Blad (talk) 14:03, 8 November 2022 (UTC)[reply]
Blad, this has now been  done per your reasonable request. :) Dmehus (talk) 02:04, 12 November 2022 (UTC)[reply]

Inactive Rights Removal - 2022-11-11[edit source]

The rights of the following users will be removed on or after 2022-11-19 if they do not return to activity:

Thanks,

Dmehus (talk)
For the Consul Team
01:54, 12 November 2022 (UTC)
I would like to retain my permission. Thanks for the notification. Stay safe. C1K98V (💬 ✒️ 📂) 03:37, 12 November 2022 (UTC)[reply]
Please remove my flag, it is no longer needed. Thanks. Stang 17:41, 12 November 2022 (UTC)[reply]
 Done (Log) Syunsyunminmin (talk) 07:06, 13 November 2022 (UTC)[reply]

What is this?[edit source]

When I tap the three dots next to “Create Account”, this option appears 

606ms (PHP7 via testwiki@mw121 / / cp23

what is this and how can I remove it? 2001:8004:51C0:2705:9832:C0F5:A666:7350 08:09, 5 December 2022 (UTC)[reply]

Retrieved from "https://publictestwiki.com/w/index.php?title=TestWiki:Community_portal&oldid=47195"