Meta:Administrators' noticeboard/Archive 6

From Meta
Jump to navigation Jump to search
Archive This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current talk page.


Protect this page

Can the page User:IOnlyHaveATalkPage be protected from being created? That user intentionally has only a talk page for some displaying and testing purposes.  APπŸ“¨  10:33, 14 December 2021 (UTC)

Would you like administrator or autopatrolled protection? Reception123 (talk) (C) 11:00, 14 December 2021 (UTC)
Admin  APπŸ“¨  11:16, 14 December 2021 (UTC)
Yes check.svg Done ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 11:24, 14 December 2021 (UTC)
Thank you!  APπŸ“¨  11:28, 14 December 2021 (UTC)

Request for translation administrator (YellowFrogger)

Autopatrol User:Bukkit (Public)

This account is my alternative account. -- Cheers, Bukkit ( Talk β€’ All Contribs ) 15:32, 17 December 2021 (UTC)

Yes check.svg Done ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 08:25, 18 December 2021 (UTC)

Add this code to the bottom of common.js

Can this code be added to the bottom of common.js? It's a html checkbox.

$(function () {
  var myElement = document.getElementById('acceptrequest-check');
  myElement.innerHTML = '<input type="checkbox" id="chb" name="chb" value="chbchecked">';
}());
Anpang Talk Stuff 07:43, 9 December 2021 (UTC)
Your code will probably be accepted yes, if it is useful for Miraheze and cites the reasons for creating it (like adding a template, etc.), but we also avoid a lot of code so as not to 'infest' with useless code YellowFrogger (βœ‰ Talk ✐ Edits) 12:55, 9 December 2021 (UTC)
Why? ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 12:56, 9 December 2021 (UTC)
(Avoid malicious code, which is not usable, etc). , but I think this one will be accepted because it creates a lot of templates YellowFrogger (βœ‰ Talk ✐ Edits) 12:58, 9 December 2021 (UTC)
I think Rhinos is driving at which templates would be enabled, and why we need them. --Raidarr (talk) 13:01, 9 December 2021 (UTC)
I'm making an accept request checkbox template. Anpang Talk Stuff 02:14, 10 December 2021 (UTC)
You can use TemplateStyles, this is X mark.svg Not done. ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 16:01, 10 December 2021 (UTC)
Exactly. You can do User:Anpang/styles.css YellowFrogger (βœ‰ Talk ✐ Edits) 21:41, 10 December 2021 (UTC)
No. It would be at Template:Template_name/styles.js ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 12:32, 11 December 2021 (UTC)
Hmm?  APπŸ“¨  00:57, 13 December 2021 (UTC)
@RhinosF1: Templatestyles seems to not support js.  APπŸ“¨  09:19, 14 December 2021 (UTC)
@RhinosF1: This  can be done because TemplateStyles doesn't support javascript.  AnpangπŸ“¨  03:01, 22 December 2021 (UTC)

RhinosF1, TemplateStyles does not support JavaScript. It is only used for CSS. β€”k6ka 🍁 (Talk Β· Contributions) 03:04, 22 December 2021 (UTC)

UI and UX improvements

Hi! I am new here and not sure where to propose a Possible UI improvement. Can someone direct me where UI and UX is discussed? ZBlace (talk) 05:57, 16 December 2021 (UTC)

@ZBlace: On the Community noticeboard or our Discord server/IRC channel. Agent Isai Talk to me! 05:57, 16 December 2021 (UTC)
Thank you! You are free to delete this thread to keep the page clean as this was to specific question of little use for others. ZBlace (talk) 07:45, 16 December 2021 (UTC)
Moved topic to M:AN, as Noticeboards shouldn't really have talkpages really, unless it relates to changing something about the noticeboard itself. Reception123 (talk) (C) 08:31, 16 December 2021 (UTC)
OK - I wrote proposal on community noticeboard, but it did not get picked up by any interface admins as far as I see. --ZBlace (talk) 20:25, 24 December 2021 (UTC)
By the fact that changes to MediaWiki:Sidebar can only be made by Interface administrators (you requested a change to the Meta-Wiki Sidebar), so I think it was meant to be right here. --YellowFrogger (Talk β€” ✐) 20:32, 24 December 2021 (UTC)

Update link

Could someone please update the "Community Wishlist Survey" link in the "What do you want to see implemented in Miraheze in 2022? Participate in our Community Wishlist Survey and let us know!" notice to go directly to the new title Community Wishlist for 2022? GTrang (talk) 04:37, 21 December 2021 (UTC)

Apologies for the delay but this was Yes check.svg done yesterday. Agent Isai Talk to me! 12:36, 22 December 2021 (UTC)

Meta:Community portal

As you know, when on mobile (which accounts for most visits) features the Special:MobileOptions , and with the advanced configuration it is shown in the main menu that "community portal" page that it is actually no longer in use and is protected from further editing. Dialog-information on.svg I suggest that someone redirect this page to the Community noticeboard, or build a new community portal linking to the noticeboards, or better, suggest that the user do their own questions in the Community noticeboard or stewards noticeboard. This would perhaps avoid confusion. --YellowFrogger (Talk β€” ✐) 23:47, 27 December 2021 (UTC)

@YellowFrogger: There are plans to revive the Community portal in the near future but I do agree the link should be changed if it redirects users to a page that is not in use. Agent Isai Talk to me! 23:50, 27 December 2021 (UTC)
YellowFrogger, thank you for noticing. That is the former community noticeboard, and contains a historical archive. It's on my radar, but I'm not sure the best way to go about correcting this. We could probably history merge it into Community noticeboard/Archive 1, then create Meta:Community portal as a local Meta Wiki only community discussion forum. It's definitely on my radar, but quite low priority for the moment. Dmehus (talk) 23:51, 27 December 2021 (UTC)
Exactly. I'd like to see you do this or exactly that, (even if that's not a big priority). --YellowFrogger (Talk β€” ✐) 02:27, 28 December 2021 (UTC)
YellowFrogger, Yes check.svg Done the requested history merge at here, with a note to the follow up request at my user talk page (new diff #1 and old diff #2). Additionally, I would just like to thank for Pinus/Matsu for previously providing the suggestion. Note that I have additionally redirected Meta:Community portal to community noticeboard only temporarily if and/or until it is repurposed as a Meta Wiki-specific community discussion portal. Dmehus (talk) 18:51, 2 January 2022 (UTC)

Trust and Safety courtesy notice to Meta administrators regarding BlackWidowMovie0

Meta administrators,

I'm Doug, a Trust and Safety Responder for Miraheze Limited, and I wanted to provide you with this courtesy notice regarding BlackWidowMovie0. The user was the subject of a full service ban, pursuant to the Terms of Use and originally effected by SRE on behalf of the Board of Directors of Miraheze Limited, it has been replaced with a partial service ban by way of local block on Meta Wiki. The local block was originally imposed by, primarily, two different Meta administrators, one of which was myself in a community capacity and the other of which was Reception123 in a community capacity. As articulated here at the user's user talk page, in order to enforce the restrictions of and conditions in place for the user's partial Trust and Safety service ban, as Meta Wiki is the central coordination wiki by which wikis are requested by users, a Meta Wiki block was necessary. Please note that this is in addition to, and not a replace of, the Meta–imposed block, and further that Meta administrators are free, should they choose, to provide notice to the user that their Meta administrator block has been lifted, but that should that occur, the Trust and Safety–imposed Meta Wiki block would remain. The inverse of this would also be true. Many thanks! :)

Should you have any procedural questions related to the above, I'm happy to answer them here. As always, any enquiries relating to this can be sent to the Trust and Safety team at ts(at)miraheze.org.

Thanks,
Doug (talk) 18:59, 2 January 2022 (UTC)

Patroller renounce Request (YellowFrogger)

Hello. Given my edits not adding much, (including peanut edits, reverted, etc) I request that I be demoted from patroller to (none), so that my edits are patrolled and further analyzed by volunteers. I'm inclined to request again just in another month. --YellowFrogger (Talk β€” ✐) 18:43, 9 January 2022 (UTC)

I'm going to mark this as X mark.svg not done. You're showing capacity to learn from what are very minor mistakes in patrolling. Dmehus (talk) 18:59, 9 January 2022 (UTC)
@Dmehus: Agreed, if you think I'm not good, or that I deserve a revocation, remove it and tell me why. --YellowFrogger (Talk β€” ✐) 20:13, 9 January 2022 (UTC)
I was not aware that they had patroller in the first place. Last I checked it had been revoked and if it had been restored I missed that. This user definitely should not be a patroller, although I am glad they recognize that and drew attention to it. I am not sure why the removal request was marked as not done, both because it was a very valid one and was a self-removal of rights request. Naleksuh (talk) 20:22, 9 January 2022 (UTC)
@Naleksuh: Doug recommended me to wait at least (30) thirty days for me to request patroller, I did almost exactly that and he restored by "I maked genuine steps". What I'm pointing out here is because my latest edits need more monitoring from the patrollers themselves, and in order for the red ! (exclamation mark) to come back to my edits. --YellowFrogger (Talk β€” ✐) 20:44, 9 January 2022 (UTC)
Naleksuh, the reason I did not act on YellowFrogger's patroller user group removal requests is because I felt this was a sudden, knee-jerk request. In the past, we've historically held off on such requests, including when Universal Omega had previously requested his interwiki administrator bit be removed (circa November 2020). While the patroller bit can easily be re-added as quickly as it can be removed, on the other hand, we don't want to just be adding and removing bits upon request. If YellowFrogger insists on removing the patroller bit, then I will do that, but they should take that into consideration in terms of future near-term re-requests. Dmehus (talk) 21:07, 9 January 2022 (UTC)
To point out about the previous repeal, expanding on Dmehus comment, this was actually applied by a somewhat controversial admin who doesn't assume the good faith, for a silly thread that doesn't take anything on a Discord server. Users like Universal Omega don't like him very much. --YellowFrogger (Talk β€” ✐) 22:48, 9 January 2022 (UTC)
YellowFrogger, so are you wishing to rescind your resignation request, or are you still wanting to proceed? Thanks. Dmehus (talk) 22:56, 9 January 2022 (UTC)
@Dmehus: Continue the rights even with the above user agreeing to renounce. I already explained to him above the reason for the revocation, although I was wrong in this story, there was no reason to generalize. If you see a negative change to my edits (if they are excessively disruptive) you can revoke the patroller's rights, and of course explain the reasons, as this usually helps to change the course of my type of edit, just as revoking caused me. lately. --YellowFrogger (Talk β€” ✐) 23:12, 9 January 2022 (UTC)

Can't back the English text

I started to translate the paragraph "Π‘Ρ„Π΅Ρ€Π° отвСтствСнности" from English to Russian. When I translated the first sentence and saved it, the rest English text of the paragraph disappeared. I don't know how to back it. RedFox (talk) 19:19, 9 January 2022 (UTC)

RedFox, I've procedurally Yes check.svg moved this request from the talk page language subpage for both greater visibility, response time, and because talk page subpages should generally not be used. An administrator translation administrator should respond to your question shortly. Dmehus (talk) 19:40, 9 January 2022 (UTC)

Please remove my Autopatrolled right

Per the recent events, I believe I need an extra set of eyes. Please remove it from this account. -- Cheers, Bongo Cat ( Talk β€’ Contribs ) 15:40, 11 January 2022 (UTC)

Glad you recognized your mistake, (and will now ask for demoted in the alt account). --YellowFrogger (Talk β€” ✐) 16:30, 11 January 2022 (UTC)
Bukkit, thanks for the reminder that the autopatrolled was still on your alternate account, so Yes check.svg done. Also, I noticed that you're still using your old username for Bukkit (Public), so should be updated. Also, a pro tip, for wikilinks with spaces in them, it's best to replace the page-stretching underscores with spaces. See DannyS712's Easy Link user script, which adds a link to your sidebar (locally or globally, depending on which user JS file you use) and which you may find useful for this purpose. Thanks. Dmehus (talk) 04:57, 12 January 2022 (UTC)

Request for variable

Hi! As the Meta-Wiki here on Miraheze doesn't need to change the interwiki table, concluding that everything here is translated through the translation extension: mw:Extension:Translate, I ask you to disable this function, $wgMinervaAlwaysShowLanguageButton (In Special:ManageWiki/settings#mw-section-localization ManageWiki). This will remove that language icon in the MinervaNeue theme (the current mobile theme here), and will of course avoid confusion, as we don't need another site to be multilingual, as stated above. Sites like MediaWiki already do this, maybe doing it here is good and won't hurt either. The <language> tag will show the page in other languages. --YellowFrogger (Talk β€” ✐) 18:13, 11 January 2022 (UTC)

After a conversation on the Discord server nothing happened here. I X mark.svg even close this here,admitting my indignation, because the same thing will happen with the SandBox that nobody replied, neither refuses nor approves, it is for this and other reasons that, in my opinion, there should not be administrators noticeboard or include in the Meta namespace. I didn't like the posture of users over there, playing with my request while I was being serious. This here is very simple to solve, until the analysis, regarding the addition of this function using only ManageWiki. Definitely, in a few months, some more respected user will place an order and it will be accepted, or else activated on its own, but remember that I was the first to request this here. --YellowFrogger (Talk β€” ✐) 06:39, 12 January 2022 (UTC)
I reopened this here. --YellowFrogger (Talk β€” ✐) 17:57, 12 January 2022 (UTC)
In response to Doug on Disc, yes, I still believe (hopefully) that the next admin who requests this will have the same delay. The scope is clear here, this includes something that probably sites that don't need others disable the language icon in MinervaNeue, and it even shows "This page doesn't exist in other languages", of course it exists, it's translated locally with Extension: Translate. Also, I would recommend that you reply me that you are busy, not following what users were doing (does not include the joking part as you are respectful, more ignoring). You could have asked me to wait, if you said that, I probably lost --YellowFrogger (Talk β€” ✐) 06:56, 12 January 2022 (UTC)
If there's no meaningful objections to this after a week or so, I think we can consider disabling it. Dmehus (talk) 07:04, 12 January 2022 (UTC)
@Dmehus: I reopened. I'm not expecting an immediate response (decline/approval). But this is technical here at Meta, but it's still low priority. --YellowFrogger (Talk β€” ✐) 17:55, 12 January 2022 (UTC)
@Dmehus: Here is the enabled function. There's no reason to regret disabling it here. The site is translated internally and we don't need it there, which is when it's interwiki translated.

--YellowFrogger (Talk β€” ✐) 18:06, 12 January 2022 (UTC)

I'm not very technically proficient with this topic and I'm not in the best position to research, but I would like to see input on the merit here since at face value, it's at least worth considering. --Raidarr (talk) 22:32, 12 January 2022 (UTC)
Dmehus won't be back for a few days now. This here is not of extreme urgency, but I guarantee, it will help not to confuse mobile users. This icon in Minerva says that there are no pages in the other language, while in fact the page is internally translated and the <language> tag does this service by showing the expected languages. --YellowFrogger (Talk β€” ✐) 22:39, 12 January 2022 (UTC)

Extensions

Is there currently a translation administrator available to mark the recent change on the Extensions page for translation? Thanks --YellowFrogger (Talk β€” ✐) 20:03, 13 January 2022 (UTC)

@YellowFrogger: Yes check.svg Done. Agent Isai Talk to me! 21:18, 13 January 2022 (UTC)
Thank you. I also expected an extension like this in Miraheze, however, PageViewInfo is WMF specific and HitCounters doesn't work. PageViewinfo shows views in the last thirty days in &action=info with API modules, like Wikipedia, including a very interesting graph showing the drops/rises of page views ([1]). I'm sure this is better than Matomo (because it shows on each page) then we would see the engagement of a wiki, and the best, each page. HitCounters is more limited and previously (in older versions of MW, including Monobook) they were automatically displayed in the footers of wikis, the functionality was removed, but it is still possible to install, I don't understand why it is not possible in Miraheze, PageViewInfo is perhaps more real/less liar because HitCounters changes page views with each update. I hope that one day, PageViewInfo will be set for all wikis besides WMF and also Miraheze, even if a MediaWiki page shows the installation tutorial. --YellowFrogger (Talk β€” ✐) 21:36, 13 January 2022 (UTC)
The second part of this seems better suited to perhaps the Community Noticeboard for its broad nature, or perhaps inquiry via discord to SRE for faster response.--Raidarr (talk) 22:06, 13 January 2022 (UTC)
This was another statement of mine. --YellowFrogger (Talk β€” ✐) 22:59, 13 January 2022 (UTC)
I don't understand your point, you seem to have gone from asking to mark a page for translation to talking about 2 previously declined extensions. As previously discussed, PageViewInfo is very Wikimedia-specific (as you noted) and HitCounters has a horrible performance issue and was previously broken. I've used Matomo through it's dashboard and it is a very, very powerful and detailed tool but there is currently no way to show public, detailed statistics per T7512. Agent Isai Talk to me! 23:51, 13 January 2022 (UTC)
@Agent Isai: That statement of yours at the end made me curious. There is a way to access Matomo besides that normal page (your dashboard, according to you)? Where do I get access? --YellowFrogger (Talk β€” ✐) 00:03, 14 January 2022 (UTC)
@YellowFrogger: The tool is only available for those with an LDAP account (SRE, Board and T&S). It is not available to normal users due to the amount of personal data that is available on it. Agent Isai Talk to me! 00:32, 14 January 2022 (UTC)
Strange. What personal data does this have? --YellowFrogger (Talk β€” ✐) 00:54, 14 January 2022 (UTC)

Merge Template:Β· into Template:Bullet

Template:Β· inserts a middot which looks extremely similar to bullets (Template:Bullet inserts bullets), so I suggest merging Template:Β· into Template:Bullet (Template:Bullet is a few days older).  AnpangπŸ“¨  03:11, 16 January 2022 (UTC)

I don't support it. Instead, it's better to delete a page. I use {{bullet}} in my signature and it can get in my way. --YellowFrogger (Talk β€” ✐) 03:15, 16 January 2022 (UTC)
I said, "so I suggest merging Template:Β· into Template:Bullet" That means Template:Β· will be turned into a redirect to Template:Bullet and Template:Bullet will be the same, no changes.  AnpangπŸ“¨  03:20, 16 January 2022 (UTC)
Okay, good for explaining. Let's see if something doesn't happen. --YellowFrogger (Talk β€” ✐) 03:33, 16 January 2022 (UTC)
Done. See? Nothing happended, your siggy is still fine.  AnpangπŸ“¨  03:34, 16 January 2022 (UTC)
@Anpang: What do you mean by that? --YellowFrogger (Talk β€” ✐) 03:40, 16 January 2022 (UTC)
@YellowFrogger: You first thought your signature was going to break because Template:Bullet would merge into another template (NOT the middot template into the bullet template) so I said it's fine, nothing happended to the bullet template which also means your signature/siggy  AnpangπŸ“¨  03:51, 16 January 2022 (UTC)
Anpang, with an acknowledgement to YellowFrogger's response, I've Yes check.svg done this, per your request. However, I've not done it as a history merge; I've deleted the two redirect templates as simply unused, or with little use, and because it's better to consolidate transclusions against a single template in order to track and maintain usage. Dmehus (talk) 04:14, 16 January 2022 (UTC)

Request for delete this page

Hello. Please delete the following page:

Thank you --YellowFrogger (Talk β€” ✐) 02:20, 17 January 2022 (UTC)

Yes check.svg Done. Dmehus (talk) 03:25, 17 January 2022 (UTC)

Sitenotice

Hello. It seems that the only user who maintains sitenotice global is Agent. There was supposed to be a warning about involuntarily closed wikis/errors caused by migration, this might help desperate users. If this were to be done today, unfortunately it would be late, as it was supposed to be done earlier. I was even surprised that Miraheze didn't make any post-migration website notices. But now, it seems unnecessary. --YellowFrogger (Talk β€” ✐) 03:14, 17 January 2022 (UTC)

YellowFrogger, So there are local sitenotices, for Meta Wiki-specific announcements, in this case, global central notices, which primarily Stewards administrator, and GitHub repository sitenotices, which Agent takes care of, for SRE-related maintenance or notices (i.e., extension removals), the latter of which can be applied to specific wikis or to all wikis. It's not what clear you're asking for, but this seems to be GitHub repository-related, so closing as X mark.svg cannot be undertaken. Dmehus (talk) 03:23, 17 January 2022 (UTC)
I asked my fellow SRE collogues if we could add a sitenotice for the closed wikis/SVG image issues but they said that it wouldn't be necessary which is why they're not on. Either way, most outstanding issues have thankfully been fixed. Agent Isai Talk to me! 05:19, 17 January 2022 (UTC)

Autopatrol Fan FormuΕ‚y 1

I've seen your translations a bit, and maybe this user has good intentions. He's been editing since last month (joins Discord) and maybe his edits don't need to be patrolled. --YellowFrogger (Talk β€” ✐) 16:31, 15 January 2022 (UTC)

Yes check.svg Done. Dmehus (talk) 06:48, 18 January 2022 (UTC)

Autopatrol

May I please be considered for autopatrolled rights? I'd like to create some redirect pages for common search terms (as discussed in Discord, and within reasonable limits of course) to help users better find sections within articles commonly asked about on Discord. Later, if appropriate, I may be able to help out on some other stuff occasionally as well. Thanks! | -- FrozenPlum (Talk / Email) 01:03, 18 January 2022 (UTC)

I Agreed agree with this.  AnpangπŸ“¨  01:11, 18 January 2022 (UTC)
Reliable and unproblematic editor. I see no apparent need to continue patrolling. dross (t β€’ c β€’ g) 06:39, 18 January 2022 (UTC)
Yes check.svg Done. Dmehus (talk) 06:44, 18 January 2022 (UTC)

Closed wikis

Any translation administrator to mark recent changes for translation? I made some changes talking about the need for local election after an RfC, the content on this page was out of date and I've updated it now with this information.

Soon I will remove the warning {{update}} if necessary

Thanks,
--YellowFrogger (Talk β€” ✐) 00:22, 19 January 2022 (UTC)

Yes check.svg Done ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 07:48, 19 January 2022 (UTC)

Request to delete

Please delete the following pages:

These are all the deleted translation units and there is no point to keep them. Thanks, Magogre (talk) 08:29, 19 January 2022 (UTC)

Hm, so it was this request that led to the deletion of the page (translated through) (although that page doesn't even have much content). I will recreate. --YellowFrogger (talk) (βœ”) 05:09, 20 January 2022 (UTC)
Yes check.svg Done Dmehus (talk) 05:22, 20 January 2022 (UTC)
Dmehus, you deleted the entire translated pages of Staff/hi and Staff/pt-br. I only requested to delete the above pages; others were fine. Magogre (talk) 05:29, 20 January 2022 (UTC)
Magogre, yeah, but that would've been problematic to try and delete all those pages individually. Since the pt-br translation was less than 20% complete, with only the page title translated, this left only the hi translation. As it was only a few short sentences, it was simpler just to delete the page and have it be retranslated. Thanks. Dmehus (talk) 06:06, 20 January 2022 (UTC)
Dmehus, that's fine and it was no big harm but I believe user contributions and their time should be respected. That was my main point and that is why I took my half an hour to filter the above pages instead of just requesting the deletion of Staff/hi, Staff/en and Staff/pt-br. Indeed, it can be translated again. YF has already translated it to pt-br. --Magogre (talk) 07:59, 20 January 2022 (UTC)
Magogre, they are. That's why I thanked ThisIsACreeper1101 explicitly in my log summary. Dmehus (talk) 08:28, 20 January 2022 (UTC)

User:YellowFrogger/Patrolling the edits to main namespace

Hi! Can I move this page: User:YellowFrogger/Patrolling the edits to namespace (main)? Do you agree with this? Thanks! --YellowFrogger (talk) (βœ”) 03:56, 23 January 2022 (UTC)

The way it's written, especially with focus to you and your advice is better suited to the userspace. Personally I think there should be collaboration between multiple meta regulars to make a page written to be suited for the mainspace. --Raidarr (talk) 11:28, 23 January 2022 (UTC)
I will decide to keep it in my namespace. I had even put my signature on the page. --YellowFrogger (talk) (βœ”) 17:49, 23 January 2022 (UTC)
YellowFrogger, I believe this duplicates the guidelines of {{patroller granted}} and the patroller documentation page. I would, therefore, entertain a history merge to Meta:Patrollers, so you can adapt and merge in the non-redundant text there, if desired. Dmehus (talk) 21:54, 23 January 2022 (UTC)
@Dmehus: I created it thinking about these two pages quoted by you, it doesn't talk exactly how to mark a patrolled as patrolled. Also, what is "merge history". Even so, thanks for the reply. --YellowFrogger (talk) (βœ”) 00:00, 24 January 2022 (UTC)

New noticeboard only for blocks/global locks

Hi! What Mirahezians think about a page creation for requesting global locks/local blocks (or rather incidents). We already have SN or Meta:AN, I know, but most threads are not about locks (rarely, it's too messy and late to handle locks). We will rely on this Wikipedia page, or work in a similar way, where the requestor(s) state the reason , the username, and an administrator/bureaucrat/steward/GS will evaluate: Not done or Done. The structure would be similar to the common noticeboards, with a form similar to RfA (automatic). I'm sure creating a page just to resolve blocks would help a lot. Even to the point where I consult you guys to see if I open one (RfC), and avoid snow or out-of-scope. Leave here what you think. Thanks! --YellowFrogger (talk) (βœ”) 05:21, 22 January 2022 (UTC)

There are ideas in the works to divide the noticeboards by function in general (a help desk, maybe a task system, maybe an experimental system to be tried by T&S). I like the spirit of the idea, but I think it would just muddy the waters at the time for something that can be a pretty simply addressed message here, or as often is the case, through discord. The suggestion as described feels just a bit too bureaucratic in light of future changes and the raw specifically of the suggestion. --Raidarr (talk) 09:28, 22 January 2022 (UTC)
@Raidarr: My main goal is to cut down on bureaucracy around response times! It might not be nice to have an extra noticeboard (more complicated to look for), but think about the administrators response time. --YellowFrogger (talk) (βœ”) 04:26, 23 January 2022 (UTC)
It's a noble goal, but I don't see how adding another function split from the official one is really going to do it. I think the only real path on this is to actually re-design how the system works, so users can coherently find the areas they want sooner than later instead of being bounced between various pages. That may be inevitable to a point, but we can do better especially since blocks/global locks are a rare enough appearance on either noticeboard and tend to be resolved promptly enough. What this does is add a bureaucratic element to completing locks where on Meta, the given administrator is probably already made aware either here or IRC/Discord, or with CVT, CVT gets to it when they do and resolve it fine as it is. There is simply not a niche for having this. It's an extra noticeboard for its own sake and I don't believe it sells. You think it would help a lot, I think it offers absolutely nil towards any actual problems. --Raidarr (talk) 11:26, 23 January 2022 (UTC)
@YellowFrogger: There's no need for a drastic change like this. --DarkMatterMan4500 (talk) (contribs) 21:19, 29 January 2022 (UTC)

Patroller request (Hypercane)

Hello, I would like to be considered for the patroller user group. I have been attempting to increase my activity as of recently, and I would like to help out even more (even if it is just one user right added). I have recently helped another user on the community noticeboard. Still in the process of helping them, but I am pretty sure with my prior experience as an administrator elsewhere I would be fit for the position. Thanks for your time. Hypercane (talk) 21:49, 24 January 2022 (UTC)

You can help more with some pages (translations, for example, if you know other languages). I don't see any problem supporting you, even though, the patroller group doesn't have much more than doing the simple thing of marking edits as patrolled. --YellowFrogger (talk) (βœ”) 21:58, 24 January 2022 (UTC)
And participate in RfXs too --YellowFrogger (talk) (βœ”) 21:59, 24 January 2022 (UTC)
I already plan on helping out elsewhere here too, thank you though. Hypercane (talk) 22:02, 24 January 2022 (UTC)
@Hypercane: Yes, if you continue at this pace, you can probably be a Wiki creator in 3 months :) --YellowFrogger (talk) (βœ”) 02:05, 25 January 2022 (UTC)
Yes check.svg Done ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 22:05, 24 January 2022 (UTC)

Disable this variable

Looks like mediawiki.org does that too. --YellowFrogger (talk) (βœ”) 14:34, 29 January 2022 (UTC)

Block for Octahedron foundation

This has been a long time coming, it has been far too long. User has a history of disruptive editing and failure or refusal to get the point. Many users have had a problem with their talk page messages, I looked through them and while some seem mild this is definitely a problem. Requesting a series of increasingly ridiculous wikis. Has already been blocked on testwiki for this same behavior. Final tipping point for this was Requests for Comment/Are bagels good. Naleksuh (talk) 02:44, 31 January 2022 (UTC)

Yes check.svg Blocked partially by Dmehus --YellowFrogger (talk) (βœ”) 02:44, 31 January 2022 (UTC)
Yes check.svg Already done. Dmehus (talk) 02:51, 31 January 2022 (UTC)
I would not regard this as done, as the block applied only applies to the main namespace, and I was proposing a sitewide block. In particular, the users talk page messages and disruptive wiki requests are one of the main problems. However, we will see if the disruption continues and if so it can be expanded to sitewide. Naleksuh (talk) 02:52, 31 January 2022 (UTC)
@Dmehus and Naleksuh: To be honest, Octahedron foundation annoys me. He would constantly leave me nefarious types of messages, but the one thing that got me laughing are his ridiculous wiki requests. I however can add that despite the warnings he received from not only me, but other users, he has failed to heed the warnings and continued the disruption. Also making ridiculously unsourced claims of a user being a "pedo" without sourcing anything, and resorting to vandalism and buffoonery on the Drawn Feet Wiki after he didn't get his wish, especially after he was raging over people not doing what he was commanding there. DarkMatterMan4500 (talk) (contribs) 02:55, 31 January 2022 (UTC)
I'd consider adding User talk namespace, if requested, by you or others, but I'm loathe to consider an indefinite sitewide block on Meta Wiki, given Meta's role as a central coordination wiki, unless absolutely required. If the user's problematic behaviour persists, then yes, I would expand this to a sitewide block, per, well, the user themselves in terms of their continued pattern of conduct. Dmehus (talk) 02:56, 31 January 2022 (UTC)
Oh please do. The disruption has gone on far enough to the point where his questions become quite a nuisance. He's lucky he isn't locked at this time, but he should be very careful the next time. DarkMatterMan4500 (talk) (contribs) 03:01, 31 January 2022 (UTC)
Looking at the the user's global edits, a thread should probably be started at stewards' noticeboard, to be honest. I haven't looked through what percentage of the user's Meta Wiki edits are notionally constructive, but other than spoonwiki and, potentially, this wiki, this is arguably looking more and more like a vandalism only account, to be honest. Dmehus (talk) 03:07, 31 January 2022 (UTC)
For what it's worth (and maybe this would be better suited for such an official thread), entertaining this idea makes me extremely uncomfortable. Making participation on Miraheze a matter of CIR in general is abhorrent from my perspective, especially considering that I see no real history of truly disruptive participation from any of the accounts beyond not getting the point. Every previous competency issue was addressed in the scope of that particular case. Restricting participation on Meta due to disruption is reasonable and necessary, but restrictions that span Miraheze in a wide sweeping motion are more difficult to justify. dross (t β€’ c β€’ g) 09:02, 31 January 2022 (UTC)
When I saw spoonwiki before it was made private, the contents were almost completely spam in nature. I don't consider there to be much saving unless the wiki managed to find an unseen literacy in its private time, though to be fair that lack of literacy was implied in the wiki request which I would not have comfortably granted as it was. --Raidarr (talk) 09:25, 31 January 2022 (UTC)
whats gonna happen to the wiki request Snail destroyer (talk) 13:38, 31 January 2022 (UTC)
DMM, you forgot to mention that he was blocked for abusing rights on (publictestswiki.com), where he blocked me simply for "acting like a nanny", a rather absurd block summary. --YellowFrogger (talk) (βœ”) 03:12, 31 January 2022 (UTC)
@YellowFrogger: I think they already knew that. DarkMatterMan4500 (talk) (contribs) 13:19, 31 January 2022 (UTC)
what about my wiki request? Snail destroyer (talk) 13:47, 31 January 2022 (UTC)
@Octahedron foundation: They were already declined with one of them being approved anyway. DarkMatterMan4500 (talk) (contribs) 13:48, 31 January 2022 (UTC)
what about the one about bagels Snail destroyer (talk) 13:56, 31 January 2022 (UTC)
@Octahedron foundation: It's not getting approved by any wiki creator. Based on what we've seen on spoonwiki and here on Meta, I think 1 wiki is more than enough for you. Agent Isai Talk to me! 16:14, 31 January 2022 (UTC)
But the bagels Snail destroyer (talk) 17:43, 31 January 2022 (UTC)
This needs to be sitewide Naleksuh (talk) 17:46, 31 January 2022 (UTC)
As Dmehus said above, Meta is a central emergency wiki where people who need help can come here. That's why a full block shouldn't be necessary. Did the user experience problems the other day, if he was totally blocked? --YellowFrogger (talk) (βœ”) 17:52, 31 January 2022 (UTC)
I have issued a warning. If they continue with the disruption I will consider a sitewide block. Reception123 (talk) (C) 06:20, 1 February 2022 (UTC)

Request for rollbacker

Meta:Community portal in Sidebar

Any system administrator or any other users who have sufficient privileges to edit the MediaWiki namespace? I propose to link the page Meta:Community portal to Noticeboards in MediaWiki:Sidebar.

For example, like this:

*Noticeboards
**Community noticeboard|Community noticeboard
**Stewards' noticeboard|Stewards' noticeboard
**Meta:Administrators' noticeboard|Meta Administrators' noticeboard
**Meta:Community portal|Meta Community portal

I don't see great despair in putting the link, but because this page is newly created and many users are not aware of it. That said, I think this would help a lot. --YellowFrogger (talk) (βœ”) 00:36, 8 February 2022 (UTC)

For continuity I think it would make sense. At the same time I'd strongly encourage a look at renaming the RfA process to get that out once and for all. --Raidarr (talk) 01:26, 8 February 2022 (UTC)
Makes sense and will be useful for quick navigation. --Magogre (talk) 03:00, 8 February 2022 (UTC)
This would be quite beneficial for navigation. β€” Arcversin (talk) 01:19, 9 February 2022 (UTC)
I 100% support this action. I mean, it makes sense doing so. DarkMatterMan4500 (talk) (contribs) 02:08, 9 February 2022 (UTC)
Well this here a while ago and it looks like 4 unique editors (5 with me) agree with this. Even so, what will be done? --YellowFrogger (talk) (βœ”) 21:19, 12 February 2022 (UTC)
This has been Yes check.svg done. The concern I have, though, is that the similarly named Meta:Community portal may be confusing with community noticeboard and actually increase the workload for Meta patrollers moving threads to the correct community noticeboard, but it's a reasonable request, and, I think, placing it at the bottom of the noticeboard lists should help to minimize this. We can monitor this and course correct accordingly. As an administrative note to a portion of the unaddress preamble to this request, it wouldn't be appropriate for a system administrator to make this edit to the MediaWiki:Sidebar. Meta:Administrators' noticeboard is indeed the best venue, and Meta administrators the best functionary to action this request. Dmehus (talk) 18:22, 13 February 2022 (UTC)
@Dmehus: Thanks. But the only thing that intrigues me is the lowercase "Meta community portal" (C). --YellowFrogger (talk) (βœ”) 22:12, 13 February 2022 (UTC)
That was, in part, intentional and by design. Since Community noticeboard is capitalized, the lowercase "c" in Meta community portal may help to distinguish between the two similarly named portals. As well, grammatically speaking, it is more consistent with the practice of not capitalizing the name of the noticeboard. Dmehus (talk) 22:26, 13 February 2022 (UTC)

Grant Local IP Block Exemption

Deletion request(s)

Hello. Please delete the following pages:


These are all the unused/abandoned translation units. Thanks. --Magogre (talk) 08:29, 15 February 2022 (UTC)

Yes check.svg Done Reception123 (talk) (C) 09:52, 15 February 2022 (UTC)
Thank you Reception123. --Magogre (talk) 11:09, 15 February 2022 (UTC)

Block for YellowFrogger

YellowFrogger is currently engaged in an edit war at User talk:Agent Isai. Multiple users have reverted their edits yet they continously reinstate and make more. Agent Isai is within their right to revert per w:WP:OWNTALK but YellowFrogger continuously edits and is well over the three-revert rule. Naleksuh (talk) 01:00, 16 February 2022 (UTC)

I have taken emergency action in light of the edit war and YellowFrogger's significantly declined behavior as well as delays in local sysop action. It is likely an unprecedented move and I apologize if it was an overstep. It is either way subject to proper local administrator review. Disruption should be ceased; any sockpuppet action to circumvent the block as retribution will be noted as well as actioned by global lock as abuse of multiple accounts. --Raidarr (talk) 01:06, 16 February 2022 (UTC)
If it's not too much, YellowFrogger has been too disruptive beyond any comprehensibility for quite some time now. If yesterday's incident regarding Ninox's similar behavior like voting again with a sock wasn't bad enough, wait until you see the disruption they added to my talk page, which I have reverted the moment it was set there. I am EXTREMELY disappointed in this user's behavior. I would probably ask YellowFrogger to seek some help and take a load off by taking a break from Miraheze for a while until he realizes what he has done wrong, and how he can come to terms of his recent wrongdoings. What I am essentially saying from this reply is for him to do something else for a while, and take a clean start and start all over again (that is, if he could get permission to have a fresh start). I do hope he comes back with maturity and competency. DarkMatterMan4500 (talk) (contribs) 01:22, 16 February 2022 (UTC)
User:Raidarr, global sysop actions are not supposed to be indefinite. It is supposed to be for a short time period, during which a local sysop can choose to extend it. Naleksuh (talk) 01:42, 16 February 2022 (UTC)
My impression was that this block was meant to be reviewed by a Meta sysop and the block reason would probably be amended either way so I guess this is fine for now but indeed, I would advise Raidarr to perhaps not indefinite block users on other wikis that are not Meta. Agent Isai Talk to me! 01:48, 16 February 2022 (UTC)
The intention is for it to be reviewed and replaced, in which the time period is deliberately unspecified; noted for future cases however, as one of likely multiple advisories given the nature of the action. If it is not addressed when I return tomorrow I can look at a shorter time, perhaps the week duration that was issued on login wiki by Doug. --Raidarr (talk) 01:51, 16 February 2022 (UTC)
@Raidarr I have reviewed the block, and I approve of it, and have reblocked showing as such and have denied their unblock request. Zppix (Meta | talk to me) 04:16, 16 February 2022 (UTC)
Support an indefinite block. I was surprised that they weren't (b)locked in the first place. Totally unacceptable behaviour. --Magogre (talk) 02:09, 16 February 2022 (UTC)
First off, don't use bullet points, this is a request, not a vote or public forum. Second, the user has already been blocked indefinitely but by a global sysop. I personally wouldn't have placed an indefinite block at all but it's outside of the global sysops policy to do so-it would make sense for a meta sysop to either set an expiration date or leave the parameters as is. Naleksuh (talk) 02:12, 16 February 2022 (UTC)
I agree with Naleksuh above that bolded bullet points aren't appropriate for requests for assistance from a Meta administrator. The community can advise Meta administrators on courses of action, and, occasionally, in the past, Meta administrators have delegated decision-making to the community on the best outcome for users, but in such cases, the authority to make that delegation to the community rests with Meta administrators and Stewards (depending on the type of conduct and outcome). I have reviewed YellowFrogger's recent conduct with Agent Isai. First of all, Agent Isai should have been clearer in his edit summaries, and ideally provided a warning on why YellowFrogger's edits were being reverted. Indicating "transparency" (one word) in an edit summary is not that helpful to someone whose native language is not English. A better option would've been to message him here, advising him how to properly edit his own comments where replies have already occurred (see also: this English Wikipedia editing guideline on the matter) by striking through his comments and adding his amended comments. Nevertheless, YellowFrogger's continuing to edit war was also highly problematic. Raidarr's action as a Global Sysop seems fine to me, and the appropriate venue to review the action is indeed Meta:Administrators' noticeboard. I do think a block on Meta Wiki is needed, but, at the same time, YellowFrogger is currently subject to an indefinite Steward-imposed global user restriction restricting him to creating any alternate accounts he requires logged in and, ideally, on Meta Wiki. Additionally, he is also subject to a Meta administrator-imposed editing restriction limiting him to using only his YellowFrogger account on Meta Wiki. Thus, an indefinite sitewide block would be at cross purposes with the aforementioned user restrictions. I am leaning towards either (a) an indefinite partial block from one or more namespaces (this is where the community's input would be helpful in helping to define the namespaces), with the option to appeal not sooner than three (3) months from the date of imposition or (b) a three (3) month partial block one or more namespaces (User talk namespace certainly, but likely (Main) and Meta namespaces as well) Dmehus (talk) 03:43, 17 February 2022 (UTC)
I would support (a) where he is blocked on all namespaces indefinitely (but not sitewide blocked which would hinder him from creating user accounts, in accordance with the globally imposed restriction) and can appeal in 3 months. I think YellowFrogger should take some time off Meta to reflect on his actions, cool off, and once he's ready to appeal in 3 or more months, he can come back and will be gladly received by the community. Agent Isai Talk to me! 05:24, 17 February 2022 (UTC)
If the partial block is for all namespaces simply to allow the creation of alt accounts publicly on Meta, that would be fine with me. Reception123 (talk) (C) 06:57, 17 February 2022 (UTC)
Except that wouldn't work, because a partial block on all namespaces vs. a sitewide block doesn't change anything here. Instead it's in the "block account creation" option. Naleksuh (talk) 07:00, 17 February 2022 (UTC)
We could block indefinitely from all namespaces, unchecking the "account creation" box. Though I agree there's not really a significant need for him to create alternate user accounts, this may invite further abuse or breaching of that restriction. I agree that it's best for YellowFrogger to not be able to edit on Meta Wiki, but since Meta Wiki is where wikis are requested, for mainly technical and transparency reasons, and because it's where certain other special page functions occur (i.e., global renames, logging in to Phabricator, modifying OAuth consumers, etc.), there is a need for him to have access to those functions, but no ability to edit on Meta Wiki, indefinitely, with the opportunity to appeal after at least three months. Dmehus (talk) 07:05, 17 February 2022 (UTC)
Would it be in consideration to block the bot and alternate account to avoid socking? SoyokoAnis 18:29, 17 February 2022 (UTC)
They are not blocked just for being other accounts unless they were created after the block or are being used to evade etc. Otherwise, there is no evidence that the block was necessary to prevent damage. Naleksuh (talk) 18:32, 17 February 2022 (UTC)

Block for Andyyeung7

As seen by their recent contributions I believe this user needs a block imposed on their account due to their disruptive behavior and editing. Hypercane (talk) 02:12, 16 February 2022 (UTC)

Hypercane, the user seems to have stopped the behaviour. In any case, given that the problems seem to have just been (repeated?) out of scope page creations, what the user needed was a clearer warning, which I've now Yes check.svg done. Thanks. Dmehus (talk) 03:57, 17 February 2022 (UTC)
Ah okay, well that works out too. Thank you Dmehus. Hypercane (talk) 12:07, 17 February 2022 (UTC)

Resignation of rights

Please remove my patroller and translationadmin flags. Thanks. --Magogre (talk) 04:19, 18 February 2022 (UTC)

Magogre, as with your similar request at stewards' noticeboard, Yes check.svg done, with regrets and thanks for your service. I have left you with autopatrolled, as there should be no need to patrol your edits, but this can be removed also, if you request it. Dmehus (talk) 04:28, 18 February 2022 (UTC)

Moderation extension

I've enabled the Moderation extension.

  • Should autopatrolled or autoconfirmed users, or both, be auto-moderated?
  • Who should have the ability to moderate edits? Administrators, or administrators and patrollers? Dmehus (talk) 20:12, 20 February 2022 (UTC)
I think autoconfirmed users should be auto-moderated unless sleeper socks begin to spam Meta in which case autopatrolled would be better. As for who should be able to moderate, I think patrollers are trustworthy enough to help moderate edits. Agent Isai Talk to me! 20:15, 20 February 2022 (UTC)
X mark.svg Removed. Please do not add extensions as a Steward on Meta without the consent of a bureaucrat. John (talk) 20:19, 20 February 2022 (UTC)
I agree, this should not have been enabled. Both because we do not need a repeat of the report extension business and because stuff like this should have community consensus or at least a Meta crat. Naleksuh (talk) 21:05, 20 February 2022 (UTC)
Wow, ESPECIALLY not as this extension makes a very dramatic major change to the way the entire premise of wikis operates. This would need a massive consensus to be enabled, not just enabled by a bureaucrat and definitely not by a non-bureaucrat steward. Naleksuh (talk) 21:06, 20 February 2022 (UTC)
We've rate limited IP edits for now and we're working on some less impacting mitigations using what's available to us. ~ RhinosF1 - (chat)Β· accΒ· c - (     online) 21:07, 20 February 2022 (UTC)
More changes from another non-bureaucrat! Naleksuh (talk) 21:08, 20 February 2022 (UTC)
That has been far from clear, given the role Meta Wiki plays as the central coordination wiki, and the historical practices in which Meta Wiki has operated. Indeed, we have even had SRE performing ManageWiki changes in the past, though I agree with Agent Isai that an RFC is not necessarily needed. It can be either an RFC, or a community discussion at Meta:Administrators' noticeboard or Meta:Community portal. Dmehus (talk) 21:17, 20 February 2022 (UTC)
Agreed, this is the sort of thing that needs an RfC to be enabled. β€” Arcversin (talk) 21:08, 20 February 2022 (UTC)
Perhaps not a full blown RfC but definitely an AN discussion. Agent Isai Talk to me! 21:09, 20 February 2022 (UTC)
No, definitely an RFC. This extension seeks to change the entire way the wiki operates. Naleksuh (talk) 21:10, 20 February 2022 (UTC)
The extension's primary use is generally only for temporary site protection, not permanent protection. Agent Isai Talk to me! 21:11, 20 February 2022 (UTC)
Even if so, there would need to be an RFC to establish the conditions for use, what group skips moderation, what group can moderate, etc. Also, turning on moderation is kinda like giving in to the vandals. β€” Arcversin (talk) 21:22, 20 February 2022 (UTC)
Who remember this?--MrJaroslavik (talk) 21:48, 20 February 2022 (UTC)
For the record, a Meta bureaucrat did authorize that extension to be enabled. Subsequent discussions informed the decision to revert the change. I don't see a direct comparison there. Dmehus (talk) 21:50, 20 February 2022 (UTC)
For the record... There was not consensus for adding that extension... As like in this case...--MrJaroslavik (talk) 21:53, 20 February 2022 (UTC)
Well, no. The discussion you linked to was the subsequent discussion. In the previous discussion, several participants, including myself and Reception123, all agreed with enabling the extension, and the Meta bureaucrat viewed that as either (a) sufficient consensus to enable or (b) non-controversial enough so as to not require a fuller discussion. Subsequent to that, a couple users dissented, so a fuller discussion was had. Southparkfan's close was complicated, but essentially said consensus tended to be trending toward enabling, but was not yet there in terms of some of the logistical items. In any case, the extension was subsequently removed pending a third, fuller discussion, but since then, due to the extension's limited feature set, there's been no desire to re-propose enabling it. Dmehus (talk) 22:04, 20 February 2022 (UTC)
Lol, I see no change in your behavior has occurred... In that discussion/request was only Redmin, you and Reception, it really is not consensus and i will be quiet about your favourite "non-controversial"... Extension was enabled about 30 hours after request...--MrJaroslavik (talk) 22:14, 20 February 2022 (UTC)
I completely agree with MrJaroslavik. That report thing was awful and thank god it is removed. We do not need a repeat of that. Naleksuh (talk) 00:38, 21 February 2022 (UTC)
Let's be smart about this and not try to cancel Doug over something as trivial as enabling the moderation extension (which he definitely shouldn't have enabled to begin with), or over something that occurred about a year or so ago. I may disagree with Doug on certain things, but having this weird obsession about his past actions is just absolutely not needed here, and is practically an unhealthy habit. DarkMatterMan4500 (talk) (contribs) 00:46, 21 February 2022 (UTC)
I am not "cancelling Doug". Simply saying that someone should not have did something is not cancelling, it is simply holding someone accountable for their actions. The only way to avoid that is to do nothing. There is no "cancelling", this isn't 4chan. Naleksuh (talk) 05:55, 21 February 2022 (UTC)
If someone repeats their mistakes and continues his arrogant behavior (on-wiki), should we remain quiet? Please stop defending him at all costs...--MrJaroslavik (talk) 06:09, 21 February 2022 (UTC)
Please stop defending him at all costs There are two ways to interpret this. Are you saying that they were defending at all costs and need to stop, or that they should stop at all costs? Naleksuh (talk) 06:13, 21 February 2022 (UTC)
DMM don't want see issues and defending Doug always, so i guess it's first option.--MrJaroslavik (talk) 06:38, 21 February 2022 (UTC)
I think it is a shame that this topic must once again be repeated after the last time which caused a lot of issues and argument. First of all I think that some people here have been overreacting and have turned this 'scandal' a bit more personal than it should be. I think that the main issues here is that there is no written policy about this and that invites for confusion and for people not to know: 1) when a Steward can enable an extension (if ever) 2) when a Bureaucrat can request to enable an extension without prior community consensus 3) when Community consensus is required to enable an extension. In my opinion in this case I do not think it was necessary to enable this extension as Steward however in an emergency it may have made sense for a Bureaucrat to authorise it without prior community consensus. This is however just an opinion which demonstrates that it may be unclear to people when extensions can be enabled which is why a policy would be best. If people agree I would be willing to attempt to write one for this. To conclude however I do not believe that Stewards should be enabling extensions in the vast majority of cases as there is no justification for it generally. --DeeM28 (talk) 06:17, 21 February 2022 (UTC)
Hmm, there is no policy... It was discussed year (?) ago and he know about it. Issue is not on my/our side, issue is on his side, he is repeating same mistakes as like before (desysop, de-steward requests and others discussions)....--MrJaroslavik (talk) 06:38, 21 February 2022 (UTC)
DeeM28, I agree with your thoughtfully considered points. Meta Wiki is a special wiki for a couple reasons. For one thing, it is the primary public facing website for Miraheze. For another, Meta Wiki is used for global administration of wikis, global blocks, global account administration, and wiki administration and creation. As such, Meta bureaucrats, a locally elected role, cannot have ManageWiki access. Part of the confusion here stems from the unclear historical practices. Indeed, in the past, it was somewhat common for Site Reliability Engineering team members, a non-elected technical role, to perform certain actions, particularly when Stewards were not active at the time or because it was unclear. My understanding was that I should normally obtain a Meta bureaucrat's authorization to enable an extension, notwithstanding cases of crosswiki abuse where the IP hopping was persistent, sustained, and blocks were ineffective. So that's why I enabled the extension, temporarily, and started this discussion to see whether the community agreed with that and to define how it should operate. In any case, the extension configuration would have taken too long to configure, so was just about to revert the addition when I saw John had reverted it for me. I hadn't realized he was even available, otherwise I would have asked him (Reception123 had already gone to bed) for his thoughts or if he thought there was a better approach. Going forward, though, I'll ensure that a Meta bureaucrat authorizes any extension changes or asks that it go to a community discussion first, even cases of counter-vandalism mitigation prevention reasons. Dmehus (talk) 06:40, 21 February 2022 (UTC)
I think it's definitely fair to ensure from now on that a Meta bureaucrat authorises any extension changes and that would be a satisfactory resolution to this dispute/thread. A Meta bureaucrat would then decide whether the extension should can be authorised by them alone or whether a discussion is needed, and if they feel like the latter is needed, then they would let the Steward know that they don't authorise the change. Reception123 (talk) (C) 06:57, 21 February 2022 (UTC)
I think ^ from Reception is a reasonable take, although in my opinion there are only two valid scenarios that would entail a Steward's managewki intervention.
One is an emergency. Immediate action to stop an unprecedented extreme issue. I believe any Steward should be able to take action as soon as they can. The scenario of this thread was not an action I believe justifies that.It meant well, but it needs to set a higher bar.
The second is non-emergency, at which point surely the given Steward can afford to wait. If they can wait, they can discuss first and act later, attaining consensus in the normal manner or if it is still urgent, still by making the inquiry in a public venue. Anything from 'somewhat important' to say, a Meta RfC where a steward should be requested to enact a ManageWiki change result.
I don't think there's really room where a Steward should request a bureaucrat/bc-steward for input that doesn't also entail community discussion and the first case should be absolutely temporary until a community discussion removes it/ratifies something longer term. I do agree in a wider principle that a) stewards should discuss with each other where available and b) if a meta bureaucrat, especially a meta bureaucrat + steward is available, they should be consulted if there is evidence they are just about immediately available even in an emergency which did seem to be the case here and would have avoided the current fuss. I don't think this was handled optimally, but if we can draw a clear line here and Doug follows it, the issue needs to go any further than that. But it's clear that as a community we have various different opinions where to draw the line for action, so right now I'd find it hard to come out with a concrete advisory if I were treating all statements here as equal. --Raidarr (talk) 14:34, 21 February 2022 (UTC)

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ @Reception123 and Dmehus: I think this sounds a bit fair. And regarding what Naleksuh and MrJaroslavik said above: No, I wasn't trying to defend what Doug did about a year or so ago or the fact that he questionably enabled that extension (which really shouldn't have happened to begin with), nor was I attempting to silence you guys from having an opinion (I mean, anyone is welcomed to vent out their frustrations, and/or voice out other concerns for that matter). @MrJaroslavik: If I may also add that you and Naleksuh had every right to point out what he was doing wrong, but perhaps try to keep an open mind (which I know for a fact that you and Naleksuh are indeed open to any potential ideas that might work), but it does annoy me that I have to repeat what I said from a year ago, and seeing the latter has been more aggressive than usual, which really left me baffled. All in all, you might want to consider looking at the reply I left here a bit more carefully, rather than jump to conclusions saying that I'm defending his actions. The recent action he did make really did baffle me, and I had absolutely no idea what his thought process was in enabling that said extension. DarkMatterMan4500 (talk) (contribs) 14:43, 21 February 2022 (UTC)

Interface administrator for Arcversin

I'm pleased to be able to submit this request for Meta interface administrator for Arcversin, as it's a role tailor made for him given his extensive CSS and JavaScript knowledge. His primary focus will be on maintaining, de-Wikipedifying, and customizing existing (including, but not limited to, Twinkle) and new gadgets. He understands that changes to MediaWiki:Common.css and MediaWiki:Common.js have widespread impacts to everyone, so should have at least a brief discussion at Meta:Administrators' noticeboard, typically one in which a Meta administrator would have participated, and that Meta administrators are those locally elected functionaries which will add local sitenotices to discussions, though they may delegate this function to non-elected interface administrators in their discretion. I will let Arcversin add to his rationale for requesting the permission, confirm that he has a strong password for his account, and then let any bureaucrat grant the permission. Dmehus (talk) 17:46, 21 February 2022 (UTC)

I can confirm that my account has a strong password (and 2FA). In the immediate future, I plan on preparing a version of MoreMenu for use on Miraheze. β€” Arcversin (talk) 17:58, 21 February 2022 (UTC)
I think this would be reasonable, especially to gather the grassroots support for becoming a full administrator. The primary issue of trust I don't think is a problem here, and I support it as a method towards deeper and more prolific involvement. --Raidarr (talk) 18:00, 21 February 2022 (UTC)
This seems like a reasonable request with a sensible use case and made by a trusted user who has JS and CSS knowledge. Yes check.svg Done. Reception123 (talk) (C) 19:54, 21 February 2022 (UTC).
Twinkle has already been de-Wikipediaified, there's nothing more to do there. Although I am the primary person responsible for it there is certainly no reason why any other interface-admin cannot edit the associated pages. But there's not any de-Wikipediaifying or maintenance to do right now, so I'm not sure why that was brought up as an example. Arcversin, if there is something not working with Twinkle, any reason why it has not been brought up to me or somewhere else in a public forum I could have seen it in beforehand? Naleksuh (talk) 02:07, 23 February 2022 (UTC)
Twinkle is working just fine, I believe Doug was just using that as an example since it's pretty well known. β€” Arcversin (talk) 03:13, 23 February 2022 (UTC)

Can OrangeHoney be added as a gadget

Can this be added as a gadget? (i will add more to it) It's basically a lite version of MoreMenu (not inspired by MoreMenu at all). MoreMenu has small and incorrectly aligned text in some labels for some reason, so this fixes it.

Screenshot 2022-02-28 171628.jpg (why is Move the only one with big text?)  AnpangπŸ“¨  10:14, 28 February 2022 (UTC)

@Anpang: I've fixed a security exploit (Cross-site scripting to be exact) in the script you linked, specifically, the URL of the current page wasn't being escaped before inserting it into the page to be used as a purge link. This would allow someone's account to be hijacked if they clicked on a specifically crafted link. β€” Arcversin (talk) 19:31, 28 February 2022 (UTC)
Oh.  AnpangπŸ“¨  01:02, 1 March 2022 (UTC)

User:Woman Zeke making legal threats

In Special:RequestWikiQueue/23290, User:Woman Zeke made legal threats towards Miraheze and/or his fellow editors. β€” Arcversin (talk) 15:50, 5 March 2022 (UTC)

Arcversin While it is clear that it's a legal threat, it's very vague/non-specific and doesn't seem serious at all. Therefore, I don't think it's currently necessary to add more to your response on the request for them to stop. If they continue or escalate that could be dealt with then. Reception123 (talk) (C) 16:06, 5 March 2022 (UTC)
I agree with Reception123. This is just trolling, in my view. If the user continues to create nonsense wiki requests, they can be blocked for a period of time, along with a final warning, not to engage in spamming the wiki request queue. Dmehus (talk) 17:18, 5 March 2022 (UTC)
I suppose that makes sense considering this wasn't made within the context of a BLP article or similar. β€” Arcversin (talk) 17:22, 5 March 2022 (UTC)
I was actually talking to Agent Isai privately regarding that account the other night, and it looked pretty odd. DarkMatterMan4500 (talk) (contribs) 17:37, 5 March 2022 (UTC)
In reply to DarkMatterMan4500's comment, it's indeed odd that this account was created nearly a year ago to the day, but has made almost no global edits until recently and only just recently demanded Miraheze create a wiki for them, not specifying what their wiki is about or really, well, anything. I have to wonder if it's a sleeper sockpuppet of someone, but no idea who.
In reply to Arcversin's comment, yes, that's absolutely true, but also if it were a serious enough legal threat, we have the Trust and Safety team that review complaints, assess their legitimacy, and respond accordingly. Dmehus (talk) 17:54, 5 March 2022 (UTC)

Removal of the bot flag for MirahezeBots

Could any bureaucrat kindly remove the bot flag from MirahezeBots on Meta Wiki, in line with the Meta:Bots discretionary guideline page? The bot is clearly not active on Meta Wiki, having made fewer than five (5) edits, and no log actions, in the preceding twelve (12) calendar months, the most recent of which was more than six (6) months ago? Even if it were suddently active again, this level of activity does not qualify, in my view, for, or does not necessitate having its edits suppressed from RC. Dmehus (talk) 20:24, 5 March 2022 (UTC)

Note I have separately Yes check.svg added the confirmed flag it'll require to update its OAuth consumers. This should be sufficient, consistent with Void-bot. Thanks. Dmehus (talk) 20:29, 5 March 2022 (UTC)

News section

Can admins add:

  • March 2022: Miraheze now has 6,000 wikis!

to the News section of the main page, and archive

  • December 2019: Miraheze upgraded to MediaWiki 1.34!

Silicona (talk) 07:41, 28 March 2022 (UTC)

That number will likely drop back down to 5,000 once closed wikis are deleted and once all inactive wikis which were affected by the Recent Changes/inadvertent closure bug are finally closed. Agent Isai Talk to me! 14:01, 28 March 2022 (UTC)
Yeah, I think for number of wikis it's a bit complicated due to the deletion issue but either way we could probably stick to larger numbers for news, like 5000-7500-10000 (hopefully). Reception123 (talk) (C) 18:45, 28 March 2022 (UTC)
I agree. This is very minor and not worthy of a mention in the news section. We've added a continuously updating (may require an ?action=purge to the page) counter showing our total number of wikis, so marking this as X mark.svg not done. Dmehus (talk) 03:23, 29 March 2022 (UTC)

Request for autopatrolled (Silicona)

At the time of writing, I made 840 edits, 396 of which are on Meta. I am an admin in 3 wikis and bureaucrat in Test wiki and Numberpedia, so I would like to request autopatrolled right for myself on Meta. Silicona (talk) 17:17, 28 March 2022 (UTC)

A huge number of your edits are edits which "translate" pages into British English, why did you do that? These pages are already in English so there's no need for that. Agent Isai Talk to me! 17:21, 28 March 2022 (UTC)
Silicona, as I explained that I didn't this block was not needed and a bit BITEy to newcomers, the fact that you created many British English translations of source pages, which, arguably, should use British/Canadian English is a bit of a problem. This demonstrates a bit of a competence is required issue in that it would've been preferred you reach out to us through our official communication channel, IRC, or our secondary communication channel, Discord, and engage with us on ways to volunteer on Meta Wiki. As well, you should also note that there's no set edit count for autopatrolled to be granted. Each administrator will have slightly different criteria, but generally speaking, users must typically demonstrate at least two and, ideally, all three things. Firstly, they must be active, but active in a constructive way. Secondly, they should know Meta Wiki's purpose and scope. Thirdly, they should, and ideally, must, understand talk page guidelines and conventions. Some level of editing is required to demonstrate these things, and I don't want to quantify it, as there's no set number. Admittedly, for unilingual users, they are not able to demonstrate activity through translations of pages, but there are other ways, such as assisting users on community noticeboard, fixing lint errors and other things, etc., competently. Accordingly, this is X mark.svg not done, but I would reconsider a request for this permission after at least thirty (30) calendar days in terms of re-assessment, or perhaps even a bit sooner, but again, it will be up to you to demonstrate the above. Dmehus (talk) 03:14, 29 March 2022 (UTC)

Cleanup unused rights from the moderation extension

There are a number of unused user rights (plus a group) left over from when the moderation extension was briefly enabled, which should be cleaned up eventually. β€” Arcversin (talk) 17:41, 28 March 2022 (UTC)

Arcversin, I have been wanting to clean this up. Having spoken to John in his dual Meta bureaucrat and steward capacities, he had no objections to this, as it is essentially cleanup from a reversion of an added extension that ended up being solved using more conventional CVT methods. Dmehus (talk) 17:21, 2 April 2022 (UTC)
Yes check.svg Done Dmehus (talk) 17:35, 2 April 2022 (UTC)

Reception123 and edit warring

There is an issue on User_talk:Naleksuh. The talk page owner has removed a thread that they do not want on the talk page per OWNTALK and not wanting the content on the talk page, but the person who posted it is continuously reinstating it, twice, citing fact that OWNTALK is technically not a policy, but without any indication of any policy that prohibits removal.

Since removal of messages is permitted both by Miraheze and by common sense, with no policy prohibiting removal, and the user demanding that they be archived in the way they prefer on someone else's talk page just because they are a sysop, their continuous reinstatement of the removed material is edit warring (ironically, the message they are trying to reinstate complains about alleged edit warring for someone else, so why are they themselves edit warring?) and may get close to 3RR territory as they have already reinstated it twice with no grounds to do so. Naleksuh (talk) 18:18, 28 March 2022 (UTC)

This is getting ridiculous with what I am seeing here. If I can recall correctly, you also did the same thing too, which is unexpected behavior coming from a patroller with 2 additional advanced permissions. This is certainly getting to a certain point where it's nauseating, and the fact that you suddenly wrote this out of the blue makes this extremely childish, and it needs to stop. DarkMatterMan4500 (talk) (contribs) 18:24, 28 March 2022 (UTC)
No, I've never done any such thing. If someone removes a comment of mine from their talk page I do not reinstate it. Naleksuh (talk) 18:29, 28 March 2022 (UTC)
Then why revert back-and-forth with another user, and with Reception123? I'm sorry, but this whole thing about you and this edit-warring crap you have makes me look like a saint by comparison, except it also makes me look like the better person when comparing the edit-wars that have occurred. DarkMatterMan4500 (talk) (contribs) 20:04, 28 March 2022 (UTC)
For the sake of transparency, I think it's okay that Reception123 restored the warning he gave you so that administrators can refer back to it easily in case of any future discussions which may require that this warning be pulled up. If anything, I would stress the importance of clear communication here. I haven't seen any attempts, whether on IRC or on-wiki to remediate this long-standing issue. I would urge you and the administrators to come to an agreement to prevent this needless back and forth that's going on. Agent Isai Talk to me! 18:27, 28 March 2022 (UTC)
(edit conflict)First of all, while I will admit some people have cited Wikipedia policies in the past, Meta is not Wikipedia and as such it does not make sense for us to follow all of their policies. Some Wikipedia policies are rather common sense and uncontroversial, but this one in my view is not. Therefore, I do not believe that citing Wikipedia policies is a solution to the problem here. Now, to the actual issue. I'd first like to point out that in my view not allowing users to remove threads without archiving is a convention here on Meta and I have consistently prevented users from doing so without any comments from any user saying they had an issue with it. There are two main rationales behind this. The first one is that especially when a warning is concerned, the user being warned should not be allowed to completely remove such warnings in an attempt to 'hide' them from users or administrators by forcing them to look through all the revisions. Second, it's not fair to the people participating in the conversation to have their comments completely removed from the talk page and only accessible through revisions. I see no good reason for why users should be allowed to dispose of talk page messages. To finish however, if you wish to challenge this I would propose a Meta RfC to settle this matter more clearly, otherwise I think the convention should stand as it has been applied to users in the past without issue or comment. --Reception123 (talk) (C) 18:30, 28 March 2022 (UTC)
Meta is not Wikipedia and as such it does not make sense for us to follow all of their policies It is policy on Wikipedia, but is common sense just about anywhere. Plus, "it's not a policy, it's a guideline" goes against what you are saying, because there is neither a policy nor a guideline to support what you are doing. In fact, the opposite. If you want to read an essay, you can look at w:Wikipedia:Don't restore removed comments. In particular, this part : "The comment is still in the page history, so it is not necessary to keep it visible just to show that the user received the message. It is also wrong to force them to keep it there as a sort of 'badge of shame'. "
Second, it's not fair to the people participating in the conversation to have their comments completely removed from the talk page and only accessible through revisions. It's not fair to users to tell them how they can and cannot archive their talk page. I've always archived by removing from the page for 2+ years and longer, and you are basically trying to tell me that I will have to stop on this wiki only.
Reception123's entire case basically hinges on them being a sysop, which is absolutely unacceptable. Sysops are accountable to the community, and the sysop toolkit is not a way for users to make threads more important or to exhert some authority over other users and how they manage their talk pages.
Also, none of this refutes the central point: While users can remove comments from their own talk page, and reverting pages in your own user space is generally exempt from edit warring, continuing to restore them is edit warring. Reception123 is encouraged to stop edit warring and not apply weak conventions to other talk pages, especially not when dealing with their own messages. To quote Thomas Hobbes, No man is a fit arbitrator in his own cause. Naleksuh (talk) 18:58, 28 March 2022 (UTC)
Regarding the policy argument, it has clearly been recognised that Meta lacks a lot of written policies and instead functions by what we refer to as 'conventions'. You keep quoting Wikipedia essays but as I have said, the convention on Meta has always been to insist that users archive talk page messages rather than remove them. I don't see why this convention shouldn't apply to you, and as I say, if you wish to 'denounce' it it can be done via RfC.
Regarding archiving, I don't see why it shouldn't be fair to ask users to archive their talk page messages. How do you justify that against the two reasons why they shouldn't that I have given?
Regarding being a sysop, that is not true. Any given user could have fairly reverted your removals for the same reason as myself. Just because it is your talk page, that does not give you a right to edit war, regardless of what the Wikipedia policies you quote. Because I do not wish to continue this edit war, I will personally refrain from reverting your edits if you try to remove the thread again, but if you do so I will not only hope that another administrator reverts that edit but I will be forced to open a local RfC to determine what the rule should be, if you do not wish to accept that this is the current convention which as far as I am aware no one has been against when it was applied in the past. Reception123 (talk) (C) 19:04, 28 March 2022 (UTC)
I'm certainly not aware of any such convention, and I don't believe it is the case. Even if it is, conventions are conventions and not policies, and not a reason to go around policing people especially in their user space.
to ask users to archive their talk page messages To ask, sure. But you are not trying to ask, you insist it be required for users to archive it in the way that you want. Your "reasons" were one that "it's a warning". One, the validity of that "warning" was questioned, second, insisting that users keep warnings on their talk page is even worse as it is essentially trying to use it as a mark of shame or insist that users keep it there for a "log" of their alleged wrongdoings. Sure, you say that w:Wikipedia:Don't restore removed comments is only an essay and is on Wikipedia and doesn't apply here, but you should read it as it completely counters everything you are saying. The other "reason" was that it's not fair to the other people. There is no case to be made that the method I choose to archive with is unfair to people posting. In fact, the opposite is true: trying to force one specific method is unfair; so Reception123 is the one being "unfair" in their own words. Even if I did put it in an archive subpage you still would have to make a new thread as posting to archives isn't allowed. The only difference is it's been archived to Special:PermanentLink/239802 instead of User talk:Naleksuh/Archive 1, which will remain a red link for life. Naleksuh (talk) 19:37, 28 March 2022 (UTC)
"Archiving" it through Special:PermanentLink makes it impossible to search and find the warning through the on-wiki search engine and requires that an administrator or user manually dig up the warning in your talk page's history which may prove inconvenient at a future date if your user talk page recieves more edits which further digs that down the history page while archiving it moves it out of your main talk page while still maintaining the original thread in an easy to find page. Agent Isai Talk to me! 19:44, 28 March 2022 (UTC)
@Naleksuh: My god Nale, the biggest elephant in the room is the driven edit-warring you yourself have initiated with Reception123. The latter on the other hand barely did anything, other than cautioning you in this scenario to stop, but now we're here. Can we please let it go before this thread gets out of control? Badgering and/or sealioning other users will get you nowhere fast, as you have already made your point around a few weeks ago, and I thought this topic was dropped by now. The points you have made here are slowly losing all of its meaning because you keep bludgeoning with the process, which I may add, is disruptive behavior, and should not continue any further. I don't even know why you chose to bring this matter that should've been resolved elsewhere back up. I'm sorry, but this is ridiculous beyond repair. DarkMatterMan4500 (talk) (contribs) 19:56, 28 March 2022 (UTC)
If you really want to [[w:WP:DROPTHESTICK|let it go]], then why continuously create things that have no purpose other than to arbitrarily restrict users? Especially something I've been doing for years and would be a convention change to me to stop. Since Reception123 agreed to stop edit warring, I re-moved it which was all I ever wanted to do, and you (I can use formatted text too) can drop the stick by not insisting anything more: be the one to stop what I never started in the first place. You can also stop calling me "Nale" at the same time, I've asked you to stop multiple times before but you never have. Naleksuh (talk) 20:01, 28 March 2022 (UTC)
Per what I said above, I have created this RfC. Please also note that I agreed to stop edit warring because that is not a thing to be done, but I did mention that I hope another administrator would intervene and I clearly completely disagree with your position still. Reception123 (talk) (C) 06:14, 29 March 2022 (UTC)
Reception123, you most certainly were not edit warring. You were following the long held Meta Wiki and, indeed, Miraheze, convention that recent warnings must not be removed user talk pages. Naleksuh's claim that edit warring does not apply to their own user talk page is, frankly, laughable if not ludicrous, as that would mean socks, as that would effectively provide vandals an exemption and free pass to do whatever they want on their own user talk pages. Frankly, given the number of warnings you provided Naleksuh, and I'm not certain why you didn't block them for edit warring for a short time (say 1-3 days) despite your, my and even Agent's recent warnings? There is, frankly, consensus here that this thread is spurious, frivolous, nonsense, and vexatious, and if a community were to propose a boomerang block, that's something I think any Meta administrator would entertain. Dmehus (talk) 07:03, 29 March 2022 (UTC)
After reconsideration, I have retracted my RfC so it can be worked on further and drafted, rather than opened in the spur of the moment. As for the thread, it seems clear that at least two other Meta administrators agree with me that warnings/notices should not be removed from your talk page, so I must once again ask you to stop doing so. Reception123 (talk) (C) 07:10, 29 March 2022 (UTC)
I would have liked to have seen this RfC. You already gave the two rather weak reasons for preventing removal of commments above, which have been addressed both by myself and by the essay. Your point seems to be to use users talk pages a list of warnings against them. Let me know once this RfC has been reopened (also be sure to list qualifiers for warnings, who is qualified to warn, and how recent is recent). Naleksuh (talk) 07:26, 29 March 2022 (UTC)
In addition to comments above, and to a potential RfC, which may still be helpful, to the notion articulated by Naleksuh that administrators must somehow justify every action based on a nuanced rule or policy, the community has, time and again, in successive RfC after RfC and discussion opposed as rule creep, preferring that administrators exercise common sense together with good governance formed from internal administrator discussions. Dmehus (talk) 07:17, 29 March 2022 (UTC)
Naleksuh, since you identified the diff-permalink method, which I also happen to prefer, I would think all concerned here would be satisfied if you simply added a bulleted list of permalinks at either (a) the top of your your user talk page or (b) at User talk:Naleksuh/Archives. Dmehus (talk) 07:46, 29 March 2022 (UTC)
That's a great idea, but I'm sure people will come up with some reason to object to that too. It doesn't change the focal point though : just because Reception123 was reinstating a "warning" does not make what they did not edit warring, and there's nothing to suggest any such exemption. If you refuse to believe user space is an exemption, why create new exemptions that don't exist? Naleksuh (talk) 07:52, 29 March 2022 (UTC)
Well, I think users thought you just wanted to have the permalinks buried in the ?action=history view for your user talk page, which can make specific revisions hard to find, especially on users with higher numbers of revisions on their user talk pages. As to why Reception123 didn't just BOLDly do that, as an alternative to simply reverting subsequent times, though I wouldn't characterize it as edit warring as it was restoration of very recent administrator warnings, I'm not sure. Perhaps he'll see this and might comment. Dmehus (talk) 07:58, 29 March 2022 (UTC)
it was restoration of very recent administrator [warnings] That doesn't make it not edit warring. Reception123 posted on my page, I reverted it, and they reinstated it. Also, it wasn't even "very recent", it was 3 weeks ago, so relatively recent but not "very recent". Naleksuh (talk) 08:00, 29 March 2022 (UTC)
That is intentionally not codified, but, generally speaking, my "rule of thumb" is minimum thirty (30) days and usually more like ninety (90) days, but if you acknowledge the warning was nearly three weeks ago, then that nullifies your claim of "edit warring" by Reception123, particularly given that edit warring is typically more than three reverts within a 24 hour period, no? Dmehus (talk) 08:05, 29 March 2022 (UTC)
No, it does not nullify that. More than three reverts in 24 hours breaks the three-revert rule, but you can still be edit warring without breaking it. Naleksuh (talk) 17:04, 29 March 2022 (UTC)
@Naleksuh: You're not really making much sense here, especially in terms of how recent it was. In any case, I would consider any recent action within a 90-day period. It's excruciatingly nauseating having to see this pointless nonsense being thrown at each other. Within this thread, I felt like I was watching a bunch of kids arguing with each other on the playground over who gets to go down the slide first. DarkMatterMan4500 (talk) (contribs) 17:12, 29 March 2022 (UTC)
I think the permalink method is perfectly acceptable and would serve the same intended purpose of making conduct or platform messages accessible, which is a well precedented convention here which has only been opposed the first time by this thread. Feel free to put it into practice, or even just add it to the top and say something on the lines of 'here, is this agreeable' so some agreement can be made here rather than a slightly amusing but ultimately tiring battle.
I've also been thinking of simply assembling permalinks to relevant messages through central means, ie, a place on the internal cvt wiki or even public to achieve this purpose, but it does have a bit of a 1984 feel to it. --Raidarr (talk) 12:30, 29 March 2022 (UTC)
For the editing issue, I would say it is quite arguably an edit war and an issue that should have come out and been advanced to a discussion for clarification after the first reversion and a disagreement appeared. It's an issue and it's time to move to the next stage for the confusion that caused it. I do believe Reception is now aware of the issue with the reverting back and forth after having conferred on Discord. Seeing that much reversion going on in a page's history is obviously an issue and needs to be stopped one way or another. --Raidarr (talk) 17:12, 29 March 2022 (UTC)
Well, this will be my last comment before I stop posting here on this: I think I'm going to be sick after reading all of this stuff from Naleksuh, as it pretty much poisons the original point of this thread, especially if it's leaning towards ad nauseum, and only gets boring from here. DarkMatterMan4500 (talk) (contribs) 17:17, 29 March 2022 (UTC)
I absolutely agree with @Naleksuh: regarding that you selectively choose which Wikipedia policies you will accept and use. There are more options - either accept all, none, or create local policies. And regarding the conventions, let yourself be laughed... Personal note about restricting users - Miraheze has changed a lot, for the worse regarding these bullying measures. I would love Miraheze's atmosphere to return to the time I joined, but it won't happen... I would like to see the opinion of @John:,--MrJaroslavik (talk) 19:02, 30 March 2022 (UTC)
First of all ignoring the convention and Wikipedia policy argument in terms of principles in my view it is absolutely ludicrous for the suggestion to be made that a person is to be allowed to remove warnings from administrators on from his or her talk page. That can mean several different things. First it can mean that there is clear contempt on the part of the user who perceives the warning as unjust or undeserved and belives that that means it is fine for them to just remove it. Second it can mean that they are embarassed by the warning and wish to hide it from the public view. Most importantly as it was pointed out above it means that the warning will almost have the effect of disappearing and if another administrator wishes to send the user a warning for another matter they will not have the benefit of being able to consult it. While an extreme comparison it can be compared to a criminal record; how would things work if criminals would be able to remove parts of their criminal record because they felt they were unfair? It makes no sense to allow someone to remove warnings from their talk page because they do not like them and I completely disagree with that and would be more than willing to support any proposals making it a written policy if that is what is neceessary
In terms of the Wikipedia policy arguments and the aggressive arguments made by MrJaroslavik and Naleksuh here is my view. First of all I agree that it is not fair for some Wikipedia policies to be cited and adopted as ours and others to be selectively categorised as bad. That being said I do think that conventions are an important part of the way that Meta works because it is simply not possible for relatively new (or underdeveloped projects) to have a policy for each thing. In this case it seems that there has been a long (and very reasonable as argued above) practice of not allowing people to remove warnings from their talk pages...why should this be abandoned just because someone is quoting a Wikipedia policy to the contrary effect? If there is an argument regarding whether a convention is indeed a convention I believe the way that this should be resolved is via a Request for Comment or discussion so that the community can decide whether to codify this convention if it is a controversial one. I once again feel that things are getting too personal as usual when instead they should be viewed from a more objective standard. I do not see how this can be considered 'bullying'. In any case I repeat that I would be more than willing to support an RfC to clarify this rule into policy. DeeM28 (talk) 17:17, 1 April 2022 (UTC)
Additionally I wish to add that I can see how there can be a perception that some administrators are selectively choosing which Wikipedia policies they follow but I think what is more relevant and important than any Wikipedia policies are our practices. If something has been done for months and has not been questioned by anyone it is arguably a convention. If people believe that this convention is an inappropriate one then that should be dealt with by an RfC which asks the community to decide whether to keep the convention or not. It is especially relevant if multiple administrators follow a convention (or agree with it). If only one administrator was creating conventions then I would agree that it could be more problematic in certain situations. --DeeM28 (talk) 17:21, 1 April 2022 (UTC)