TestWiki:Community portal: Difference between revisions

From TestWiki
(6 intermediate revisions by 5 users not shown)
Line 559: Line 559:
 
:::: {{tq|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''' {{tq|was right to remove the block}}. And even if there was, this situation would not be one of them.
 
:::: {{tq|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''' {{tq|was right to remove the block}}. And even if there was, this situation would not be one of them.
 
:::: {{tq|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.
 
:::: {{tq|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. [[User:Naleksuh|Naleksuh]] ([[User talk:Naleksuh|talk]]) 00:51, 24 September 2022 (UTC)
+
:::: 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, {{tq|[They] should've just asked another bureaucrat or consul though, not taken things into [their] own hands}} [[User:Naleksuh|Naleksuh]] ([[User talk:Naleksuh|talk]]) 00:51, 24 September 2022 (UTC)
  +
:::::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. [[User:Kiko4564|Kiko4564]] ([[User talk:Kiko4564|talk]]) 11:14, 24 September 2022 (UTC)
  +
  +
== AutoImport and old requests for permissions ==
  +
  +
Hello! This bot has archived the topics in Archive 12 instead of archive 13. Could someone please see it? Thanks! [[User:AlPaD|AlPaD]] ([[User talk:AlPaD|talk]]) 06:25, 28 September 2022 (UTC)

Revision as of 06:28, 28 September 2022

Community Portal

Archives: 1 | 2 | 3
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

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

Inactive Rights Removal - 2021-10-7

Inactive Rights Removal - 2021-10-09

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

Community Ban Request: ApexAgunomu

Community advisory opinion to Consuls regarding ApexAgunomu

Decrat for Example2

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

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

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

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

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

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

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

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

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]