Meta:Administrators' noticeboard/Archive 4

This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current talk page.

Request for Rollback (Universal Omega)

Hello, I know I have not done much counter-vandalism here on meta, although I do feel I should have rollbacker, so that if necessary I am able to quickly rollback the edits of vandals. I am active here on meta and quite frequently check the wiki requests, and already patrol many edits on meta, marking then as patrolled, so it makes sense for me to have rollback so that I can use it if needed. I can live without it by just going back and publishing the last good edit, but the rollback would provide a better record, and make it easier to do it. Thank you for the consideration! User:Universal Omega/Sig 15:20, 13 August 2020 (UTC)

Comment: I'm not opposed to this, but I personally haven't even requested it as Twinkle's pseudo-rollback via "undo" and "restore to revision" has served me well (though, there has been one, maybe two, instances where rollback might've helped, mainly relating to another user's refactoring of other users' comments). Dmehus (talk) 15:26, 13 August 2020 (UTC)

@Dmehus: Thanks. I actually think I have twinkle off, thanks for reminding me. In that case I do suppose this request is somewhat unnecessary. Thanks! User:Universal Omega/Sig 15:33, 13 August 2020 (UTC)

I also would see no reason to oppose this, though I personally feel that there is very little vandalism on Meta currently and that as Dmehus said, Twinkle would probably work. Reception123 (talk) (C) 15:52, 13 August 2020 (UTC)

@Dmehus and Reception123: Thank you for reminding me about Twinkle, and while you may be right about there being very little vandalism on meta, I do not need Rollbacker with Twinkle existing. However, I do think I should mention that twinkle seems unreliable, and does not work on all my devices for some unknown reason. But for now I suppose I do not need Rollback. Thanks for the replies!User:Universal Omega/Sig 04:01, 14 August 2020 (UTC)

@Universal Omega: Although rollback is rarely needed due to the pseudo-rollback feature included within the Twinkle (which uses undo), you've articulated a clear purpose and use case (i.e., the Twinkle compatibility issue when mobile), and you are trusted, so I'm inclined to grant this request, provided that you only use rollback when on mobile for obvious vandalism or for reverting Discord/auth. So,

Done. Dmehus (talk) 18:59, 21 August 2020 (UTC)

Request for Patroller (Universal Omega)

Hello, I would like to request the patroller group. I was active patrolling edits in the past when it was the autopatrolled group and would like to continue that. Thanks! User:Universal Omega/Sig 16:05, 30 August 2020 (UTC)

On hold for a few days to a week while we finalize the guidelines. Generally, I'm hoping that all patrollers will add things like {{unsigned}}, including timestamps (adjusted back to UTC time, as applicable), to talk page and noticeboards without signatures and/or timestamps, but yes, you are among the first patrollers I would like to see onboarded. Dmehus (talk) 18:51, 30 August 2020 (UTC)

Done. Please ensure you that you follow the main patroller guidelines that will follow on your user talk page. If you have any questions, please don't hesitate to ask. Dmehus (talk) 03:49, 31 August 2020 (UTC)

Request for Patroller (CircleyDoesExtracter)

Hi. I am CircleyDoesExtracter. I can nicely request the patroller right. I had experience adding unsigned signatures and patrolling edits. Since I supported the idea of the patroller group on Meta, I'd like to request it and continue with the autopatrolled right. Thanks! Circley DoesExtracter(Circley Talk | Global |Email the Cloud) 01:27, 31 August 2020 (UTC)

Done. Please ensure you that you follow the main patroller guidelines that will follow on your user talk page. If you have any questions, please don't hesitate to ask. Dmehus (talk) 03:49, 31 August 2020 (UTC)

Request for patrollers (松・Matsu)

Hi,there.Since the Japanese character code is minor and often has garbled characters, I would like to go around editing written in Japanese and help meta.thanks.--松•Matsu (talk) 14:50, 30 August 2020 (UTC)

On hold for a few days to a week while we finalize the guidelines. Generally, I'm hoping that all patrollers will add things like {{unsigned}}, including timestamps (adjusted back to UTC time, as applicable), to talk page and noticeboards without signatures and/or timestamps, but yes, you are among the first patrollers I would like to see onboarded. Dmehus (talk) 18:51, 30 August 2020 (UTC)

Done. Please ensure you that you follow the main patroller guidelines that will follow on your user talk page. If you have any questions, please don't hesitate to ask. Dmehus (talk) 03:49, 31 August 2020 (UTC)

@Dmehus:Thank you.:)--松•Matsu (talk) 08:12, 31 August 2020 (UTC)

Request for Patroller (Bonnedav)

Hello, I am Bonnedav. I may not be around all the time but do pop up occasionally. I have done patrolling on Meta before and wish to continue to do so. Thus i wish to request the new patroller group for this reason. Thank you. Bonnedav (talk) 22:09, 31 August 2020 (UTC)

Done; I was hoping you'd request this. Please ensure you that you follow the main patroller guidelines that will follow on your user talk page. If you have any questions, please don't hesitate to ask. Dmehus (talk) 22:32, 31 August 2020 (UTC)

Request for Patroller (Hypercane)

Hello, I would like to request the patroller user group as I believe it would be a great way for me to start helping out here on Meta. I'll look at any relevant guidelines you give me, thank you. Hypercane (talk) 00:28, 5 September 2020 (UTC)

Done. Thanks for volunteering. Dmehus (talk) 00:29, 5 September 2020 (UTC)

Request for `mergehistory` to be added to the `administrator` user group

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Consensus for. John (talk) 16:41, 12 September 2020 (UTC)

The following is a brief proposal for discussion, primarily, among administrators and interested Meta community members who follow this page to add the mergehistory user right to the administrator user group. Using the Special:MergeHistory special page, mergehistory is a user right that allows the revisions from one page to be moved, or merged, rather, into another page. It is primarily used for fixing things like improper cut and paste page moves, so in that way, is sometimes seen as a counter-vandalism tool. Nevertheless, it also secondarily used to history merge in the revisions from one older page into the revisions of a newer page, with the primary reason being for CreativeCommons copyright licensing compliance (see also this English Wikipedia guideline page for more on that). Commonly established guidelines on the English Wikipedia recommend that it be avoided where there are significant concerns with regard to parallel page histories.

Background: In somewhat of a curious anomaly, likely the result of a clerical oversight when Meta was established (since there are no merge log entries), mergehistory was never assigned to the sysop user group (see this special page in ManageWiki).

Rationale: I personally have a least a couple pages requiring history merging, mainly per attribution reasons and also for housekeeping reasons so redundant trailing redirects left behind by what would be the resulting merge can be safely deleted; however, @Reception123: and I have also been discussing the need to establish a Meta-only community discussion noticeboard (likely at Meta:Community portal, which, in turn, would see that historical page's revisions history merged into Community noticeboard/Archive 1 and made extant to the current revision on that archive page), to eliminate or reduce certain confusion if using Meta:Community noticeboard that would almost certainly be confused with community noticeboard, since he isn't keen on co-mingling Meta-only discussions with global or Miraheze community/customer discussions on community noticeboard, and, frankly, neither am I. We also briefly toyed around with my alternate idea of having a Meta:Bureaucrats' noticeboard, but seeing as bureaucrats on Meta only really grant interface administrator requests and close local RfCs (other than things like approving bots and closing administrator discussions at Meta:Requests for permissions), there's little need for them to have a separate noticeboard of their own, and, with bureaucrat in the name, users may incorrectly perceive they aren't allowed to participate on that potential noticeboard. Now, if the community still preferred a Meta:Bureaucrats' noticeboard as an alternative to Meta:Community portal, we would certainly support that, but there is still such a potential use case for mergehistory that it should be added to the administrator user group.

Proposal: To add the mergehistory user right to the administrator user group.

Note: This proposal should remain open for at least seven (7) calendar days, but given how minor of a user right addition this is, it can likely be closed early (by a bureaucrat on Meta who also holds steward rights, for technical reasons) if at least five people, having valid arguments, have expressed a supportive view with overwhelming consensus of at least 80% or greater.

Proposed by: Dmehus (talk) 21:43, 5 September 2020 (UTC)

Support

Strong support As proposer. Dmehus (talk) 21:49, 5 September 2020 (UTC)
Support I do see how this could be useful for the administrators to have. User:Universal Omega/Sig 21:53, 5 September 2020 (UTC) ］ |

Support Might be useful for sysops. Circley DoesExtracter(Circley Talk | Global |Email the Cloud) 22:52, 5 September 2020 (UTC)

Support Would be useful for Meta admins to have. Reception123 (talk) (C) 05:15, 6 September 2020 (UTC)

Support Can be useful for administrators HeartsDo (Talk || Global || Wiki Creator) 12:51, 6 September 2020 (UTC)

Neutral/Abstain

Oppose

Discussion

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

Autopatrolled request

First, I moved accounts from Tom191 to this account, which the former is autopatrolled. Second, I know how to use meta, vote in requests, I sign my posts, and add unsigned for others too. AppleCrunchy (talk) 23:56, 14 September 2020 (UTC)

@AppleCrunchy: Are you able to sign in to your @Tom191: account and have it reply to this thread, confirming that Tom191 and AppleCrunchy are the same person? If you had created AppleCrunchy while signed in as Tom191, it would show up in the user creation log that Tom191 had created the user account AppleCrunchy. Nevertheless, once you've done this, this LGTM, and I'm inclined to approve. Thanks. Dmehus (talk) 00:40, 15 September 2020 (UTC)

Yes, I'm AppleCrunchy Tom191 (talk) 13:05, 15 September 2020 (UTC)

@AppleCrunchy:

Done. Thanks for confirming from your @Tom191:, which you can now shelve, if you wish. You may want to add a notice on Tom191's global user page that it is a retired/former account. On your global user page (or Meta user page), you may, optionally, wish to disclose your prior Tom191 account, but that part is up to you as well. Here's the diff link for your confirmation edit from Tom191 for AppleCrunchy. Dmehus (talk) 13:49, 15 September 2020 (UTC)

Special:MyLanguage and "tvar" tags on FAQ

Hi, Raltseye has left a message on my talk page for ask to "implement Special:MyLanguage in tvar tags on FAQ" but I can not do this because the page is sysop protected. If a admin can take care this task, it would be good :). HeartsDo (Talk || Global || Wiki Creator) 06:00, 13 September 2020 (UTC)

@HeartsDo: Hrm, this should already be enabled, as I have seen <tvar /> used on pages on Meta, quite frequently in fact. Maybe @Raltseye: just means to update the source pages with this tag? If so, I'd recommend reaching out to either (a) any translation administrator (for non-administrator-protected pages) or (b) any administrator (for any administrator-protected pages). Hope this is of some assistance. Dmehus (talk) 15:04, 13 September 2020 (UTC)

Yes, that's what I meant with "implementing", as in putting the actual tags in the source code on the page itself. I appologize if I used the wrong wording. --Raltseye (talk) 22:29, 13 September 2020 (UTC)

@Raltseye: I'm going to temporarily lower the page protection on that page temporarily, so you or @HeartsDo: can undertake this. When it is complete, please reply back to this thread, and we'll (a) re-protect the page and (b) re-mark the page for translation. How does that sound? Dmehus (talk) 01:08, 14 September 2020 (UTC)

@Dmehus: Sounds good to me. --Raltseye (talk) 22:10, 14 September 2020 (UTC)

@Dmehus: I think I'm done, I don't see anything more to do on FAQ. @HeartsDo:, you're more than welcome to inspect of course. I also took care of some redirects and some dubble spaces that were scattered around.

Also, maybe Board should be translated, I don't know, maybe. --Raltseye (talk) 23:01, 14 September 2020 (UTC)

@Raltseye: Thanks for letting me know that you seem to be done with updating FAQ. I'll leave the protection lowered for another day or so, in case you have anymore updates to do, then will mark it for translation. Regarding Board, since it's a global page, I checked Miraheze's board secretary @Owen:, who had no issues with it being a translated page. So, I will take care of that now. Dmehus (talk) 23:14, 14 September 2020 (UTC)

Great, thanks! --Raltseye (talk) 23:20, 14 September 2020 (UTC)

@Raltseye: Board is all

done, and is ready to be translated now. Let me know if you would like to translate the two subpages of that page. Dmehus (talk) 23:30, 14 September 2020 (UTC)

@Dmehus: Thanks! I'm not so sure about the other two sub pages but yeah, maybe if you think it's appropriate. Also, next time, don't forget to add the Special:MyLanguage only on pages that can be translated and not on the likes of talk and user pages, since those (typically) can't be translated and in tvar tags so they can easily be translated without having to write the whole link. --Raltseye (talk) 21:02, 15 September 2020 (UTC)

@Raltseye: Thanks for the tip on the <tvar /> tags. I'll definitely try and do that in the future, and it was chiefly from your sample code that I am now much more confident in using them! As to the Special:MyLanguage links, yeah, I guess that's probably true, but the thinking was that the subpages would likely be translated, so couldn't hurt. Anyway, I will mark those subpages now. Dmehus (talk) 21:13, 15 September 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘That's great! Also, could you add tvar tags to the main page? --Raltseye (talk) 16:54, 16 September 2020 (UTC)

Merge User:FireBarrier101/signature into User:FireBarrier101/sig

I want to merge User:FireBarrier101/signature into User:FireBarrier101/sig on this revision. 「T ҍ C」(_yell / ^earth) ^{left miraheze} 17:48, 18 September 2020 (UTC)

FireBarrier101

Done. Dmehus (talk) 18:15, 18 September 2020 (UTC)

The section of the translation page is broken

Since the section of the translation source page has been changed significantly, the section is broken on some translation pages.I propose to delete pages that are not modified.thanks.--松•Matsu (talk) 00:58, 3 October 2020 (UTC)

@松: Yeah, this page was broken for the longest time until HeartsDo did excellent work repairing the broken translation. Is there a problem with specific sections, or just long outdated translated sections? Dmehus (talk) 01:34, 3 October 2020 (UTC)

@Dmehus: 8th is especially.It has a big impact because it inserts the rejected extension in the global extension part.However, this may help translate rejected extensions.But, the translation of the rejected extension has been subdivided and may not be very useful.--松•Matsu (talk) 01:45, 3 October 2020 (UTC)

@松: Hrm, at first I wondered if by "8th" if the issue was maybe HeartsDo had reused a translation unit ID number that had been used previously for another extension. Now, I am not so certain what you are meaning. Are you just saying you don't find the rejected extensions particularly useful, or you think we should change the order of the sections on the source page? Dmehus (talk) 01:56, 3 October 2020 (UTC)

@Dmehus: Translations:Extensions/8/XX part.This is the explanation part of CentralAuth.It looks like we're inserting a list of rejected extensions into the CentralAuth description.This affects unmodified, translated pages.--松•Matsu (talk) 02:09, 3 October 2020 (UTC)

@松: Ah, thanks for the helpful clarification. I will look into seeing if we can modify that translation unit somehow without having to invalidate it in some way. Separately, I have deleted seven (7) unmaintained translations (unmaintained since 2018 to early 2020), namely three variants of Chinese, Polish, Russian, Bangladesh, and Korean. All were approximately 1% (or less) translated, so that should help as well. Dmehus (talk) 03:29, 3 October 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@Dmehus: Thank you for your confirmation and response:)--松•Matsu (talk) 03:53, 3 October 2020 (UTC)

Removal of the `bot` flags for Proxybot and Void-bot

Looking at the Meta contributions and log actions for Proxybot and contributions and log actions for Void-bot, it looks like the former has not made an edit or log action on Meta since March 2018 and the latter has not done the same since October 2018 (not counting a February 2019 OAuth consumer token update). I previously confirmed with @Zppix:, the bot operator of the former, that Proxybot is longer blocking open proxies, and I haven't yet spoken to @Void:, so am pinging him if he can confirm whether Void-bot is still operating on Meta or whether it just operates on other wikis (i.e., CVT and/or MirahezeBots wikis). So, I'm just wondering if any Meta bureaucrat could remove the bot flag from these two bots on Meta, assuming there are no imminent plans for them to resume their functions? Thanks. Dmehus (talk) 17:31, 8 October 2020 (UTC)

I believe when we get the proxy stuff going again we'll be using the MirahezeBots account. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 15:50, 12 October 2020 (UTC)

Void-bot could probably lose the sysop flag right now, but still actively uses the bot login. I can't recall the source code off the top of my head, but I think it might not function properly if the bot flag is removed from the account. I intend to continue working on it, but recently many things have gotten in the way. -- Void ^Whispers 23:23, 12 October 2020 (UTC)

I've removed the sysop flag from Void-bot and the bot flag from Proxybot per above. If these are needed again in the future, they can be re-requested naturally. Reception123 (talk) (C) 17:54, 13 October 2020 (UTC)

Please block 2600:1700:50D0:ECC0:351F:B9E0:6C70:8A21

Special:Contribs/2600:1700:50D0:ECC0:351F:B9E0:6C70:8A21

Vandalism. Gomdoli4696 (talk) 04:57, 13 October 2020 (UTC)

@Gomdoli4696:, with a Cc: to @HeartsDo:, IP address hard blocked for one month, preventing logged in users from that IP address from editing on Meta for the duration and also from accounts being created at that IP address. As well, should the IP user change IPs, I've temporarily protected community noticeboard for two weeks to logged in, registered users. Thank you for your report, and to you both for your reversions. Dmehus (talk) 05:18, 13 October 2020 (UTC)
and hard blocked as they moved to their talk page. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 08:00, 13 October 2020 (UTC)

Moving a wiki to Miraheze is up for translation?

I recently got around to polish the page Moving a wiki to Miraheze for translation, is this something that we can mark for translation, or is there something more to do? And if so, how do one group it with other pages in the same category in Special:LanguageStats? Is that done by categories or do one have to manually do that in some special page? --Raltseye (talk) 16:10, 23 October 2020 (UTC)

@Raltseye: Yeah, that page can be marked, but I would check with @HeartsDo: first as they were working on that, mainly related to its translation units. Otherwise, I have no issues with it. To your latter question, I believe that's where the "aggregate groups" comes in in that you have to aggregate the page with a similar established translation group (i.e., probably "documentation"). Dmehus (talk) 16:23, 23 October 2020 (UTC)

For explain rapidly the problem, this page was already marked as translation but just removed on the translation wihout removing old units.

I have maybe a idea, but I not sure there will work. I will mark the page for translation and see if Fuzzybot do somethings. If it doing nothing, I will try to manual edit the old units (if possible) and create the new one and see if it modify the main page.

In other word, don't touch the page and I will say if a success or fail HeartsDo (Talk || Global || Wiki Creator) 16:37, 23 October 2020 (UTC)

OK, never trust on the green box, Fuzzybot is doing his job, this request is

Done HeartsDo (Talk || Global || Wiki Creator) 16:44, 23 October 2020 (UTC)

Archiving

Not sure if this is a great idea, but maybe add the autoarchive to this page since some things are literally 5 years old.

{{Autoarchive/config
|archive = Meta:Community portal/Archive %(counter)d
|algo = old(30d)
|counter = 1
|maxarchivesize = 100K
|archiveheader = {{Archive}} __NOINDEX__
}}

For your consideration. BlackWidowMovie0 (talk) 20:27, 29 October 2020 (UTC)

BlackWidowMovie0 Thank you for your good-faith suggestion. Meta:Community portal is the former community noticeboard, and, incidentally, I didn't realize that page's sysop protection had expired. This has now been corrected. We're currently developing plans to repurpose that noticeboard into a Meta-only community discussion portal, but what do with its archives is challenging. So, in the interim, it is sysop protected. Hope that helps. Dmehus (talk) 00:43, 30 October 2020 (UTC)

@Dmehus: It does. Thanks! BlackWidowMovie0 (talk) 00:44, 30 October 2020 (UTC)

Okay, great, and no problem. Thanks. Dmehus (talk) 00:49, 30 October 2020 (UTC)

Does Miraheze need translate rules?

Lots of English words are polysememes. And in other languages, they also have lots of different expression.

For example, "Miraheze" in Chinese can be "Miraheze", "米拉和泽" (transliteration), "菏泽的米拉铜合金" (literally) and so on.

I think Miraheze needs translate rules what has the translation of special words on gauge to make translations standard.

--开炸弹车 (talk) 03:26, 1 November 2020 (UTC)

Special:GlobalRenameRequest

I recently made a request to change my name on Miraheze the for why is entailed in the request, anyway, the message on said Special page shows this message:

Begäran om globalt namnbyte av användarkonto

Begär ett nytt användarnamn som kommer att används på alla projekt.

Alla dina tidigare bidrag kommer att knytas till detta nya användarnamn.

När du har begärt ett nytt användarnamn, kommer en anmälan att skickas till Wikimedias stewarder för utföra ett namnbyte. Du kommer att meddelas via email när denna process är klar.

Om din förfrågan är relaterad till en önskan om anonymitet/integritet, var vänlig notera att en permanent loggpost kommer att skapas med notering av ditt tidigare namn. Du kanske bör överväga att skapa ett nytt separat och oberoende konto och byta namn på ditt nuvarande konto till något slumpmässigt och sedan överge det.

Nuvarande användarnamn:

Raltseye

Now, correct me if I'm wrong but shouldn't it say Miraheze and not MediaWiki? Or is the system sending back a global name change request to MediaWiki? Isn't that handled locally? In which case it should be Miraheze. Or am I missing something here, could it a problem with localisation? --Raltseye (talk) 23:36, 31 October 2020 (UTC)

Seems to be an error in translation, as all renames are handled by Miraheze Stewards. Zppix (Meta | CVT Member | talk to me) 01:05, 1 November 2020 (UTC)

I assume it has to do with this unit on translatewiki. Alright, I seen to have fixed it. This thread was unnecessary.. --Raltseye (talk) 02:48, 1 November 2020 (UTC)

Thanks anyway. — Preceding unsigned comment added by Raltseye (talk • contribs) 02:52, 31 October 2020 (UTC)

@Raltseye: I was just going to suggest that this should be translated through translatewiki.net. It sounds like you found the correct interface message to translate. We have a bot on GitHub that automatically imports translatewiki.net translations on a regular basis. @Zppix: would probably know the frequency by which the translations are imported into our GitHub repository. Hope that helps. Dmehus (talk) 03:28, 1 November 2020 (UTC)

I am not sure how often this happens as the bot nor translatewiki is controlled by us AFAIK. Zppix (Meta | CVT Member | talk to me) 05:21, 1 November 2020 (UTC)

I fixed the translation anyway. --Raltseye (talk) 13:38, 1 November 2020 (UTC)

Please can you delete my userpage at Meta

Please may you delete this page here: https://meta.miraheze.org/wiki/User:TheBurningPrincess as I wish to change my name (at some point), and for that page to show up as deleted on Google TheBurningPrincess (talk) 21:50, 1 November 2020 (UTC)

TheBurningPrincess

Done. Please note, though, for Meta-only requests, you should either (a) use Meta:Administrators' noticeboard or (b) add {{admin help}} in a new section on your user talk page. Dmehus (talk) 22:07, 1 November 2020 (UTC)

TheBurningPrincess Should you wish to reply to this thread, please note that I have moved it from stewards' noticeboard to Meta:Administrators' noticeboard, where it is now in scope. Dmehus (talk) 22:15, 1 November 2020 (UTC)

MediaWiki:Common.css

.infobox {
	border: 1px solid #a2a9b1;
	border-spacing: 3px;
	background-color: #f8f9fa;
	color: black;
	/* @noflip */
	margin: 0.5em 0 0.5em 1em;
	padding: 0.2em;
	/* @noflip */
	float: right;
	/* @noflip */
	clear: right;
	font-size: 88%;
	line-height: 1.5em;
	width: 25em;
}
.infobox caption {
	font-size: 125%;
	font-weight: bold;
	padding: 0.2em;
	text-align: center;
}
.infobox td,
.infobox th {
	vertical-align: top;
	/* @noflip */
	text-align: left;
}

.infobox th {
	white-space: nowrap;
}

.infobox.bordered {
	border-collapse: collapse;
}
.infobox.bordered td,
.infobox.bordered th {
	border: 1px solid #a2a9b1;
}
.infobox.bordered .borderless td,
.infobox.bordered .borderless th {
	border: 0;
}

.infobox.sisterproject {
	width: 20em;
	font-size: 90%;
}

.infobox.standard-talk {
	border: 1px solid #c0c090;
	background-color: #f8eaba;
}
.infobox.standard-talk.bordered td,
.infobox.standard-talk.bordered th {
	border: 1px solid #c0c090;
}

/* styles for bordered infobox with merged rows */
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
	border: 0;
	border-top: 1px solid #a2a9b1;
	/* @noflip */
	border-right: 1px solid #a2a9b1;
}

.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
	border: 0;
	/* @noflip */
	border-right: 1px solid #a2a9b1;
}

/* Styles for geography infoboxes, eg countries,
   country subdivisions, cities, etc.            */
.infobox.geography {
	border-collapse: collapse;
	line-height: 1.2em;
	font-size: 90%;
}

.infobox.geography  td,
.infobox.geography  th {
	border-top: 1px solid #a2a9b1;
	padding: 0.4em 0.6em 0.4em 0.6em;
}
.infobox.geography .mergedtoprow td,
.infobox.geography .mergedtoprow th {
	border-top: 1px solid #a2a9b1;
	padding: 0.4em 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedrow td,
.infobox.geography .mergedrow th {
	border: 0;
	padding: 0 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedbottomrow td,
.infobox.geography .mergedbottomrow th {
	border-top: 0;
	border-bottom: 1px solid #a2a9b1;
	padding: 0 0.6em 0.4em 0.6em;
}

.infobox.geography .maptable td,
.infobox.geography .maptable th {
	border: 0;
	padding: 0;
}

(from Korean Wikipedia)
This is infobox class. can add MediaWiki:Common.css? Gomdoli (talk) 12:21, 28 October 2020 (UTC)

@Gomdoli: It's not clear to me how adding this to Meta's common.css file would be helpful. As far as I'm aware, that file only controls Meta, and has no impacts on other wikis. So, essentially, you would need to suggest to every wiki to update their common.css files where they use that infobox. Hope that helps. Dmehus (talk) 12:47, 28 October 2020 (UTC)

Yes, I'm only talking about metawiki. ※{{Infobox}} -- Gomdoli (talk) 12:51, 28 October 2020 (UTC)

@Dmehus -- Gomdoli (talk) 12:53, 28 October 2020 (UTC)

@Gomdoli: Okay, thanks. It's still not clear to me, though, what these CSS classes would solve? What would they change? Also, if you forget to {{ping}} someone, you can still go back into your message and insert a ping since no one has replied. You can optionally update the timestamp of your signature. There's no need to start a new paragraph and sign again just for the ping. I mean, it's fine the way you did it, but just letting you know another way that is perfectly acceptable. Dmehus (talk) 12:58, 28 October 2020 (UTC)

They define infobox's style; We can use class, then load styles. --Gomdoli (talk) 13:20, 28 October 2020 (UTC)

@Dmehus: and, you said

Also, if you forget to {{ping}} someone, you can still go back into your message and insert a ping since no one has replied.

, I edited that's because pings won't be sent. Wikipedia:ko:Template:Ping -- Gomdoli (talk) 13:22, 28 October 2020 (UTC)

There's infobox template. Yes. But what does this CSS class do? What value does it add to the template? Why should everyone loading Meta get these chunks of code? No, "because there's a template, there should be this CSS code" does NOT count. — revi 14:11, 28 October 2020 (UTC)

Not done as no real need. Dmehus (talk) 17:53, 10 November 2020 (UTC)

Double </language> tags

The training module Training modules/Dealing with online harassment/slides/on-wiki-steps-they-can-take feature double </language> tags. I don't have the permission to edit the page (even though the edit button says I can), so if anyone with said permission could remove one of them, that'd be nice. --Sabelöga (talk) 13:43, 10 November 2020 (UTC)

@Sabelöga:

Done, but that page wasn't protected, so I'm not sure why you weren't able to remove it. Dmehus (talk) 14:47, 10 November 2020 (UTC)

Strange, it works now :/ Thanks anyway :) --Sabelöga (talk) 15:19, 10 November 2020 (UTC)

@Sabelöga: Yeah, strange. Oh well, it works now. Anyway, I noticed that you added the noinclude tag around the languages tag in this edit. It's been my experience that the languages and translate tags are impervious to the noinclude tag. So, while that edit is harmless, it's also useless. Not a big deal, and I wouldn't bother correcting it, but just a point for the future. Dmehus (talk) 15:49, 10 November 2020 (UTC)

@Dmehus: Well, if you mean that the language tags are automatically treated as noinclude I think you're misinformed, because the only reason I noticed that it was doubled and thought it was a problem is because it was transcluded on Training modules/Online harassment due to the missing noinclude. Since I removed them they aren't transcluded on that page just like the other ones. --Sabelöga (talk) 17:14, 10 November 2020 (UTC)

@Sabelöga: Well, hrm, that's possible, I guess, but I have noticed that when transcluding translated pages, the languages tag seemed to ignore the noinclude tag. To be honest, though, I'm not sure why we've even prepared the training modules for translation, as they're not used by community members. They're used exclusively by system administrators in the course of dealing with Terms of Use enforcement (mainly serious online harassment). We have several administrators that speak languages other than English, but all are fluent in English, so there's not really a massive need to be translating these pages. What are your thoughts to potentially deleting the translated subpages (and translation units) for the training modules, and moving these pages from main namespace to Tech: namespace? This would certainly reduce the workload for translators. Dmehus (talk) 17:24, 10 November 2020 (UTC)

I'm all for that, as it would take a very long time to translate them and wouldn't really be that worth it, plus it might distract translators into translating those when they're aren't really the most needed, or not needed at all. I would never for instance translate them as it's too much work and hassle, and even if I were to do it, it would take like a week or so. So deleting them from the translation system seems fair. --Sabelöga (talk) 17:30, 10 November 2020 (UTC)

@Sabelöga: Oh, great. I was worried you'd already put a lot of work into translating those modules. I'll try and tackle this project in the next week or so. Dmehus (talk) 17:38, 10 November 2020 (UTC)

Excellent, no only Spanish had been translated, partially. --Sabelöga (talk) 17:48, 10 November 2020 (UTC)

Request for `interface-admin` for Naleksuh

Following my discussion on IRC with Naleksuh regarding Twinkle no longer functioning following Miraheze's upgrade to MediaWiki version 1.35, and because we no longer have an active Twinkle maintainer to continue the de-Wikipedia-ification started by Amanda Catherine, he has accepted my invitation to join the Meta team as an interface administrator. Additionally, he has a separate application in to volunteer as a Miraheze MediaWiki extension security reviewer, given his php coding expertise. I have no doubt he will also be keen to install useful gadgets on Meta.

With that, I will now turn it over to Naleksuh to provide the necessary acceptance of this nomination and any bureaucrat can see fit to close this discretionary appointment request when their time permits. Thanks. Dmehus (talk) 03:04, 12 November 2020 (UTC)

Thank you for the request. I accept the nomination. Naleksuh (talk) 03:08, 12 November 2020 (UTC)

My password is set to take over 500 quadrillion years to crack and is not used anywhere other than Miraheze. Naleksuh (talk) 03:10, 12 November 2020 (UTC)

Done Reception123 (talk) (C) 06:10, 12 November 2020 (UTC)

Request for Marking Discord/Ops for Translation

Hello, could a translation administrator (or administrator) please mark Discord/Ops for translation? Thank you very much. R4356th (talk) 11:38, 13 November 2020 (UTC)

Doing… HeartsDo (Talk || Global || Wiki Creator) 11:47, 13 November 2020 (UTC)

R4356th

Done HeartsDo (Talk || Global || Wiki Creator) 11:50, 13 November 2020 (UTC)

Thank you very much, @HeartsDo:. R4356th (talk) 12:11, 13 November 2020 (UTC)

Request for interface messages MediaWiki:nstab-tech and MediaWiki:nstab-tech/ja

Request...create this pages:

MediaWiki:nstab-tech:Tech

MediaWiki:nstab-tech/ja:ワザ

--Waki285 (talk) 00:33, 12 November 2020 (UTC)

@Waki285: Firstly, please note that I have procedurally moved this discussion and question from MediaWiki talk:Nstab-tech for a couple reasons. One, that is an orphaned talk page. Two, since talk pages aren't monitored regularly, the noticeboards are where most discussions should occur. Secondly, I'm not familiar with these interface messages. What would be the purpose of these? Dmehus (talk) 00:40, 12 November 2020 (UTC)

@Waki285: After looking into this a bit further, I realized that the Tech: namespace already displays "Tech" in the subject page's tab name, so I'm going to say that MediaWiki:nstab-tech is

Not done. Regarding MediaWiki:nstab-tech/ja, that can be done. Normally, interface message translations are done through translatewiki.net; however, in this case, it does seem to make sense to translate this locally. When I double-checked the translation of ワザ using Google Translate, it returned "Waza". So, I am going to reach out to @松: (Pine/Matsu), a Meta patroller, to confirm that this is the correct Japanese translation for the English word "Tech". @松:, can you confirm and/or comment? Dmehus (talk) 01:20, 12 November 2020 (UTC)

It can also be translated as technical information.--松•Matsu (talk) 05:58, 18 November 2020 (UTC)

@松: Okay, thank you. What do you think would be the best Japanese character to use for Tech to appear in the page name for Tech: namespace? Dmehus (talk) 06:14, 18 November 2020 (UTC)

Request for Marking Discord/Verification/Intro for Translation

Hello, could a translation administrator (or administrator) please mark Discord/Verification/Intro for translation? Thank you very much.(The text is the same as the previous person, but I'm sorry.) --Waki285 (talk) 05:42, 17 November 2020 (UTC)

Okay, but then why not just put the text on Discord/Verification anyway? The way it is now, people can't read the translated pages from the first page. Then what's the point of that page? --Sabelöga (talk) 14:25, 17 November 2020 (UTC)

Done I did not notice the Discord/Verification page before. @Sabelöga:, I think that page's content could be replaced with a redirect to Discord/Verification/Intro. R4356th (talk) 14:30, 17 November 2020 (UTC)

R4356th Okay, but why then not move Discord/Verification/Intro to Discord/Verification? --Sabelöga (talk) 14:39, 17 November 2020 (UTC)

@Sabelöga: Yes, that could be done, too. But it is worth noting that the page cannot be translated while the move is in progress. R4356th (talk) 15:11, 17 November 2020 (UTC)

R4356th Well, no-one has started any translation, yet have they? --Sabelöga (talk) 15:25, 17 November 2020 (UTC)

Nope, I was just saying that no one can translate while this is being moved. So, yeah, it looks like there is no harm in moving it now. R4356th (talk) 15:28, 17 November 2020 (UTC)

I've had a look at both pages and, because Discord/Verification is sysop protected, moving Discord/Verification/Intro isn't possible. Since the former is a duplication of the latter, what I will do is remove the protection on the former, and either (a) delete the former and move the latter to the deleted former's title (if the latter is an older page than the former page) or (b) delete the latter and remove it from the translate system, allowing any translation administrator to prepare the former page for translation. Dmehus (talk) 16:03, 17 November 2020 (UTC)

This is

done. Discord/Verification can now be translated as it is no longer transcluding Discord/Verification/Intro. Dmehus (talk) 16:24, 17 November 2020 (UTC)

Great. Thank you very much. R4356th (talk) 16:28, 17 November 2020 (UTC)

Requesting edit on Meta:General disclaimer

Specifically, I request that Special:MyLanguage is added to all the present links and that Terms of Use and Privacy Policy is moved from the tvar tags so that the link text can be translated. Like so: [[Terms of Use|Terms of Use]]. --Sabelöga (talk) 00:16, 21 November 2020 (UTC)

@Sabelöga: I'm willing to add this as it does seem like a reasonable and helpful request; however, I meant to follow up with you on my user talk page that I had to remove the Special:MyLanguage prefix from MediaWiki:Mainpage due to an upstream MediaWiki bug that prevented administrators from being able to change the visibility of log entries in Special:Log. So, that prior request you made won't be actionable, unfortunately. However, this seems reasonable, as it isn't changing anything within MediaWiki: namespace. Dmehus (talk) 00:29, 21 November 2020 (UTC)

Done Dmehus (talk) 00:36, 21 November 2020 (UTC)

Thank you, and to comment on the previous request I made, I understand that it didn't work the way I intend it to so that it was reverted is maybe not a big deal, but being able to direct users to a translated version of the main page is still desirable so maybe if it's possible any other way I guess. Also, maybe that page should have some a categories? --Sabelöga (talk) 00:45, 21 November 2020 (UTC)

@Sabelöga: Thanks for understanding. Yeah, I'll try and think of an alternate method of redirecting users to the translated Main Page. As far as adding categories to the Main Page, that's certainly possible, but I'd have to check with Reception123 and see if it's desirable, but will definitely do that and get back to you. Dmehus (talk) 00:57, 21 November 2020 (UTC)

@Dmehus: Okay, I was also thinking of Meta:General disclaimer which doesn't have any categories, the Main page could just have Category:Miraheze if that isn't undesired. --Sabelöga (talk) 01:24, 21 November 2020 (UTC)

Possible new template I've been developing on the test wiki

Possible new template I've been developing on the test wiki to be used on Meta:Administrators and other similar lists. Basically, it creates a translatable template that gets transcluded on the lists that in turn gets translated onto the main articles. See User:Sabelöga/Sandlåda for details on how the acutal template looks and works in action. (Also, why don't the testwiki have its own interwiki prefix :/) --Sabelöga (talk) 12:35, 21 November 2020 (UTC)

@Sabelöga: Technically and aesthetically, this looks fine, and I'm not opposed to it, but I have to think about this some more as I was actually planning on using the [[.../List]] as cross-wiki transcluded lists, incorporated into local wikis' lists of users (i.e., for local and global interwiki administrators). Due to an upstream bug with the Translate extension's translate and languages tags ignoring the noinclude tag when used with scary transclusion, this would pose problems with transclusion. So, let me think about this some more, and I'll try and get back to you on this in the next month or two. Dmehus (talk) 15:21, 21 November 2020 (UTC)

Okay. --Sabelöga (talk) 16:46, 21 November 2020 (UTC)

Translatewiki

I was translating mwgithub-mirahezemagic-custom on translatewiki and saw a problem with one of the translate units. Is there somewhere were I can discuss this further with someone? Specifically there is a lot of wikimarkup in a translate unit that is really unnecessary for translators to copy and steals time. --Sabelöga (talk) 01:28, 21 November 2020 (UTC)

@Sabelöga: What do you mean by unnecessary wiki markup? Most of our MirahezeMagic interface messages are contained within this json file, so any changes to the source messages can be requested in that way, which are then, in turn, update on translatewiki.net for translators to update. The translations are then piped back to Miraheze's GitHub repository every Monday. Dmehus (talk) 02:07, 21 November 2020 (UTC)

@Dmehus:I speak specifically about translatewiki:MediaWiki:Mirahezemagic-custom-miraheze-warnmessage in which I don't think that the wikimarkup should be contained withing the translation unit. I mean, can't it be contained outside it? Minimalising the required copy-pasting from the translators and standardising the way the notice looks. The way it is now, I could have changed how it works and if one were to in the future update the source code for the notice one would have to update the translations as well. --Sabelöga (talk) 10:24, 21 November 2020 (UTC)

@Sabelöga: The linked Miraheze warning message doesn't exist on translatewiki.net. Did you possibly mean a different message? Dmehus (talk) 15:16, 21 November 2020 (UTC)

@Dmehus: Darn it, I mean this one https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=mirahezemagic-custom-miraheze-warnmessage&group=mwgithub-mirahezemagic-custom&language=sv&filter=&optional=1&action=translate --Sabelöga (talk) 16:46, 21 November 2020 (UTC)

@Dmehus: Any developments? Sabelöga (talk) 01:06, 23 November 2020 (UTC)

@Sabelöga: Thank you for the reminder. Yes, in fact. The good news is that particular MirahezeMagic interface message is an old interface message, so it no longer needs to be translated. The bad news is that we changed the method by which sitenotices are applied to wikis (used to be done by a bot; now it's done automatically by a maintenance script on a cron) and, as a result, those sitenotices can't currently be translated. I did some checking with Nikerabbit in the #mediawiki-i18n ^connect channel on IRC and, unfortunately, when the source interface message is deleted, the messages on translatewiki.net aren't deleted. Nikerabbit did say that the messages should no longer be sorted into the appropriate message group. So, if for some reason they are, then there could be another issue that will have to be tracked down. Hope that helps. Dmehus (talk) 03:49, 23 November 2020 (UTC)

@Dmehus: Okay, so the message is unfortunately no longer supported nor translatable. I understand. --Sabelöga (talk) 07:02, 23 November 2020 (UTC)

@Sabelöga: Well, sort of. That message is no longer used, but translatewiki.net doesn't delete outdated messages. The current message is at this page in our GitHub repository, which you can see doesn't offer a way to translate it currently. We'll try and investigate a way to translate it, whether on-wiki or on GitHub, though, but no timeframe for when this will be done. Dmehus (talk) 14:15, 23 November 2020 (UTC)

I understand. Sabelöga (talk) 14:54, 23 November 2020 (UTC)

Translate Template:Translated

I'm thinking of marking Template:Translated for translation. Do you think this is a good idea? Also, if I were to do it, I can include the English version in the translated version if the point of the template is to point users to the bottom of the page even if they don't speak the local language. I'm thinking it's beneficial to display the information in both languages. Sabelöga (talk) 01:05, 23 November 2020 (UTC)

@Sabelöga: While this might be a good idea, for several reasons, I'd like to postpone preparing this for several reasons. For one thing, I have to look into how the transclusion of translated templates works, which may also add complexity to our translation pages. Keep in mind we have a limited number of translation volunteers, and, while I can see the benefit to translating these templates into languages other than English, our community is nowhere near as large or as active as the Wikimedia translation community. At the same time, we already have a fair number of content, documentation, and policy pages which need translating, translation reviewing, and updating. Finally, I do not want to overburden the jobrunner servers too much with an even greater number of pages (now templates) that will require translating. So, I'd really prefer to see us focus on translating content in Main, Meta, and Category namespaces for the time being. Hope that helps. Dmehus (talk) 01:15, 23 November 2020 (UTC)

@Dmehus: That's fine, it's not that urgent so if things need to be prepared then take your time. Though when it comes to transclusions I believe we can just use Template:TNT which uses the translated version of a template (or other transcludable page) if it exists or the source template (page). Basically I've noticed it actually transcludes {pagename}/en which solves the problem of including translate tags. See how Template:Global policy is used on Dormancy Policy for instance. --Sabelöga (talk) 01:29, 23 November 2020 (UTC)

Okay, thanks. Yeah, I will try and look into it over the next month or so, and hopefully we can prepare it for translation. Dmehus (talk) 03:43, 23 November 2020 (UTC)

Okay. --Sabelöga (talk) 07:35, 23 November 2020 (UTC)

Note that we do use translatable templates on most of the policy pages. (Using Template:TNT) MacFan4000 ^{(Talk Contribs)} 15:16, 23 November 2020 (UTC)

Exactly my point, so I don't see any issues wth this either. Sabelöga (talk) 15:22, 23 November 2020 (UTC)

TOC right on Tech:Server admin log

For the sake of reading the page I think that Tech:Server admin log should make use of {{TOC right}}. I tried to add it but there was a message that said only system administrators should edit the page which makes sense since it's updated by a bot. Now, I don't know how that page is used or by who, but the way it is now that one have to scroll through an enormous amount of TOC to get to the first entry is ridiculous, if the page is never read by humans this should not pose a problem though, but then again why host it here? --Sabelöga (talk) 07:38, 23 November 2020 (UTC)

@Sabelöga: Reasonable suggestion.

Done. Dmehus (talk) 14:08, 23 November 2020 (UTC)

@Dmehus: Thanks! I only hope this won't create any troubles with the bot when it's due to update the list next. --Sabelöga (talk) 14:54, 23 November 2020 (UTC)

It shouldn't. Bot adds only a new log entry to the row immediately above the previous row, adding a new section header when the calendar rolls into a new month. Dmehus (talk) 14:57, 23 November 2020 (UTC)

Excellent! Sabelöga (talk) 15:01, 23 November 2020 (UTC)

Creating a Policy for Marking Pages for Translation

Looking through the recent changes and talk pages, I think we should have an official policy for marking pages for translation on Meta to avoid any kind of possible confusion. A template for informing users that their edit was unhelpful to translators (usually because they either reverted an edit adding <tvar>s or edited something inside a tvar and did not check the "Do not invalidate translations" option while marking the page for translation) could be helpful, too. Does anybody have any opinion on this? (I am putting this here instead of CN because I believe this needs admins' attention.) R4356th (talk) 15:49, 23 November 2020 (UTC)

R4356th This is indeed the correct noticeboard to use for now, as it concerns a Meta specific issue/proposal. While I do agree a policy, or perhaps a guideline adopted by administrators rather than a community adopted policy, could be helpful for translations, we do have a number of more pressing things to get to at the moment, so this probably will not be done for at least a month or two. In the meantime, we do have these translation administrator guidelines that are fairly comprehensive, particularly when you add together this advice which all translation administrators should follow. Moreover, I think most of the pages that need to be prepared for translation have been, so we really just need to focus on updating those pages. Let me know if that helps, and clears that up. Dmehus (talk) 16:13, 23 November 2020 (UTC)

Yes, sure but that template is barely read by non-translationadmins. And it does not mention the part about not marking translations as outdated. R4356th (talk) 16:24, 23 November 2020 (UTC)

Perhaps a better solution could be to take the elements from the template Dmehus mentions and to make them into a separate guideline page that non-translation administrators could read or easily be linked to (however, they could always be linked to the template too if necessary). I don't think that a policy, per se is needed, simply clear non-controversial guidelines that all users can and should follow. Reception123 (talk) (C) 16:27, 23 November 2020 (UTC)

R4356th (and Cc: to @Reception123:) Also, another reason why I'm not sure a formal policy is needed is that I rather like the practice of invalidating translations as then the outdated translations are marked in red. The old translations are still there, and just need to be copied, pasted, and updated. Perhaps we could do well to advise administrators and translation administrators not to invalidate translations for minor things like updating the tvar tags, but I think we can probably just keep doing this with gentle reminders as we see them. Dmehus (talk) 16:32, 23 November 2020 (UTC)

+1 for Reception123 idea HeartsDo (Talk || Global || Wiki Creator) 16:32, 23 November 2020 (UTC)

While I'm not opposed to the above idea, as indeed I was the one that first floated the idea of a possible guideline page, I don't see an immediate need to create it, simply because our current practice of gentle reminders is working well, and non-translation administrators cannot mark pages for translation. Dmehus (talk) 16:34, 23 November 2020 (UTC)

@Dmehus: To be honest, I am suggesting creating a policy mostly just so that reminders do not need to be sent. I am not really a fan of the ones that are currently being sent. And +1 for Reception123's idea, from me, too. Additionally, I would like to note that I am not saying it should be done immediately as well. R4356th (talk) 18:24, 23 November 2020 (UTC)

R4356th Okay, I'll try and work on a guideline page in the next month or so. I do think we should not make it mandatory, though, to check the "do not invalidate translations" box, though, as that does have its uses (i.e., it lets translators know which sections need to be updated). That being said, perhaps for the time being @Sabelöga: could ease up on the reminders being sent? Dmehus (talk) 18:33, 23 November 2020 (UTC)

Yes, I agree that it should not be made mandatory since well, as you say, it is useful in several cases. But its use should be encouraged whenever possible, in my opinion, as it is very helpful for translators. When I started working on updating most of the existing Bengali translations, I found that many of them did not really need to be updated since the updates to the English version were minor wording or spelling issue fixes which were already corrected in the translation and had to make null edits to mark them as updated. R4356th (talk) 18:49, 23 November 2020 (UTC)

Yes, I was reckless on the second one I sent as I didn't realize my advice was being followed. I'm sorry for that one and have apologized to the person the unnecessary message was sent to. But I agree that marking the box "Do not invalidate translations" is useful, sometimes, and it would be beneficial to stake out where it is somewhere so that we can direct people there if there's any uncertainties. Sabelöga (talk) 23:00, 23 November 2020 (UTC)

Edit request on Meta:Administrators

Could someone lower the protection level on Meta:Administrators or copy the edit from Special:Diff/146477 there? Don't forget to update the Meta:Administrators/List with Special:Diff/146476. --Sabelöga (talk) 01:13, 25 November 2020 (UTC)

EDIT: The same request on System administrators, System administrators, and Stewards. --Sabelöga (talk) 01:22, 25 November 2020 (UTC)

@Sabelöga: I did notice your inclusion of noinclude tags around the headers of the [[/List]] subpages, and half expected to have to come here to say

not done, as I noted a little further up on this noticeboard that these [[/List]] subpages are designed to be easily transcluded onto other wikis. However, in my testing, purging the page several times to be sure, it seems that there were no issues, so I am going to mark this is

done. It should be done shortly, with the obvious proviso that should unexpected issues crop up with scary transclusion, it will have to be undone. Dmehus (talk) 01:37, 25 November 2020 (UTC)

@Dmehus: Well, the thing here is that you have to provide your own header which then in turn can be translatable, that has to be present or else it will look like this when transcluded: {{:Meta:Interface administrators/List}}. --Sabelöga (talk) 01:42, 25 November 2020 (UTC)

@Sabelöga: Can you clarify what you mean by this just a bit? When I looked at my test revision on TestWiki, I saw a properly formatted table with scary transclusion. When I saw your example, locally transcluded, which I've wrapped in <nowiki></nowiki> tags for readability, it was not properly formatted. The transclusion would probably be a bit different with scary transclusion, but I just want to confirm that you also see a properly formatted formatted table on TestWiki. Thanks. 01:51, 25 November 2020 (UTC)

@Dmehus: Well, yes, the table you showed me in Test Wiki works fine. If it's supposed to ignore noinclude tags on other wikis then it's working the way it should. Locally on the other hand, one have to provide a header. --Sabelöga (talk) 01:55, 25 November 2020 (UTC)

@Sabelöga: Yes, in this case, the fact that noinclude tags are ignored with scary transclusion works in our favour here, so this was was a reasonable workaround you devised. In the event the upstream bug is ever patched, we should be able to remove one of the duplicate headers, hopefully. In any event, in your request, you linked to two instances of system administrators. I assume for one of them you meant Global Sysops, but the headers don't seem to quite match up with either of those. Wiki tables can be a bit of a headache to work with, which I invariably don't have the time for, so I'm going to have to ask you to please figure out the wikitable formatting for those pages, and link me to the revisions. You may use either your sandbox on TestWiki or the Meta community sandbox. Thanks. Dmehus (talk) 02:28, 25 November 2020 (UTC)

That's good, and yeah, I can work that out. Sabelöga (talk) 02:32, 25 November 2020 (UTC)

@Dmehus: Aand, done User:Sabelöga/sandbox. Sabelöga (talk) 02:58, 25 November 2020 (UTC)

@Sabelöga: Thanks, but for Global Sysops, I'm seeing the same wikitext coding as what I used, and the new header doesn't match up with the existing columns, so that's my concern. Also, do you have a diff for the system administrators page? Dmehus (talk) 03:01, 25 November 2020 (UTC)

Done @Dmehus: Well, they do duplicate in my sandbox in TestWiki but they don't do when I preview the copied text Meta, for some reason :/ Sabelöga (talk) 03:15, 25 November 2020 (UTC)

@Sabelöga: Okay, great. Thank you for preparing the updated headers in your TestWiki sandbox, which I've now separately blanked, and

completed this request. Dmehus (talk) 08:49, 25 November 2020 (UTC)

Excellent, thank you! Sabelöga (talk) 09:22, 25 November 2020 (UTC)

Requesting edit on MediaWiki:Sidebar

Could someone change the FAQ string to Special:MyLanguage/FAQ|faq? This will enable translation of that label from MediaWiki:Faq/sv, MediaWiki:Faq/sv/de, etc. --Sabelöga (talk) 02:23, 28 November 2020 (UTC)

@Sabelöga: Thank you for your request, but it's not clear that (a) this can, or should, be changed on-wiki and (b) how you want this effected. Can you confirm this can be done on-wiki and not, say, through translatewiki.net or some other venue? Additionally, can you please specify your requested change in the format of "change x into y". Thanks. Dmehus (talk) 02:30, 28 November 2020 (UTC)

@Sabelöga: I believe I've understood what you're after, but this really should be done in our GitHub MirahezeMagic repository, so I've

done this pull request for you. Once it's merged, I'll update the MediaWiki:Sidebar per your request and follow up here. However, keep in mind the localisation updates are only processed on a weekly basis (every Monday at 0:00 UTC, if I remember correctly), so it'll be just a bit yet before you can translate. Trusting this works for you. Dmehus (talk) 02:42, 28 November 2020 (UTC)

Sure, @Dmehus:. On MediaWiki:Sidebar, I would want the string Special:MyLanguage/FAQ|FAQ to be changed into Special:MyLanguage/FAQ|faq, this will make the program fetch the displayed text from the system message MediaWiki:Faq/(language code), which, for instance Swedish, would make it Frågor och Svar and for German Häufig gestellte Fragen. The way it is now, the text is written in raw text which displayed the English FAQ regardless of language. Sabelöga (talk) 02:47, 28 November 2020 (UTC)

Well, okay, I don't see why we would have to go through GitHub to change something in the sidebar, but if that's praxis I suppose it's fine, as long as it gets done. --Sabelöga (talk) 03:07, 28 November 2020 (UTC)

Interface messages, whenever possible, are supposed to be done through translatewiki.net, mainly because editing certain messages locally can have unforeseen side effects. So, this would be my preference. Moreover, editing it through translatewiki.net will mean the change can be used globally. That is to say, other Miraheze wikis can use the miraheze-faq interface message flag in their sidebar, and it doesn't need to be retranslated over and over. Dmehus (talk) 04:59, 28 November 2020 (UTC)

Yes, of course we should be translating through translatewiki, but that requires us to use the translation they provide, and in this case we don't. The translations are already here (see: MediaWiki:faq/sv, MediaWiki:Faq/ar, etc.). Writing FAQ in lower-case will uitlize these, and display them to readers if they set their system language to a certain language. Do note that we do the same thing in MediaWiki:Sidebar already with mainpage|mainpage-description which calls for MediaWiki:mainpage-description/de, MediaWiki:mainpage-description/pl, etc. All I ask for is that we do the same thing with the FAQ that's all. Sabelöga (talk) 05:07, 28 November 2020 (UTC)

I believe mainpage-description is a MirahezeMagic-controlled interface message, though. Dmehus (talk) 05:13, 28 November 2020 (UTC)

Isn't it on every MediaWiki wiki though? Sabelöga (talk) 05:15, 28 November 2020 (UTC)

Maybe mainpage-description is, but is faq? If you can show me evidence on MediaWiki that it is, then I'll add it. Otherwise, I'd be inclined to delete those other local MediaWiki interface messages and shift them to translatewiki.net. Dmehus (talk) 05:19, 28 November 2020 (UTC)

https://www.mediawiki.org/wiki/MediaWiki:Faq/sv it is. Sabelöga (talk) 05:23, 28 November 2020 (UTC)

That doesn't tell me, though, if faq is a defined message description in core MediaWiki. For all I know, they could be just piping the wikilink in MediaWiki:Sidebar. So, I really would prefer to go through translatewiki.net, in absence of further evidence. Dmehus (talk) 05:28, 28 November 2020 (UTC)

https://translatewiki.net/wiki/MediaWiki:Faq/sv here it is, in all its translated glory. Sabelöga (talk) 05:42, 28 November 2020 (UTC)

@Sabelöga: Okay, so to be clear, you're not asking me to create a local /sv subpage in MediaWiki: namespace. If I add faq to the MediaWiki:Sidebar, this will just properly translate the link in the sidebar. The actual Swedish translation of MediaWiki:Faq will be done on translatewiki.net? If so, I can do that, and this was after I just got my GitHub commit merged to create a separate miraheze-faq interface message. LOL ;-) Dmehus (talk) 05:58, 28 November 2020 (UTC)

In a nutshell, yeah. Sabelöga (talk) 06:01, 28 November 2020 (UTC)

@Sabelöga: Okay, great, then this seems to be

done, assuming what I asked is accurate. Dmehus (talk) 06:04, 28 November 2020 (UTC)

Indeed, the label is now translated, thanks very much :D If you'd like you could temporary change your system language and see how it changes along with the rest of the links in the sidebar. Sabelöga (talk) 06:06, 28 November 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Great! Yeah, it's weird that MediaWiki:Faq can't be deleted, and there's not even a page history for it, so it must indeed be a special core MediaWiki message. Yes, I might do that temporarily one of these days. No problem. Dmehus (talk) 06:16, 28 November 2020 (UTC)

Request for deleting a page

Could an admin please delete Meta:Userboxes/dr? It is a subpage of a translatable page and the title and page content makes me feel like it was supposed to be a translated page but the Translate extension's translating interface was not used. It is currently showing up in Special:PageTranslation as a page proposed for translation because of having the translate tag in its Wikitext. While this is not really a problem, I do not see any use of that page either. Thank you. R4356th (talk) 16:04, 28 November 2020 (UTC)

Done, thanks to @Dmehus:. R4356th (talk) 16:07, 28 November 2020 (UTC)

R4356th Yes,

page deleted, and thanks both for your report and for your clerking, as I was just coming here to say that. I've also separately verified that all existing translation subpages are valid translation subpages, not manually created ones. Dmehus (talk) 16:09, 28 November 2020 (UTC)

Cool. Thank you very much. R4356th (talk) 16:12, 28 November 2020 (UTC)

Requesting edit on Meta:Copyrights

There's a </span> missing on the page, it's no big deal since it doesn't break the page but still, it looks like something's wrong when translating the page. The whole translate unit should be inside the span since it then removes the span entirely from the translating unit, with the link in tvar.
There's also a Special:MyLanguage missing from the Miraheze link. --Sabelöga (talk) 07:49, 30 November 2020 (UTC)
Done. Dmehus (talk) 14:10, 30 November 2020 (UTC)
Thanks you. --Sabelöga (talk) 20:20, 30 November 2020 (UTC)

Please specify Category Pages as the translation target

Please specify Category:Stewards as the translation target.--Waki285 (talk) 05:14, 2 December 2020 (UTC)

Sure --Sabelöga (talk) 05:17, 2 December 2020 (UTC)

@Waki285: If you like, you can also prepare the rest of the categories in Category:Global user groups to be consistent. Sabelöga (talk) 05:20, 2 December 2020 (UTC)

Please also Template:Update. Waki285 (talk) 04:05, 4 December 2020 (UTC)

@Waki285: I'm less familiar with translatable templates, but this does seem fine to me, so

done. I assume you'll need to use it conjunction with {{TNT}}, correct? Dmehus (talk) 04:42, 4 December 2020 (UTC)

Yes, otherwise the translations tags will show on the target page ;) --Sabelöga (talk) 06:16, 4 December 2020 (UTC)

Removing my `interface-admin` flag

With my recent successful election to steward, I really do not require the interface-admin flag on Meta Wiki, so if any Meta bureaucrat could kindly remove the flag for me, that would be great.

Thanks,
Dmehus (talk) 01:47, 5 December 2020 (UTC)

Not done unless you’re resigning the relevant rights. Steward is not a permission to supersede local rights. John (talk) 01:52, 5 December 2020 (UTC)

Thanks, @John:. Though you and I ended up having a conversation on IRC, I felt that it would be important for me to clarify on-wiki the intent behind my unusually brief request. Indeed, I know that the steward role is not a substitute for local user groups, but was mainly wondering whether a Meta bureaucrat would be able to provide me a local authorization to use the user rights as part of the Meta interface administrator user group (since that group itself is a discretionary appointment). Following my conversation with you, while that could be done in theory, in practical terms, from the sounds of it, there exists no local policy on providing for this delegation. Perhaps that's a local discussion the Meta Wiki community could have at some point, defining the user rights the global groups may use and under what conditions they may use them regardless of whether the local user groups are also held. At any rate, following your suggestion, I'll hang onto the user group for the time being. Thanks again. Dmehus (talk) 22:52, 5 December 2020 (UTC)

I have destroyed User:Lily/global.js

I did not realize that I was in metawiki when I moved my global.js and edited the redirect link, now I cannot edit the page because it redirects to a page outside user namespace. Pls delete the page, so I can restore my old global.js, thank you very much Lily (Lilypond Wiki · talk to me · little garden · my wiki of everything) 14:19, 5 December 2020 (UTC)

I've moved it back to the original page. Reception123 (talk) (C) 14:59, 5 December 2020 (UTC)

Thank you very much! Greetings Lily

(Lilypond Wiki · talk to me · little garden · my wiki of everything) 15:18, 5 December 2020 (UTC)

Note that I have procedurally moved this request from stewards' noticeboard to Meta:Administrators' noticeboard. Basically, Meta:Administrators' noticeboard is the venue for any requests about users or pages on Meta that requires administrator intervention]], local, small-ish community proposals, and local discretionary appointment permissions requests granted by either a local administrator or bureaucrat. Community noticeboard is technical support questions regarding your wiki, small-ish global community proposals, questions about Miraheze or MediaWiki generally, and requests to add interwiki prefixes to your wiki. Stewards' noticeboard is basically for anything requiring steward attention that isn't handled elsewhere on other related noticeboards (i.e., Requests for adoption). Hope that helps. Glad the issue was

resolved, too. Dmehus (talk) 16:50, 5 December 2020 (UTC)

Update list of current stewards at Stewards

Since Dmehus is now a steward, may a Meta administrator update the list at Stewards? Justarandomliberal (talk) 03:29, 5 December 2020 (UTC)

Justarandomliberal I will try and have all the user group lists updated later this evening. Thanks. Dmehus (talk) 03:30, 5 December 2020 (UTC)

Justarandomliberal This has been

done by @Universal Omega:. If you ever see minor inconsistencies between the user list subpages, please don't hesitate to make the update(s) yourself, taking care to leave a clear edit summary and, optionally, linking to a relevant permalink/diff in said edit summary. Thanks again for your reporting this, and for your community contributions. Dmehus (talk) 17:37, 5 December 2020 (UTC)

@Dmehus: This is unfortunately,

Not done. {{List of Stewards}} has not been updated yet. R4356th (talk) 20:23, 6 December 2020 (UTC)

And I cannot edit that page since it is protected. :( R4356th (talk) 20:33, 6 December 2020 (UTC)

R4356th Thank you. I didn't even know that {{List of Stewards}} existed, actually. It looks like it existed prior to Stewards/List being created, so I've simply

history merged in the revisions prior to today, since the wikitable was broadly similar to that at Stewards/List, and now @NDKilla: is appropriately credited as page creator of Stewards/List. So, now

done. Dmehus (talk) 21:20, 6 December 2020 (UTC)

@Dmehus: Thank you very much. R4356th (talk) 21:36, 6 December 2020 (UTC)

No problem. Dmehus (talk) 21:37, 6 December 2020 (UTC)

I want to add a CodeMirror extension to this wiki

I would like this wiki (Meta) to introduce CodeMirror Extensions with Special:ManageWiki/extensions. Reason ... It's hard to see when writing in wiki text. This tool can be turned on and off at any time by the individual user. Waki285 (talk) 03:43, 2 December 2020 (UTC)

@Waki285: First, thank you for this suggestion, which I have procedurally moved from community noticeboard to here, where it is now notionally in scope, as I can actually see a good use case for enabling CodeMirror on Meta Wiki. At the same time, I believe Universal Omega has also enabled it on his DC Multiverse Wiki together with VisualEditor. Generally speaking, we should probably leave this discussion open for approximately 3-5 calendar days or so, to encourage anyone else to express an opinion, and then I'll reach out to the steward bureaucrat John to effect this change. Thanks again. Dmehus (talk) 04:43, 2 December 2020 (UTC)

@Waki285: With no objections from anyone in more than a week, this is

done as it's a reasonable request. Dmehus (talk) 22:32, 12 December 2020 (UTC)

Unassigned user right `unwatchedpages`

I noticed that the steward user group is able to view the number of page watchers of a given page on Meta Wiki, something the local Meta administrators cannot do, presumably because the user right unwatchedpages is unassigned locally. It's included within the steward and globalsysop global groups, but not any local user groups. On TestWiki, we have it assigned to the administrator user group and, indeed, on English Wikipedia, they, too, have assigned it to the administrator user group, though interestingly, the number of page watchers is still visible to non-administrators on that wiki, so that suggests, perhaps, there's some sort of additional configuration change we'd need to make? Nevertheless, as I can see a use case for Meta administrators, or even all users, potentially, being able to see the number of page watchers of a given page, I'd like to add the unwatchedpages user right to either (a) administrator or, perhaps, (b) autoconfirmed and confirmed maybe? As Meta Wiki is rather unique in its management structure in that it is a steward-managed wiki with local Meta bureaucrats managing the closing of local permissions requests, RfCs, and Meta community discussions at AN, I thought I'd post this idea here to see if anyone had any objections to me making this change? Though local bureaucrat approval is not likely required, since it does affect the the user rights of Meta administrators, feedback from any Meta bureaucrats is of particular interest to me. Thanks. Dmehus (talk) 13:59, 10 December 2020 (UTC)

I have no objections to this and think it was likely an oversight. Sysops on EnWiki also have the right, and I don't see why sysops here on Meta shouldn't. Reception123 (talk) (C) 14:06, 10 December 2020 (UTC)

With the endorsement of local Meta Wiki bureaucrat @Reception123: and no objections from anyone in more than two days, this is now

done. Meta administrators can now view unwatchedpages, something that was most likely an inadvertent oversight. Dmehus (talk) 22:41, 12 December 2020 (UTC)

Request for Enabling Extensions Report and EditCount

The Report extension will allow registered users to report revisions privately to sysops (default, can be changed). And sysops will be able to review the reports from Special:HandleReports. I think this will be helpful for fighting vandalism and sharing private information with admins. @Dmehus: said that he would propose it for enabling here on the Phabricator task for installing this on Miraheze and on Discord. EditCount will implement a special page for showing users' local edit count allowing users to transclude their edit count in their signatures. This extension is not very important but would be good, in my opinion. R4356th (talk) 17:08, 11 December 2020 (UTC)

R4356th I would have no objection to these extensions be enabled on Meta Wiki as they're both either useful or small, but will wait to see if either of @Reception123 and John: have any thoughts, so will give it a few days before enabling. My only concern with the Report extension is whether or not that extension will create a new patroller user group and overwrite the existing patroller group. If not, that is to say, if the extension first checks if an existing group exists prior to overwriting and creating, then I have no concerns. Dmehus (talk) 17:20, 11 December 2020 (UTC)

@Dmehus: It adds a new user right called handle-reports which is assigned to Sysops by default (but as I mentioned earlier, it can be changed). R4356th (talk) 17:27, 11 December 2020 (UTC)

R4356th Ah, my mistake...I was thinking of Patroller, which I haven't requested be installed on Miraheze yet—still debating whether to request it, but may file a Phabricator task in a few weeks. I'll wait until at least @Reception123: adds a comment, giving his blessing to Meta administrators having no opposition to having that added user right. Dmehus (talk) 17:35, 11 December 2020 (UTC)

I think EditCount should be fine to enable and may be useful. As for Report, I'm not sure how useful it would be to us really, but I don't object to us giving it a try and if it doesn't work out disabling it afterwards. Reception123 (talk) (C) 07:35, 12 December 2020 (UTC)

@Reception123: Considering Report might turn out to be problematic if there are spam reports or new users mistakenly using it, do you think community consensus is necessary here? R4356th (talk) 07:49, 12 December 2020 (UTC)

R4356th It's a potentially valid question, but considering that Meta administrators are the only ones that would be viewing the special page, I would say no, actually. And actually, that would be a stronger argument against requiring a formal community proposal to enable the extension, as we want to be able to disable the extension quickly if it were misused. I see no problem trying it out, as the use case for this would be for Meta patrollers to report problematic revisions requiring revision deletion (i.e., editor who logged out or grossly defamatory or insulting comments, etc.), since revision deletion requests can't simply be tagged with {{delete}} like page deletion requests. Since administrators are the only users that can see the reports, this is an ideal way to report such requests. Plus, creating a new thread at Meta:Administrators' noticeboard for every grossly defamatory or insulting revision requiring deletion is a bit much, in my opinion (though reporting revisions of users who likely edited while logged out would normally be reported privately; however, since administrators are the only ones that can see the page, this is a reasonable reporting avenue). Dmehus (talk) 13:44, 12 December 2020 (UTC)

I agree that I don't think there's much harm in at least trying it out and seeing if it works for us, it could be an interesting tool for us. If it doesn't, it can be quickly removed as Dmehus says. Reception123 (talk) (C) 15:58, 12 December 2020 (UTC)

@Dmehus and Reception123: okay, great. R4356th (talk) 16:35, 12 December 2020 (UTC)

R4356th and Reception123 With that, this is now

done. Dmehus (talk) 22:50, 12 December 2020 (UTC)

@Dmehus: Thank you so much! R4356th (talk) 09:57, 13 December 2020 (UTC)

Enabled the Purge extension on Meta Wiki

Hi everyone,

As Meta Wiki has somewhat of a unique governance structure in that it is a Steward-managed wiki, with Meta bureaucrats overseeing such things as local Meta community proposals and RfCs and stewards managing most other aspects of the wiki, I have enabled the Purge extension by way of this log action, and am providing this courtesy notification to the Meta Wiki community of this action. For one thing, I am constantly having to alter my web address by adding ?action=purge to the end of the URL, so having a purge link in the "More" tab would be quite helpful. Additionally, most or all of the Wikimedia wikis have this extension enabled. The extension's documentation recommends assigning the purge user right to registered, logged in users, to prevent search engine crawlers from crawling purge links and adding to server load. I have verified with this special page that this indeed the configuration. Though unlikely to bring any objections, should the Meta Wiki community have any thoughts on this, this thread would be the place to do it. Dmehus (talk) 03:11, 16 December 2020 (UTC)

It seems to only need putting the following code on MediaWiki:common.js or one's own common.js page:

$('#p-cactions ul').append('<li><a href="?action=purge">purge</a><li>');

--开炸弹车 (talk) 14:31, 20 December 2020 (UTC)

Request to delete my Meta user page

Hello, I would like to delete my Meta user page, so that I could create a global user page in the Login wiki instead. JasonHK (talk) 14:41, 16 December 2020 (UTC)

Done Reception123 (talk) (C) 15:01, 16 December 2020 (UTC)

Request for Updating FAQ

Could an administrator please update the answer to How do I change my logo or favicon? on FAQ to explicitly mention that both logos and favicons be changed from ManageWiki? It currently only mentions that favicons can be changed. Thank you. R4356th (talk) 12:17, 19 December 2020 (UTC)

Could the What is the initial state of my new wiki? section be updated, too? It currently says, "In addition, your user name will be designated the wiki's first bureaucrat." CreateWiki previously used to put the bureaucrat's name on the main page long ago but that is no longer the case. R4356th (talk) 14:34, 19 December 2020 (UTC)

Could the How does a wiki close? section be updated, too? It says, "A wiki is also closed by stewards after a period of inactivity, as specified by the Dormancy Policy." It is outdated and System administrators are the ones who run a maintenance script to close this wikis currently. R4356th (talk) 15:29, 19 December 2020 (UTC)

Also, could the "How does a wiki close?" section be updated to say that wikis not closed by Sysadmins can be reopened by local bureaucrats, too? I am sorry for the noise but I am working on translating FAQ and these caught my eyes. R4356th (talk) 15:33, 19 December 2020 (UTC)

Partially done with regards to the closing section. Anyone else can get round to the other two. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 15:33, 19 December 2020 (UTC)

@RhinosF1: Thank you very much. R4356th (talk) 15:36, 19 December 2020 (UTC)

Could the FAQ#How do I confirm that my wiki has been created? section be updated, too? It currently states, "There are some cases where a wiki can't be created, such as... In this case, you will be advised on your user talk page." This is not usually done unless the user makes too many duplicate requests. This should be ideally updated to say that they should follow the comment(s) left on their request in such cases. R4356th (talk) 21:00, 20 December 2020 (UTC)

R4356th Since we're all very busy around here, and you're trusted, I've temporarily lowered protection on FAQ to autoconfirmed, allowing you to effect this change and any additional change(s) requested. When you're done, please just leave a reply here and {{ping}} me to reprotect it. Dmehus (talk) 23:04, 20 December 2020 (UTC)

@Dmehus: Thank you very much. R4356th (talk) 09:55, 21 December 2020 (UTC)

@Dmehus: This is now

done. Please note that I made some changes to other sections on that page, too. Also, Sysadmins should consider giving the How many servers do you have, and where are your servers located? section another look since I suspect it may still be outdated. R4356th (talk) 11:48, 21 December 2020 (UTC)

@Dmehus:

Please wait. I spotted something else. R4356th (talk) 12:25, 21 December 2020 (UTC)

I am done updating what I wanted to update. R4356th (talk) 13:03, 21 December 2020 (UTC)

R4356th

No problem, and thanks for the updates. Your updates to FAQ all looked useful, and it looks like you also updated the question on how many servers we have and where said servers are located, so that seems to be

done as well, correct? One question I had was in this edit in which you removed an translation unit containing outdated and superceded information. No concerns with the edit, but do you happen to know if the Translate extension will correctly pull a list of all translation units when a page is proposed for deletion (when you select to list all translation units)? In other words, will it list both live + removed translation units? As long as the answer to that is "yes," then I have no concerns. Dmehus (talk) 15:19, 21 December 2020 (UTC)

@Dmehus: Even though I updated the section about servers it may still be outdated (see Discord) as enough information regarding them was not present. As for the translation-related question, the Translate extension does not forget about translation units even if they are removed from the source page. So, this should not cause any issue. R4356th (talk) 16:58, 21 December 2020 (UTC)

Discussion concerning MediaWiki:Mainpage-description

Considering lowercasing the p to be more consistent with other sidebar entries (and how most other wikis list the main page in their sidebar), any objections? Naleksuh (talk) 20:33, 26 December 2020 (UTC)

@Naleksuh: Do we even need this anymore? I think we have a MirahezeMagic global interface message for this? Dmehus (talk) 20:36, 26 December 2020 (UTC)

@Dmehus: No, it's a lowercase p on most Miraheze wikis, even newly created ones. Naleksuh (talk) 20:38, 26 December 2020 (UTC)

@Naleksuh: Okay, yeah, I see that there is no MirahezeMagic global interface message, though I'm wondering if we should create one? Local wikis can always override it with a local interface message. Alternatively, I guess I'd be fine with this, but would rather see it described as "Home," since the name of the page is Miraheze. Dmehus (talk) 20:40, 26 December 2020 (UTC)

@Dmehus: I believe it is referencing what is the main page here, although it is not necessarily called Main Page. Naleksuh (talk) 21:48, 26 December 2020 (UTC)

@Naleksuh: Okay, fair enough, though I don't think this ideally the best descriptor. For now, this is sort of meh, so will call this

done, without prejudice to a future discussion about how to describe that sidebar link in the future, or making the change globally with a MirahezeMagic interface message. Dmehus (talk) 21:59, 26 December 2020 (UTC)

@John: Why was this page deleted? Naleksuh (talk) 01:07, 27 December 2020 (UTC)

@Naleksuh: I've reached out to @John: to explain the reason for the deletion. I'm okay with the deletion, provided there's a MirahezeMagic global interface message that exists in our GitHub repository; however, I haven't been able to find it. At any rate, I do agree that some explanation should've been provided given that there was a discussion on the matter here. Dmehus (talk) 01:45, 27 December 2020 (UTC)

The following has been moved from MediaWiki talk:Mainpage-description now that the companion page has been deleted. Dmehus (talk) 02:50, 27 December 2020 (UTC)

I deleted it because the requested change reverts the message back to what is provided in MediaWiki core, therefore there is no reason to maintain the override if it is the software default. John (talk) 02:54, 27 December 2020 (UTC)

@John: Ah yes, the purpose of recreating it was due to its talk page showing up as an orphaned talk page, however the discussion is now moved here with talk page deleted so all is good. Naleksuh (talk) 02:56, 27 December 2020 (UTC)

@John: Thanks. I just figured that out afterward—was just about to message you. Thanks for your follow up. Dmehus (talk) 02:56, 27 December 2020 (UTC)

Request for Importing Some Userboxes from Login Wiki

Could someone please import the userboxes "User WMF", "User Phabricator" and "User IRC" from Login Wiki, please? Thank you very much. R4356th (talk) 20:01, 8 January 2021 (UTC)

R4356th

In progress.... Dmehus (talk) 20:43, 8 January 2021 (UTC)

R4356th

Done Dmehus (talk) 01:27, 9 January 2021 (UTC)

Thank you very much though I assume you thought I was requesting these userboxes to be imported to Login Wiki which is why you moved this to SN in the first place? R4356th (talk) 09:43, 9 January 2021 (UTC)

R4356th No problem, and precisely. That's exactly what I thought initially. When I moved it back to Meta:Administrators' noticeboard, I didn't provide as detailed of an edit summary, as it was essentially a self revert. Dmehus (talk) 16:40, 9 January 2021 (UTC)

Ah,

I see. Thank you. R4356th (talk) 16:46, 9 January 2021 (UTC)

Request for Updating Stewards, Global Sysops and Counter Vandalism Team

Could someone please update Global Sysops and Counter Vandalism Team to mention how to opt out of their intervention? It currently states that opting out is possible without actually stating how. Also, could Stewards be updated to mention when they should intervene with the local wiki community? I am aware that it is impossible to opt out of their intervention but think that it should be stated when it is to be considered appropriate for Stewards to intervene with the local wiki community or administration unless requested by them if this has been discussed elsewhere by the community. If not then it should probably be left alone and perhaps at a later date, there should an RfC regarding this. Thank you. R4356th (talk) 22:20, 12 January 2021 (UTC)

R4356th The change you requested has been

done. With regard to your latter comment, I'm not sure an RfC on this is necessary. Stewards will generally only intervene when there's been a local request from the wiki, or in matters that haven't been dealt with by local administrators in a reasonable period of time (i.e., reverting spam or blatant vandalism). Hard time limits don't really work that well, particularly, in the case of blatant spam page creations, as leaving spam for too long could cause problems for Miraheze subdomains by search engines, so it shouldn't be left too long, really. Feel free to discuss this with me further in a direct message on Discord, though, as that's probably the best venue for clarifying any specific concerns. Dmehus (talk) 06:48, 13 January 2021 (UTC)

@Dmehus: Thank you very much. I was just curious about the Steward part. :) R4356th (talk) 11:17, 13 January 2021 (UTC)

@Dmehus: There is a minor grammatical mistake in Global Sysops: "Once consensus has been achieve" should be "Once consensus has been achieved" instead. Also, you have written "stewards' noticeboard" instead of "Stewards' noticeboard" in both places though it is not that big of an issue. R4356th (talk) 11:36, 13 January 2021 (UTC)

R4356th

Typo fixed. I've double-checked both places, and indeed, it does say stewards' noticeboard, not Stewards' noticeboard. Dmehus (talk) 16:13, 13 January 2021 (UTC)

Thank you for fixing it. R4356th (talk) 16:25, 13 January 2021 (UTC)

No problem. Dmehus (talk) 16:25, 13 January 2021 (UTC)

Potential Vandalism

It appears there may be some vandalism happening over at Template:Infobox person. Please take the necessary action, which may involve deleting the template as a whole. Integer ^talk 18:28, 19 January 2021 (UTC)

Marked at deletion and warned by me and deleted by Dmehus HeartsDo (Talk / Global / Wiki Creator) 18:29, 19 January 2021 (UTC)

Many thanks Integer ^talk 18:30, 19 January 2021 (UTC)

No problem :) HeartsDo (Talk / Global / Wiki Creator) 18:35, 19 January 2021 (UTC)

It has been taken by User:Dmehus, thank you! Integer ^talk 18:30, 19 January 2021 (UTC)

Meta community proposal regarding the use of the Report tool

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

The usage of the Report tool seems to be quite controversial, which is understandable. The purpose of this proposal is not to determine guidelines for enabling extensions, for what it's worth.

To my knowledge, the Report extension currently allows all registered users to use a tool for reporting revisions containing 1) vandalism or 2) requiring suppression to Meta administrators. The tool allows administrators to approve or deny the request. This tool is one-way communication. Four proposals have been introduced: 1) move the ability to report to the patroller user group 2) move the ability to report to the patroller and autopatrolled user group, 3) status quo: allow all registered users to report revision, and 4) remove the Report extension.

Who should use the extension?

Up until now, all users, anonymous and registered, can request a block or revision deletion by contacting an administrator; either via a noticeboard, a user talk page, email or social media (e.g. IRC or Discord).

By using the report tool, the following changes will be performed to community workflows:

Requests for blocking a user and revision deletion shall be moved to the Report extension.
An administrator becomes a semi first point of contact for suppression requests.
Unless community members are well known and have short communication lines with volunteers holding administrator or suppression rights on Meta, users will resort to the Report tool. Therefore, the Report tool has a direct impact on communicaton workflows.

Proposal 1 proposes to only allow the users in the patrollers group to report revisions. Proposal 2 is similar to proposal 1, but includes the autopatrolled group as well. This group consists of around 9 volunteers, whereas the autopatrolled group consists of 141 users. Avoiding abuse of the Report tool is a reason to restrict the assignment of the report right. Discrimination against all other community members is a reason to not restrict the usage of the Report tool.

Meta is a community-driven wiki. To keep this community wiki organised, several community members can request extra rights: rollbacker, administrator, patroller, bureaucrat, autopatrolled, etc. They are elected by the community, directly or indirectly. An example of indirectly: no community input is needed to become a rollbacker, but granting the rollback group is restricted to administrators: volunteers who are elected by the community. Any registered Meta user is allowed to 'vote' here (yes, sometimes a fixed support ratio determines the outcome, instead of the determined consensus). Just like that, any registered Meta user can create and edit all pages by default.

However, providing input to those people for performing their duties should be a privilege restricted to certain Meta user groups? What is considered to be abuse? How is a patroller more trustworthy than someone who is only 'autopatrolled', or actually isn't in any other user group? Where does the distrust to so many members of the Miraheze community come from? Why are the fears of abuse so strong for a tool that hasn't been in use for such a short time? With only about ten reports in a month, most of them coming from 'patrollers', the fear of abuse seems to be a case of 'do not allow, unless explicitly authorised'. This strategy works well in certain industries or for certain purposes: no one should be a steward by default, obviously. However, with regards to community engagement, the reverse has been the case since forever: everyone is allowed to participated, unless explicitly disallowed. The total impact of abuse of edit tools (e.g. vandalising hundreds of pages) is much greater than abusing the Report system to create reports. If we see someone vandalising, we can block them. 'Misusing' the Report tool is a form of vandalism as well, hence the same response should be applied: block if needed, but allow by default.

As a community, we elect administrators to perform their duties based on global and local policies and guidelines, again ratified by the community. The best definition of 'trust' here is that administrators handle the reports based on their judgement of the situation, regardless of the reporter. The impact of abuse does not justify the discrimination against everyone but 150 users, especially if new community members will never experience the short communication lines, because they do not participate in the community outside Meta. Proposal 3 'succeeds' (see below), under the assumption that anonymous users are also 'users'.

Creating reports

The last question is whether the Report extension should remain enabled at all. The fourth proposal proposes to remove the Report extension, because the list of reports is hidden - hence against the community-driven aspect of Meta and the values of transparency -, becuase the extension disrupts an existing workflow and because the extension was not enabled with proper community consultation. I agree there was a lack of community consultation beforehand, but this proposal has done a form of consultation, fortunately enough to determine some sort of consensus today.

The comments regarding proposal 4 suggest that the stance is only slightly shifted towards 'do not remove'. There is some interest in the extension and a well determined scope for usage, which I won't ignore here. I am confident that there could be a much stronger consensus for enabling if the scope (what should the extension do?) and impact (what is the impact on workflows by enabling this extension?). However, several people have expressed their concerns regarding negative impact on transparency (since the reports are only visible to administrators) and the workflows. The consensus in this situation is not a mere 'yes' or 'no', but rather 'could be enabled, but not yet'. Therefore, the outcome of this community proposal is 'negative', with a personal recommendation to reevaluate the usage of the extension and resubmitting a new proposal afterwards.

Southparkfan (talk) 23:16, 21 January 2021 (UTC)

Recently, following the Report extension being installed on Miraheze after passing a security review, in accordance with system administrator procedures for installing new extensions, it was requested to be installed on Meta. Meta patroller R4356th supported, along with Meta bureaucrat Reception123 and myself, with the prevailing view that it would be useful for conveniently reporting, confidentially to Meta administrators, revisions that either (a) are blatant vandalism or (b) require revision deletion, at minimum. The first two reports by Meta users have been good-faith, but incorrect, uses of the report tool. I do continue to believe that for these two purposes, the tool has incredible value and use on Meta; however, I think we need to change the user group(s) that have access to the extension-added user right, (report), which is used to report revisions for administrator attention.

Though not required to, officially, I am going to refrain from taking a position as the proposer of this proposal, other than to say I believe the extension should be retained. I take no position as to which proposal is better. Dmehus (talk) 23:18, 16 December 2020 (UTC)

Notes:

This proposal may be closed by an ideally uninvolved Meta bureaucrat and effected technically by a steward (whether participating or not), generally after at least three (3) calendar days and certainly after at least 5-7 calendar days.
Please remember all votes should express an argument with them, including, but not limited to, referring to the argument(s) expressed in the proposal(s) or which which have been made by other users.
Either, but not all three, of proposals 1, 2, or 3 may pass.

Proposal 1: Move `report` to patroller user group

Rationale: Patrollers and administrators are the two primary user groups on Meta Wiki that patrol, respond to, and otherwise handle, new edits and pages on this wiki.

Support

Support Yes, this was a magnificent decision to install this onto Miraheze. It makes reporting somewhat easier than normal. DarkMatterMan4500 (talk) (contribs) 00:17, 17 December 2020 (UTC)
Considering that I was the first to use this tool before anyone else can, apparently. DarkMatterMan4500 (talk) (contribs) 00:19, 17 December 2020 (UTC)
Support User:Universal Omega/Sig 06:52, 17 December 2020 (UTC) ］ |

Support as a reasonable second alternative to Proposal 2, where @Justarandomamerican and HeartsDo: both state that it's also reasonable to allow trusted autopatrolled users to report these problems on-wiki. As I articulated in my comments here and here in reply to Naleksuh, the Report has a narrow scope of utility and will be used chiefly, if not exclusively, for reporting only either (a) blatant vandalism or (b) revisions requiring revision deletion by an administrator, who would then refer to a steward privately where suppression is required. It would not be used for any other purpose besides those two described and articulated purposes. We're already reporting these things, nearly exclusively, through private Discord and IRC channels and/or through direct messages, so this just provides a quick way for patrollers to report these two circumstances to Meta administrators. Naleksuh does raise that point that Special:HandleReports should not be the exclusive remit of Meta administrators and, while this is certainly true, given its limited purpose for reporting either (a) blatant vandalism or (b) revisions requiring revision deletion, the only other potential group capable of actioning at least one of those two reports would be rollbackers, and that's definitely something we could explore in the future if there's a need, but for the moment, it's best to further codify our guidelines on the recently added Report tool and assess its utility over the next several months. If we find it's quite useful, then we can potentially look to adding rollbackers to the groups capable of actioning at least some of the reports. If we find it's not very useful or little used, then we can look to disable the extension on Meta. Dmehus (talk) 07:24, 18 December 2020 (UTC)

Support I believe patrollers should be able to make use of this extension for the time being. They are trusted enough in most cases to be able to figure out when to use it and when not to. Hypercane (talk) 06:51, 19 December 2020 (UTC)

Oppose

Allowing only users with increased user groups to merely submit reports (not handle), that goes against the entire purpose. That said, the suitability of this extension at all is questionable. Naleksuh (talk) 19:12, 17 December 2020 (UTC)
Oppose I find that allowing only the patroller user group to submit reports with this extension to be a waste (lack for a better word). There aren't too many patrollers (I think so at least) to simply report questionable revisions. Waldo (talk) 21:40, 19 December 2020 (UTC)
"There aren't too many patrollers (I think so at least) to simply report questionable revisions." There are not too many active patrollers currently but the number is enough, in my opinion. R4356th (talk) 21:43, 19 December 2020 (UTC)
If this is being used for the purpose of allowing people to report things to sysops in private, surely everyone should have that right? John (talk) 18:04, 20 December 2020 (UTC)
Agreed with above Bray (talk) 03:27, 22 December 2020 (UTC)
Oppose Per Naleksuh and John. Danner (talk) 08:01, 28 December 2020 (UTC)
Oppose I agree with Naleksuh. Frigg (talk) 18:39, 19 January 2021 (UTC)
Oppose Completely agree with Waldo. Integer ^talk 18:44, 19 January 2021 (UTC)

Neutral/Abstain

Proposal 2: Move `report` to the patroller and autopatrolled user groups

Rationale: Patrollers and administrators are the two primary user groups on Meta Wiki that patrol, respond to, and otherwise handle, new edits and pages on this wiki. Additionally, autopatrolled users are trusted users on Meta Wiki who can be trusted with this additional user right and, if misused after being warned and/or cautioned, can be a reason for revoking the user group.

Support

Support I see no reason to restrict it to patrollers only, and autopatrolled is a group where only trusted users are in. Justarandomliberal (talk) 00:18, 17 December 2020 (UTC)
Support This proposal seems to be the best compromise between users (who can misuse the tool) and patroller access only (who will be sad to restrict to only a few users) HeartsDo (Talk / Global / Wiki Creator) 05:55, 17 December 2020 (UTC)
Strong support per my articulated proposal rationale, @Justarandomamerican and HeartsDo: above, and as I articulated in my comments here and here in reply to Naleksuh, the Report has a narrow scope of utility and will be used chiefly, if not exclusively, for reporting only either (a) blatant vandalism or (b) revisions requiring revision deletion by an administrator, who would then refer to a steward privately where suppression is required. It would not be used for any other purpose besides those two described and articulated purposes. We're already reporting these things, nearly exclusively, through private Discord and IRC channels and/or through direct messages, so this just provides a quick way for patrollers to report these two circumstances to Meta administrators. At the same time, as Justarandomliberal and HeartsDo articulated above, it's also reasonable to allow trusted autopatrolled users to report these problems on-wiki. Naleksuh does raise that point that Special:HandleReports should not be the exclusive remit of Meta administrators and, while this is certainly true, given its limited purpose for reporting either (a) blatant vandalism or (b) revisions requiring revision deletion, the only other potential group capable of actioning at least one of those two reports would be rollbackers, and that's definitely something we could explore in the future if there's a need, but for the moment, it's best to further codify our guidelines on the recently added Report tool and assess its utility over the next several months. If we find it's quite useful, then we can potentially look to adding rollbackers to the groups capable of actioning at least some of the reports. If we find it's not very useful or little used, then we can look to disable the extension on Meta. Dmehus (talk) 07:17, 18 December 2020 (UTC)
Support Per the reasons stated above, I believe that, at least for starters this is the approach that we should adopt. There's not been enough time using this extension, and if this way proves to be ineffective, it can always be changed at a later time. Reception123 (talk) (C) 09:18, 18 December 2020 (UTC)
Support I also believe that autopatrolled users should be able to use this extension too. They are generally deemed trustworthy enough to do some more things than all users can. Hypercane (talk) 06:51, 19 December 2020 (UTC)
Support Since the autopatrolled and patroller user groups are given to trusted users only, I believe users in these user groups will be able to properly use the Report tool as I mentioned in my comment opposing Proposal 4. We should also consider adding guidelines on using this tool. R4356th (talk) 19:42, 19 December 2020 (UTC)

Oppose

Allowing only users with increased user groups to merely submit reports (not handle), that goes against the entire purpose. That said, the suitability of this extension at all is questionable. Naleksuh (talk) 19:12, 17 December 2020 (UTC)
Procedurally per above rationale by me. John (talk) 18:05, 20 December 2020 (UTC)

Neutral/Abstain

Comment: As in my opinion I do think perhaps we can limit it to autopatrolled users while experimenting this tool (Reporting tool) just for the time being Cocopuff2018 (talk) 21:50, 19 December 2020 (UTC)

Proposal 3: Maintain status quo

Rationale: All users should be able to report problematic revisions. Downside of this, though, is that one's user privileges cannot be revoked, and blocking users after warnings on misuse seems heavy handed.

Support

Support If staff can help users gage what qualifies as a reportable rev (which is anything that compromises the wiki) then all users should be able to report. Afterall anyone can report by default (extension or not). Waldo (talk) 00:23, 17 December 2020 (UTC)
Support I do not think two reports are enough to decide it is time to restrict this right to users in specific user groups. R4356th (talk) 07:55, 17 December 2020 (UTC)
Support The two uses of it might have been incorrect but we could add guidance and help users. If there was a clear sign over numerous occasions, I might consider it. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 13:58, 17 December 2020 (UTC)
Support per Rhinos Zppix (Meta | Sysadmin | talk to me) 14:03, 17 December 2020 (UTC)
Support per R4356th and RhinosF1. --Sabelöga (talk) 01:31, 18 December 2020 (UTC)
Support per above Bray (talk) 03:55, 19 December 2020 (UTC)
Strong support I have a great feeling that continuing to let all users use this extension to be a worthy move. Danner (talk) 07:16, 19 December 2020 (UTC)
Support per R4356th and RhinosF1. Frigg (talk) 18:22, 28 December 2020 (UTC)

Oppose

I consider the "status quo" to be not having this extension, especially since it was installed only four days ago. Naleksuh (talk) 19:12, 17 December 2020 (UTC)
Oppose per my articulated comments in the proposal rationale/lede, and per my voting argument in favour of Proposal 2, the Report extension would be used only for reporting (a) blatant vandalism or (b) revisions requiring revision deletion. While it would be wonderful to allow all registered, logged in users to use this tool, the reality is that, without a lack of codified guidelines, the probability for a high number of superfluous and incorrect reports is high, needlessly wasting limited volunteers' time that is both scarce and valuable. Thus, it is better to allow both experienced patrollers and trusted, experienced autopatrolled users to make these limited reports. Users wishing to report such things can reach out to a patroller or Meta administrator privately via e-mail or on Discord and IRC, as we're already doing anyway. Moreover, once we've codified the guidelines further in a few months' time, we can always have a brief community discussion at Meta:Administrators' noticeboard to expand the usage of the tool to the user group. However, at present, since we have no way to revoke one's user group, this proposal is non-viable for my articulated reasons. Dmehus (talk) 07:41, 18 December 2020 (UTC)
2 reports aren't enough of a pattern. You could also create guidelines. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 08:42, 18 December 2020 (UTC)
The guidelines will be developed over the next several months, but as I've articulated here, here, and elsewhere, this is a bit like putting the proverbial cart before the horse, particularly when you consider our very scare and limited volunteers' time. Moreover, as I've said, this tool is of very little utility to ordinary users anyway. Dmehus (talk) 08:49, 18 December 2020 (UTC)
Oppose I do not believe that all logged-in users should be able to use the report extension at this time. Not only the fact that we all know it will be misused if it is extended that far but a lot of nonsense reports could come out of it too. Maybe once a general guideline of sorts is established I could perhaps consider it, but not right now. Hypercane (talk) 06:51, 19 December 2020 (UTC)
Oppose Per the comments made about by Dmehus and Hypercane. Since this extension is new and rather experimental (it was approved for that purpose) I feel it's a better idea to limit it to specific groups at the beginning and see if it works out, and consider expanding it with further guidelines. I don't feel like this extension replaces reporting altogether, which can and should still be done via M:AN or by contacting a sysop otherwise (on-wiki or via the other platforms). Otherwise, I feel like rather than allowing everyone to use it, the extension should be disabled until further discussion. Reception123 (talk) (C) 18:32, 19 December 2020 (UTC)
Status quo is misleading, so I can't support it by nature of the definition. Agree on a procedural basis with Naleksuh. John (talk) 18:06, 20 December 2020 (UTC)
Strong oppose Agree with what is said above. It is not at all clear what the "status quo" even is as it was never really clearly said what the Report extension should be used for. I think that moving forward it is not possible to keep the "status quo" and have a very ambiguous and uncertain use of this extension. If this extension is desired, there should be a Request for Comment to define how it will be used, in what circumstances and by which users. DeeM28 (talk) 08:55, 24 December 2020 (UTC)

Neutral/Abstain

Proposal 4: Remove report extension

Support

It seems to have been added without nearly a wide enough community discussion, based on a select few users and it being enabled without any community discussion at all. I certainly wasn't aware of it being enabled until I had seen this. Its suitability for Meta is also questionable as well, and I likely would have opposed it being added. A "report" system goes essentially in the opposite direction a community-driven wiki should go, both in not allowing the community to review such things (hiding them to sysops only, especially things that should not be hidden), and in treating sysops like an "aura of authority". In addition, there is not really a good answer as to who should be able to handle them as it wildly depends on the content of the report—how Miraheze has been doing it for the last 5 years was perfectly fine if not preferable over this extension. Naleksuh (talk) 19:12, 17 December 2020 (UTC)
@Naleksuh: Thank you for your comments, for which I'm happy to correct a few points, which may have led to a misunderstanding on the Report extension's use case on Meta. First of all, extensions on Meta Wiki can be enabled with or without a discussion, depending, usually, on how significant or large the extension is. For example, we'd want to have to discussion to enable something like SocialProfile (which I'd oppose, likely strongly, by the way), and something like CommentStreams or WikiForum would also probably be good to have at least a longer discussion if not a formal community proposal. However, we do enable more minor or small extensions semi-frequently. Regarding the main concern of your argument, part of the confusion seems to stem from how this extension proposed to be used. Admittedly, when it was briefly discussed above, we didn't articulate clearly how it would be used, preferring to draft guidelines over the next month or two instead. However, that's been corrected with this proposal, and, indeed, it would only be used for reporting (a) blatant vandalism requiring deletion or other action by an administrator or (b) revision deletion. In terms of the latter, contrary to the Wikimedia projects, it has been standard practice on Miraheze to either (a) revision delete or (b) suppress revisions where it is either likely or known that a registered Miraheze user has edited while logged out, mainly to help safeguard users' privacy rights. As such, it would be highly inappropriate to report this on a noticeboard. In terms of the former, it would also be a spectacular waste of time and an exercise in bureaucracy to report blatant vandalism on a noticeboard, which, generally speaking, we aren't doing anyway, as this is most commonly reported through direct messages on Discord or IRC or through the #miraheze-cvt ^connect channel on IRC. So, without the extension, it's not like we'd suddenly be making such reports on-wiki, so the transparency argument is misapplied in my view. Dmehus (talk) 01:53, 18 December 2020 (UTC)
Sure, however I think that is such a limited use case and that most uses would be misuses, that it would be better to not have it at all. In addition, like I said before, I also think a "report system" and allowing sysop to handle them completely misrepresents the role of a sysop. I also think that who should be responsible for handling them wildly varies based on the content of the so-called reports. Ultimately even for things such as editing while logged out it is simply better to keep things how they were. Naleksuh (talk) 05:18, 18 December 2020 (UTC)
I disagree that a "report system" allowing administrators to handle them misrepresents the role of an administrator. If the tool is being used only for handling blatant vandalism and revision deletion, the latter of which can only be handled by administrators, why would it make sense to give Meta patrollers access to handle the reports? I mean, sure they could be permitted to handle the superfluous or incorrect reports, certainly, but then that's a stronger argument toward restricting use of the report tool to patrollers, autopatrolled users, or really any pertinent role that can be revoked because, as I said above and in my proposal, we can't simply revoke the user group. Some vandalism could be handled by rollbackers, yes, so perhaps that could be given access to handle at least some valid reports, and that can be added at some point in the future if there's both a need and a use case, with at least a brief discussion at Meta:Administrators' noticeboard. As to your latter point, I'm not sure whether you mean we should not revision delete/suppress the revisions of known or likely logged out users, or if you mean we should retain the current practice of reporting such things exclusively on Discord and IRC in private channels/direct messages, and certainly we would continue doing the latter regardless of the outcome of this extension's use on Meta Wiki. I just think it is worth trying this extension out. If we feel it's of limited to no utility in a few months' time, then, sure, let's have another community discussion to remove the extension at that time. Dmehus (talk) 05:39, 18 December 2020 (UTC)
Support. Was enabled without some discussion, then was created this "RfC" after some two reports. Bizarre...--MrJaroslavik (talk) 16:59, 18 December 2020 (UTC)
I just wanted to point out that there was a brief discussion here and you could had expressed your views as a Meta Sysop there. R4356th (talk) 17:18, 18 December 2020 (UTC)
Are you talking about that 30-hour "discussion" above? It was request, not discussion. Not enough time to reply. There was not consensus for enabling. Tbh, I was not sure what this extension is until I saw box about 1 unhandled report in RC. But I can still say that the discussion was not long enough. --MrJaroslavik (talk) 17:39, 18 December 2020 (UTC)
While I agree that the extension has limited utility, which is why I've articulated restricted use to either, or both, of the patroller and/or autopatrolled groups, I would just point out from a procedural point of view that Meta Wiki has a somewhat complicated governance structure in that it is a Steward-managed wiki, with Meta bureaucrats closing local RfCs and discussions and Meta permissions requests requiring an election. Extensions can be, and have been, enabled on Meta without a discussion; it is within the discretion of Stewards to decide on the significance of the extension to decide whether to require a discussion. In this case, there actually was at least a brief discussion. At any rate, consensus is not specifically required. I do think it's fine to try this extension out, but without codified guidelines on its use, it's best to restrict to the aforementioned group(s). If in a few months' time, it's proving to be rather useless, then I'd support disabling, absolutely. Dmehus (talk) 18:18, 18 December 2020 (UTC)
"Are you talking about that 30-hour "discussion" above?" Yes, I indeed am. "There was not consensus for enabling." How is that? There was no comment opposing installing the extension unless you mean there was not any community discussion. But even then I would say that it was a community discussion in a way considering that anyone in the community could reply to the discussion. R4356th (talk) 18:29, 18 December 2020 (UTC)
Yes, there were no comments for it because there was no opportunity for such comments to be written. There was no site notice, notification, or any other way to know that such a proposal was taking place (it was simply stacked here as a standard noncontroversial request, unlike this massive RfC after it was already enabled). And it did not run for nearly long enough, it was simply requested then added. The claim that there were no comments in opposition is also provably flawed, because had I been aware of that discussion then there would have been a comment in opposition. Naleksuh (talk) 20:03, 18 December 2020 (UTC)
^ Yes, That's something I can agree with.--MrJaroslavik (talk) 20:28, 18 December 2020 (UTC)
Well, if I'd just point out one thing from a procedural standpoint as a Steward-managed wiki, assisted in certain aspects of its management by local Meta bureaucrats, there's never been a requirement to have a community discussion at all. Stewards exercise good discretion in deciding what extensions should have discussion, what should have a larger RfC, and what can be enabled without a discussion, with or without a brief notification to the community of the enabling. In this case, we opted for a discussion, though being only one relatively minor extension, a sitenotice was not contemplated. Additionally, we have to balance what we will do sitenotices and central notices for, so as not to have more than one or two sitenotices at a time. At the same time, this also has to balanced out with mandatory system maintenance and other community central notices and system-wide sitenotices. Dmehus (talk) 05:30, 19 December 2020 (UTC)
It takes reporting away from the standard open and transparent values and places it onto a page which is hidden and not open to scrutiny. I don't feel we need this extension, and neither do I feel it adds any benefit to the community at hand. As an administrator, I wouldn't utilise such a system and wouldn't regularly check and audit the usage of it either as it unnecessarily adds another thing for us to check and another thing for us to monitor. John (talk) 21:01, 19 December 2020 (UTC)
As well from a procedural stand point, I feel an extension like this should have had consensus before adding. This arguably has a material impact on the workflow and operation of how users report issues and how sysops react. To state this was a Steward's discretion to materially change an entire wikis workflow, to me, is a problem as it gives the impression Stewards are able to tell the community how they work without a real consultation of the community at hand. Minor extensions can be added without consensus, I do agree, but this isn't minor as it changes workflows that are established over years. John (talk) 21:09, 19 December 2020 (UTC)
@John: This specific extension could've perhaps used a longer discussion, though, from a procedural standpoint of the two most active Meta administrators being in agreement, it was nonetheless reasonable, I think, given that so many of our conventions and customs are non-codified, and we mainly have to rely on past Steward actions enabling extensions. Additionally, it was never meant to be a major change in the workflow patterns, and was enabled as part of a trial to see if it could be useful. The idea behind it was only to use it for reporting revisions requiring revision deletion, which should never be reported publicly, and, potentially, for blatant vandalism (of which there is not too much). Dmehus (talk) 21:29, 19 December 2020 (UTC)
Two active administrators don't really form a basis for consensus though - especially when Bureaucrats are the ones who are responsible for determining local consensus on Meta. Personally, consensus should have been formed prior to enabling, not after. To not acknowledge this is a material change in workflow is lacking as prior workflow has always been to contact an administrator or post on the noticeboard, not press a link to fill out a form to notify an administrator entirely in private in a way more easily done than publicly. Revision deletions sure can be done this way, but what about oversights? Surely they should be entirely private to a Steward only as is the process, so this would require local understanding of what is a revision deletion action and what requires a suppression. To me, this is an attempt to legitimise a wrongly done process and if anything, can be viewed as leading consensus as would the consensus have been in favour of enabling this extension over disabling it? John (talk) 21:38, 19 December 2020 (UTC)
With regard to the point about the material change in administrator workflow, I certainly wasn't aware of a local policy that required any changes to administrator workflow should be notified to fellow administrators before implementing. An example of this was when I established the Mirahezians looking for help and Mirahezians looking for help from administrators {{help me}} categories and template, as a new and improved way of providing on-wiki assistance with users' wikis. Sure, I hadn't let you know of that, maybe, but I had advised Reception123 and a few of our most active patrollers to regularly monitor the categories, but a communication about that is on my to-do list, so my thinking is as long as the most active administrators and patrollers are aware of it, that's fine, as we are volunteers with busy schedules, work volumes, and multiple roles, so there really are no deadlines, too. As long as the implementing administrator discusses with one or more active administrators who, in turn, notify the less active administrators of an additional option, and to be clear, that's all this is, an additional option, I think that's fine because, let's face it, we're all very busy and with multiple roles and tasks, not to mention the different time zones in which everyone is located. In addition to this being only an additional option, I would just note that this was also only being enabled as a test as a test to see if it is useful. With regard to oversight, no requests for oversight would not not be done directly by patrollers, autopatrolled users, or registered users, as applicable, only requests for revision deletion would be done in this way. If suppression was required, then the administrator would notify a steward through private channels (IRC or Discord typically). As to the latter point, no that's not what this is as all. This proposal was implemented simply to correct something that hadn't been thought of in the initial request on this noticeboard, which is about which user groups should be able to use the Report tool during the testing phase. As well, I'm not sure how you can say consensus should've been formed before, not after, since extensions have been enabled frequently without consensus by various Stewards based on the implementing Steward's discretion in terms of determining how major or minor it is. So that's all I'm saying, which is notion that there was anything procedurally wrong with enabling this extension given wide Steward discretion and past precedents in this area is simply incorrect. Dmehus (talk) 05:50, 20 December 2020 (UTC)
"I certainly wasn't aware of a local policy that required any changes to administrator workflow should be notified to fellow administrators before implementing." Is it not common courtesy to involve administrators in discussion about changes that affect them? I know there is no local policy, but do we really need to codify common courtesy in that no one can unilaterally change how everyone else works without a proper discussion? "so my thinking is as long as the most active administrators and patrollers are aware of it, that's fine" so, if you wanted to modify a policy, as long as you notify the most active users that you intend to change it, you can do so without a community discussion on a policy change? "With regard to oversight, no requests for oversight would not not be done directly by patrollers, autopatrolled users, or registered users, as applicable, only requests for revision deletion would be done in this way. If suppression was required, then the administrator would notify a steward through private channels (IRC or Discord typically)." The original user should really be seeking to make the report, not an administrator for which it was referred to. "This proposal was implemented simply to correct something that hadn't been thought of in the initial request" So, my point is correct? This discussion is to essentially normalise a feature enabled without community consensus, with the community asked to consider how to use it - not whether to use it at all. The fact this option had to be added on after is mildly concerning as it shows a lack of respect for the community in that they're not asked whether to enable a feature - only administrators seemingly are, and then when its enabled, they're asked to consider how to use it, not being asked if they should even want it. "given wide Steward discretion", that policy doesn't give Stewards discretion to do as they want though. In fact, you're the first Steward to enable things solely as a Steward without a Bureaucrat either approving it or acknowledging it. So previous discretion was a local Bureaucrat as well, enacting a change they felt that either didn't need a consensus as it was minimalistic in change or for which there was a valid rationale request/consensus over. The fact this was a test to see if it worked shows there wasn't a rationale request besides "let's test it", the change wasn't minimalistic as it moves users reporting problems away from the established convention and there wasn't consensus either. It also can't be argued the community approved of this because as shown here, 3 have opposed its addition, there was only a 30 hour unadvertised conversation as well. I have serious concerns at the minute over the lack of contempt of the community here, in that you are continuing to argue your point of "I didn't need to ask the community" when you are being asked why you didn't ask the community. John (talk) 15:14, 20 December 2020 (UTC)
"The original user should really be seeking to make the report, not an administrator for which it was referred to," well, yes, but per the Meta administrator conventions of which I was advised by multiple current Meta administrators that joined the team before me, convention is to revision delete or suppress the revisions of known or likely logged out users. Indeed, as a community member, I have privately reported such revisions to existing Stewards privately (usually on Discord), and frequently, and promptly, received an obliging ":thumbsup:" emoji and notification that it had been done. "So, my point is correct?" On that point, yes, I do agree that more thought was needed, which could've been helped by a longer discussion; however, the part that I take issue with is where you write that it is to "normalise a feature enabled without community consensus," since, as you told me on IRC, extensions can be enabled without having had a formal community proposal or at least a discussion (this actually had a discussion, albeit one that was not long enough inevitably). Perhaps we could do well to have some codified guidelines in terms of what extensions can be enabled without a discussion? "In fact, you're the first Steward to enable things solely as a Steward without a Bureaucrat either approving it or acknowledging it," is not accurate, as Reception123 approved of and acknowledged it being enabled. Dmehus (talk) 18:06, 20 December 2020 (UTC)
"convention is to revision delete or suppress the revisions of known or likely logged out users", policy is to suppress per Oversight which states that this is the "tool of first resort in removing this information.", not revision deletion. Convention of revision deletion is a poor practise from a security and privacy stand point per the Streisand effect, which is why I've never advocated this, most people working in a privacy or security field won't and why when I see people advocate it, I tell them not too. It also holds the unintended consequence of spreading the information more than it would have before and potentially having no Oversight action taken because most administrators don't end up contacting for an Oversight and just expect it to happen. "extensions can be enabled without having had a formal community proposal or at least a discussion", yes, can, within reason. Just because it can, doesn't mean it should - as a Steward you can grant everyone CheckUser, it doesn't mean you should. "Reception123 approved of and acknowledged it being enabled", I will have a discussion with Reception123 about the role of a Bureaucrat and extensions then, as he shouldn't have approved enabling it unless he was certain it wouldn't have been disputed - which he acknowledged when he stated "As for Report, I'm not sure how useful it would be to us really," which should have automatically triggered him to refer it to a community discussion. John (talk) 18:17, 20 December 2020 (UTC)

And after reviewing the discussion in more detail, I see that you said, "considering that Meta administrators are the only ones that would be viewing the special page, I would say no, actually. And actually, that would be a stronger argument against requiring a formal community proposal to enable the extension". I am extremely concerned that a Steward is advocating against community consensus, when the policy page for Stewards says "Stewards will work with communities". John (talk) 15:26, 20 December 2020 (UTC)
@John: With respect, that's absolutely not what I meant by that, and is possibly either an unfair characterization or a misunderstanding. I would never advocate against the community's consensus, which is why I firmly believe that whenever an extension is enabled on Meta without a discussion, the Steward should notify the community on the applicable noticeboard. Per the conversations I had with you privately on IRC, I was given to understand that you agreed with that approach. I simply meant that it is potentially a stronger argument for being one of the extensions that could be non-controversially enabled without a lengthy discussion or formal proposal. Dmehus (talk) 17:51, 20 December 2020 (UTC)
While your intention may not have been it, it can be clearly inferred from such a comment. I do agree with the approach of notifying the community when an extension is enabled without the necessity, it such be a rarity such an approach. The general understanding of the discussion at hand seems to be because the change only impacts administrators, the community don't need to be consulted on it. Non-controversial extensions arguably don't need a community consensus - such extensions are ones of minimal to no impact whereby no reasonable person would dispute the addition and whereby those approving or wanting of it, do so without condition. The fact this extension is labelled as a test on Meta and where the only other person involved in the discussion doesn't seem entirely convinced the extension is a great addition permanently would suggest consensus should have been sought as it's not clearly non-controversial. John (talk) 18:00, 20 December 2020 (UTC)
With respect to inferences, that's true, yes, but I would just note that inferences can be incorrect, and, in this case, they were. I'm not sure what you mean by there only being one other person involved in the discussion, as R4356th and Reception123 (in addition to me) were involved in the discussion. Admittedly, like Reception123, I, too, was a bit skeptical as to its utility, but I wouldn't have necessarily equated potential lack of utility with being not non-controversial. The two are mutually exclusive, I feel. Nevertheless, I still do feel this extension's potential utility is minimal, which together with the lack of guidelines on use and the fact that it is a test, I've opposed Proposal 3. That being said, to say that I have taken this discussion with the community to heart would be an understatement. I have, and will instead either (a) require a full discussion lasting preferably at least five (5) calendar days or (b) ask you for a second opinion on whether an extension is minor and non-controversial enough to be enabled with only notification to the community. Additionally, given that, I will also be moving my "weak oppose" argument for Proposal 4 to a "weak support" per this reply. Dmehus (talk) 18:20, 20 December 2020 (UTC)

I can absolutely agree with points by John + yet my comment - If you think you can do whatever you want, you should not be a steward. And where is it said that everything on the Meta is under Stewards discretion?--MrJaroslavik (talk) 15:24, 20 December 2020 (UTC)
There is some confusion that I have with this, but I do not think anyone said they thought they could "do whatever they want" I think saying that that was said is an exaggeration. Maybe I am wrong but is it not the case that Meta bureaucrats are the ones responsible for making decisions regarding Meta? I am not very sure what part Stewards play on Meta, as they are supposed to be a global role and there is no reason why Meta should not have its own community and its own bureaucrats. DeeM28 (talk) 09:00, 24 December 2020 (UTC)
Hello @DeeM28: For many times i saw reply of Dmehus like "...is within the discretion of Steward..."- it is not okay, when this is not said in rule. Yes, Meta bureaucrats are the ones responsible for making decisions regarding Meta, this is true. MrJaroslavik (talk) 16:50, 24 December 2020 (UTC)

Support because I now agree with John on the affect this could have on the current workflow. I wouldn't want Meta to change to a point beyond recognition. Danner (talk) 17:32, 20 December 2020 (UTC)
In that case I think that you should change your vote for Proposal 3 as supporting removal of the extension is not really compatible with supporting to keep the "status quo". DeeM28 (talk) 09:02, 24 December 2020 (UTC)
Weak support per my comments in reply to @John: and in consideration of the entire discussion, I now feel that even one of the two proposed use cases for this extension, revision deletion, is weak considering that such revisions may be more easily overlooked for oversighting if revision deleted. Reporting blatant vandalism with this tool was always a bit of an edge case. That being said, I still feel that either Proposal 1 or 2, limiting the extension to select user groups for a trial, can always still be useful. Perhaps there will be other uses we didn't envision, even in this discussion. Thus, essentially Proposals 1 or 2 would be my first choice, with Proposal 4 a weak second choice. Dmehus (talk) 18:46, 20 December 2020 (UTC)
Support per John. Bray (talk) 03:00, 21 December 2020 (UTC)
Support Firstly I would like to say that in the future I think using the Request for comment space would be preferred rather than having such a long discussion on this page. The main reason for supporting removal is mostly what John said above, I think that there should have been a longer discussion before enabling this extension. The other problem is that (at least to me) it is very unclear in which cases this functionality would be used because there are no guidelines to explain to users where to report what, and I think that is very confusing. If a "trial" were to be done as it has been suggested by some I think it should be defined more clearly and have a clear goal. DeeM28 (talk) 08:53, 24 December 2020 (UTC)

Oppose

Oppose Waldo (talk) 23:45, 17 December 2020 (UTC)
@Waldo: Why exactly do you oppose? This is a discussion, not a vote. Naleksuh (talk) 00:14, 18 December 2020 (UTC)

@Waldo: I would concur with @Naleksuh: that, as I articulated in the reminder and explanatory notes following the background information on the proposal, all votes should be accompanied by an argument. The argument can very; arguments can be weaker or stronger. It is incumbent upon the closing bureaucrat to apply appropriate weight to all arguments made, as it's not simply about counting noses. Well, it can be, when the result is very clear. However, in particularly close results, votes without any arguments whatsoever can be discounted or even, where applicable and there is no indication of an implied argument, eliminated from consideration entirely, depending on the bureaucrat's assessment of the prevailing consensus. Dmehus (talk) 00:28, 18 December 2020 (UTC)
@Naleksuh: It's both. You don't need to tell me what I already know. @Dmehus: I want the extension to stay, which you can sense by my writing cues, such as me voting in favor for a different proposal while opposing this one. Here's your confirmation though since you somehow need it. Frankly not everyone has your length of free time. Waldo (talk) 02:03, 18 December 2020 (UTC)
@Waldo: Thank you, that's fine now then, yes. It was fair of @Naleksuh: to remind you to include an argument with votes, as we're not mind readers here, and others have observed in other discussions you including only a voting template and your signature. Indeed, @Reception123: was actually planning on reminding you of this point on your user talk page the next time you voted without making an argument. So, with this gentle reminder sidebar discussion, he no longer likely needs to do that. As to your final sentence, there's no need to personalize your arguments by including extraneous, negative, and hurtful comments directed towards me. That's not very nice. :( Dmehus (talk) 02:11, 18 December 2020 (UTC)
@Dmehus: Well it wasn't extraneous since I don't always have time to use my usual brain power (which is used–among many other things–for making coherent points) and I find being quick and efficient to work fine for me. It was negative and I will agree to that, sorry I was just trying to make it known that some people need to make way for hobbies with the short time they are given and writing short is supposed to help with that (for me at least). I pretty much have to stop soon now so I hope this ties some loose ends. Also you know Zppix has left out arguments too? I thought it was fine because he did it. Waldo (talk) 02:29, 18 December 2020 (UTC)
@Waldo: It absolutely was extraneous, as your passive aggressive and negative comment was directed towards and at me, not the discussion at hand. That's not okay, and cannot continue. As to your voting without an argument, it is okay as you didn't know at the time, but now you do know, so just keep that in mind for the future, okay? Related to that, if you do not have time to put together a thoughtful argument, then you do not need to rush to participate or vote in a discussion. Not everyone needs to participate in every discussion. It is best if you only participate once you have formulated and composed your argument. Regarding @Zppix: !vote, he actually did have an argument, in that he cited RhinosF1's argument. The only other one who did not have an argument, besides you, actually was @Universal Omega:, and I've just noticed that as well. I'm sure he will add to his vote in the next day or two. Hope that helps. Dmehus (talk) 02:45, 18 December 2020 (UTC)
@Dmehus: Zppix didn't add text besides his vote when voting for you for Steward. I believe Waldo meant that, not THIS particular vote. He may have done more than that in the past. Danner (talk) 05:54, 18 December 2020 (UTC)
@Danner: Yes, I suppose that's possible, yes, but at any rate, that's even less relevant as it wasn't in this discussion. Plus, I'm not sure about this apparent preference for citing Zppix as an example, too. Nonetheless, it's a minor point, and I've nonetheless articulated the explanation above to Waldo, so it's probably best not to beat this dead horse any longer. Dmehus (talk) 06:04, 18 December 2020 (UTC)
@Dmehus: "I thought it was fine because he did it." I assume that means he was explaining why he thought it was fine to vote without the text because a staffer did it too. Not irrelevant because understanding people is pertinent to seeing from a point of view and having empathy. Explanations are key. Danner (talk) 06:12, 18 December 2020 (UTC)
@Danner: For what it's worth, I didn't say it was an entirely irrelevant example; I said it was less relevant. And, indeed, as I have articulated, I have shown a tremendous amount of good-faith and empathy, as you say, in my explanations to Waldo that votes should be accompanied by arguments. I can see why he thought that it was acceptable, but it is nonetheless important to clarify this for him, as a number of examples of Waldo voting have been cited by Naleksuh, Reception123, myself, and others. As such, it's best to clarify than let incorrect assumptions continue. Thanks. Dmehus (talk) 06:20, 18 December 2020 (UTC)

I was wondering the same, it kind of feels like targeting Zppix (Meta | Sysadmin | talk to me) 06:43, 18 December 2020 (UTC)
Keep that to yourself next time, Zppix. You have no substance to go on. Danner (talk) 06:47, 18 December 2020 (UTC)
Hi, I do infact suggest you read up on all global and local policies before you continue to participate in discussions. Zppix (Meta | Sysadmin | talk to me) 07:03, 18 December 2020 (UTC)

Weak oppose per my voting argument in favour of Proposal 2, as the leading proposal, and my opposing rationale to Proposal 3, we can certainly consider removing the Report extension in a few months time if it is indeed proving to be rather useless, pointless, and generally unused. However, it's only been enabled for a few days, at best; what this needs is a bit of time—time both to assess its utility and to further codify our guidelines on how it should be used. Separately, as a procedural point of view, I noted that Naleksuh added Proposal 4 after the discussion had begun, which generally should not be done; however, since I did consider adding this Proposal 4 anyway to my community proposal set for discussion, and because only a limited number of voting arguments had been cast, it is acceptable that it was nonetheless added. That being said, it's far too early and we don't have enough hard data to assess its utility for the purposes of potential removal at this point. Now, come, say, March 2021, that would likely be a very different story. Dmehus (talk) 08:31, 18 December 2020 (UTC)
Strongest oppose as the person who requested this to be installed on Miraheze. I believe that this extension can be properly used and it is too early to decide if it is being useful or not. We should ideally have clear guidelines on how to use the extension instead as stated by RhinosF1. If any modifications to things related to this extension must be made then we should at least allow users in autopatrolled and patroller user groups to use it. R4356th (talk) 17:47, 18 December 2020 (UTC)
Oppose I do not believe we should remove it this soon without at least trying the extension first. If it doesn't work out later on, then I could support its removal, but not now. Hypercane (talk) 06:51, 19 December 2020 (UTC)
Strongly oppose per Hypercane. Danner (talk) 07:56, 28 December 2020 (UTC)
Weak oppose I am for giving the extension a chance. Bray (talk) 02:53, 30 December 2020 (UTC)
Oppose Put much thought into this. Settled on opposing removal since I have no problems toward the extension. Frigg (talk) 18:09, 6 January 2021 (UTC)
Oppose It's too early to decide whether to remove it or not, as there have only been 2 reports. Justarandomliberal (talk) 13:49, 7 January 2021 (UTC)
It has been used 7 times now (last time was 11 day ago). From a quick analysis, 3 reports should not have been reported to Administrators, but rather oversighters in a more private venue, 1 was a test report, 1 was a retaliatory complaint and 2 were legitimate reports. This means the extension so far has a successful rate of approximately 30%. John (talk) 16:29, 7 January 2021 (UTC)

Neutral/Abstain

Request for closure

Request for Uninvolved Stewards:

@NDKilla and Void: Could either of you please close this proposal? Dmehus and John are both involved in this request and therefore they may not be the best for closing this. And it has already been 34 days since this proposal was created. Redmin Contributions CentralAuth (talk) 09:57, 19 January 2021 (UTC)

R4356th This wouldn't be for a steward to close. NDKilla or Void should close only where a request has been made at stewards' noticeboard for steward closure because there are no other bureaucrats who are active. Though there's no policies against involved closures on Meta, it is a commonly accepted best practice or convention. In any case, Southparkfan is a Meta bureaucrat; however, I would ask for closure to not be invoked at the moment as I still have to respond to one or two comments, and modify one of my own votes. We can probably do well to let this continue for another week or perhaps two. Dmehus (talk) 11:00, 19 January 2021 (UTC)

@Dmehus: Oops, yeah, I forgot that Meta bureaucrats are supposed to do this. (You mentioning "techincally effected by a Steward" is what confused me.) Redmin Contributions CentralAuth (talk) 12:02, 19 January 2021 (UTC)

I extend the request for Stewards to step back from closing this unless requested by a Bureaucrat as I feel such an action would justify a discussion to restrict Stewards’ local abilities within Meta. I further note that if there is deemed to be no consensus for removing the extension - the extension should be disabled. With zero consensus to add the extension, unless there is a consensus now to add it, it would be an abhorrent abuse of Steward permission to subvert and remove the communities abilities to decide whether they want a useless extension, much rather later on going ‘you didn’t have consensus to add it, but you need consensus to remove it’. Further to this, the Steward who added it has advocated its removal agreeing it essentially was a breach of process. As a bureaucrat, involved or not, I can plainly see if this was a discussion to add the extension, it seems there would be no consensus to add it - so why shouldn’t the status quo which is this extension not be enabled, not be the case? John (talk) 11:59, 19 January 2021 (UTC)

Regarding both the act of closing this discussion, as well as your read of the discussion, I am in agreement. -- Void ^Whispers 18:41, 19 January 2021 (UTC)

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

Request for Rollback (Universal Omega)

Request for Patroller (Universal Omega)

Request for Patroller (CircleyDoesExtracter)

Request for patrollers (松・Matsu)

Request for Patroller (Bonnedav)

Request for Patroller (Hypercane)

Request for mergehistory to be added to the administrator user group

Support

Neutral/Abstain

Oppose

Discussion

Autopatrolled request

Special:MyLanguage and "tvar" tags on FAQ

Merge User:FireBarrier101/signature into User:FireBarrier101/sig

The section of the translation page is broken

Removal of the bot flags for Proxybot and Void-bot

Please block 2600:1700:50D0:ECC0:351F:B9E0:6C70:8A21

Moving a wiki to Miraheze is up for translation?

Archiving

Does Miraheze need translate rules?

Special:GlobalRenameRequest

Please can you delete my userpage at Meta

MediaWiki:Common.css

Double </language> tags

Request for interface-admin for Naleksuh

Request for Marking Discord/Ops for Translation

Request for interface messages MediaWiki:nstab-tech and MediaWiki:nstab-tech/ja

Request for Marking Discord/Verification/Intro for Translation

Requesting edit on Meta:General disclaimer

Possible new template I've been developing on the test wiki

Translatewiki

Translate Template:Translated

TOC right on Tech:Server admin log

Creating a Policy for Marking Pages for Translation

Edit request on Meta:Administrators

Requesting edit on MediaWiki:Sidebar

Request for deleting a page

Requesting edit on Meta:Copyrights

Please specify Category Pages as the translation target

Removing my interface-admin flag

I have destroyed User:Lily/global.js

Update list of current stewards at Stewards

I want to add a CodeMirror extension to this wiki

Unassigned user right unwatchedpages

Request for Enabling Extensions Report and EditCount

Enabled the Purge extension on Meta Wiki

Request to delete my Meta user page

Request for Updating FAQ

Discussion concerning MediaWiki:Mainpage-description

Request for Importing Some Userboxes from Login Wiki

Request for Updating Stewards, Global Sysops and Counter Vandalism Team

Potential Vandalism

Meta community proposal regarding the use of the Report tool

Proposal 1: Move report to patroller user group

Support

Oppose

Neutral/Abstain

Proposal 2: Move report to the patroller and autopatrolled user groups

Support

Oppose

Neutral/Abstain

Proposal 3: Maintain status quo

Support

Oppose

Neutral/Abstain

Proposal 4: Remove report extension

Support

Oppose

Neutral/Abstain

Request for closure

Request for `mergehistory` to be added to the `administrator` user group

Removal of the `bot` flags for Proxybot and Void-bot

Request for `interface-admin` for Naleksuh

Removing my `interface-admin` flag

Unassigned user right `unwatchedpages`

Proposal 1: Move `report` to patroller user group

Proposal 2: Move `report` to the patroller and autopatrolled user groups