Meta:Administrators' noticeboard: Difference between revisions

From Meta
m (Bot: Archiving 1 thread (older than 14 days) to Meta:Administrators' noticeboard/Archive 4)
(Move out-of-scope thread here from [[SN])
Line 201: Line 201:
 
:::For what it's worth, past practice on Meta Wiki with respect to importing versus copying and pasting has been...mixed, to say the least, often without even a required edit summary linking to the source page (via an [[Special:Interwiki|interwiki]] page link). Thus, while it's true attribution is required, full history attribution is ''not'' required, provided an edit summary link to the source page is included. Best practice here is to say something like <code><nowiki>Copied from [[w:Example]]</nowiki></code>, where <code>Example</code> is the source page from English Wikipedia. [[User:Dmehus|Dmehus]] ([[User talk:Dmehus|talk]]) 23:50, 20 January 2021 (UTC)
 
:::For what it's worth, past practice on Meta Wiki with respect to importing versus copying and pasting has been...mixed, to say the least, often without even a required edit summary linking to the source page (via an [[Special:Interwiki|interwiki]] page link). Thus, while it's true attribution is required, full history attribution is ''not'' required, provided an edit summary link to the source page is included. Best practice here is to say something like <code><nowiki>Copied from [[w:Example]]</nowiki></code>, where <code>Example</code> is the source page from English Wikipedia. [[User:Dmehus|Dmehus]] ([[User talk:Dmehus|talk]]) 23:50, 20 January 2021 (UTC)
 
:[[User:R4356th|R4356th]] I don't see where there's a Lua error on either [[Template:Documentation]] or [[Template:Documentation/doc]]. Can you clarify what you mean just a bit? Thanks. [[User:Dmehus|Dmehus]] ([[User talk:Dmehus|talk]]) 23:52, 20 January 2021 (UTC)
 
:[[User:R4356th|R4356th]] I don't see where there's a Lua error on either [[Template:Documentation]] or [[Template:Documentation/doc]]. Can you clarify what you mean just a bit? Thanks. [[User:Dmehus|Dmehus]] ([[User talk:Dmehus|talk]]) 23:52, 20 January 2021 (UTC)
  +
  +
== Category:Wikipedia pages with incorrect protection templates ==
  +
  +
Today I present to you a problem that has me completely baffled. If you look at <code>Category:Wikipedia pages with incorrect protection templates</code>, you can see that it has only translations of [[Custom domains]]. That said, the reason that it says "incorrect protection template" is most likely because the original [[Custom domains]] is in fact protected, but that doesn't carry over for translations. Do you think there is a fix to this or will this be permanent? Just to clarify once again, this is regarding <code>Category:Wikipedia pages with incorrect protection templates</code> --[[User:Integer|<font face="Roboto" color="#65e6ce"><b>Integer</b></font>]] [[User_talk:Integer|<sup>talk</sup>]] 03:55, 21 January 2021 (UTC)

Revision as of 07:55, 21 January 2021

OOjs UI icon pageSettings.svg Administrators' noticeboard
Shortcuts:
AN,
Meta:AN
This noticeboard is for anything that requires administrator intervention on Meta only (anything related to global policies, global groups, or in some way involves other Miraheze wikis should be discussed at the Community noticeboard)

On the Meta Administrators' noticeboard, you can request...

If you would like to request...

To add your request, type in a title and click the "Add Topic" button below.

Archives of Administrators' noticeboard [e]   



Meta community proposal regarding the use of the Report tool

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)[reply]

Notes:

  1. 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.
  2. 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.
  3. 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

  1. Symbol support vote.svg 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)[reply]
    Considering that I was the first to use this tool before anyone else can, apparently. DarkMatterMan4500 (talk) (contribs) 00:19, 17 December 2020 (UTC)[reply]
  2. Symbol support vote.svg Support
  3. Symbol support vote.svg 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)[reply]
  4. Symbol support vote.svg 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)[reply]

Oppose

  1. 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)[reply]
  2. Symbol oppose vote.svg 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)[reply]
    "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)[reply]
  3. 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)[reply]
  4. Agreed with above Bray (talk) 03:27, 22 December 2020 (UTC)[reply]
  5. Symbol oppose vote.svg Oppose Per Naleksuh and John. Danner (talk) 08:01, 28 December 2020 (UTC)[reply]
  6. Symbol oppose vote.svg Oppose I agree with Naleksuh. Frigg (talk) 18:39, 19 January 2021 (UTC)[reply]
  7. Symbol oppose vote.svg Oppose Completely agree with Waldo. Integer talk 18:44, 19 January 2021 (UTC)[reply]

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

  1. Symbol support vote.svg 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)[reply]
  2. Symbol support vote.svg 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)[reply]
  3. Symbol strong support vote.svg 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)[reply]
  4. Symbol support vote.svg 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)[reply]
  5. Symbol support vote.svg 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)[reply]
  6. Symbol support vote.svg 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)[reply]

Oppose

  1. 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)[reply]
  2. Procedurally per above rationale by me. John (talk) 18:05, 20 December 2020 (UTC)[reply]

Neutral/Abstain

  1. Pictogram voting comment.svg 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)[reply]

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

  1. Symbol support vote.svg 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)[reply]
  2. Symbol support vote.svg 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)[reply]
  3. Symbol support vote.svg 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)[reply]
  4. Symbol support vote.svg Support per Rhinos Zppix (Meta | Sysadmin | talk to me) 14:03, 17 December 2020 (UTC)[reply]
  5. Symbol support vote.svg Support per R4356th and RhinosF1. --Sabelöga (talk) 01:31, 18 December 2020 (UTC)[reply]
  6. Symbol support vote.svg Support per above Bray (talk) 03:55, 19 December 2020 (UTC)[reply]
  7. Symbol strong support vote.svg 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)[reply]
  8. Symbol support vote.svg Support per R4356th and RhinosF1. Frigg (talk) 18:22, 28 December 2020 (UTC)[reply]

Oppose

  1. 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)[reply]
  2. Symbol oppose vote.svg 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)[reply]
    2 reports aren't enough of a pattern. You could also create guidelines. ~ RhinosF1 - (chat)· acc· c - (on) 08:42, 18 December 2020 (UTC)[reply]
    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)[reply]
  3. Symbol oppose vote.svg 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)[reply]
  4. Symbol oppose vote.svg 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)[reply]
  5. 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)[reply]
  6. Symbol oppose vote oversat.svg 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)[reply]

Neutral/Abstain

Proposal 4: Remove report extension

Support

  1. 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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
  2. Support. Was enabled without some discussion, then was created this "RfC" after some two reports. Bizarre...--MrJaroslavik (talk) 16:59, 18 December 2020 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    "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)[reply]
    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)[reply]
    ^ Yes, That's something I can agree with.--MrJaroslavik (talk) 20:28, 18 December 2020 (UTC)[reply]
    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)[reply]
  3. 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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    "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)[reply]
    "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)[reply]
    "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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Symbol support vote.svg 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)[reply]
    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)[reply]
  4. Symbol partial support vote.svg 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)[reply]
    Symbol support vote.svg Support per John. Bray (talk) 03:00, 21 December 2020 (UTC)[reply]
  5. Symbol support vote.svg 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)[reply]

Oppose

  1. Symbol oppose vote.svg Oppose Waldo (talk) 23:45, 17 December 2020 (UTC)[reply]
    @Waldo: Why exactly do you oppose? This is a discussion, not a vote. Naleksuh (talk) 00:14, 18 December 2020 (UTC)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    I was wondering the same, it kind of feels like targeting Zppix (Meta | Sysadmin | talk to me) 06:43, 18 December 2020 (UTC)[reply]
    Keep that to yourself next time, Zppix. You have no substance to go on. Danner (talk) 06:47, 18 December 2020 (UTC)[reply]
    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)[reply]
    Weak Oppose.svg 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)[reply]
  2. Symbol full oppose vote.svg 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)[reply]
  3. Symbol oppose vote.svg 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)[reply]
  4. Symbol oppose vote oversat.svg Strongly oppose per Hypercane. Danner (talk) 07:56, 28 December 2020 (UTC)[reply]
  5. Weak Oppose.svg Weak oppose I am for giving the extension a chance. Bray (talk) 02:53, 30 December 2020 (UTC)[reply]
  6. Symbol oppose vote.svg 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)[reply]
  7. Symbol oppose vote.svg 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)[reply]
    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)[reply]

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. User:R4356th/Signature 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)[reply]
@Dmehus: Oops, yeah, I forgot that Meta bureaucrats are supposed to do this. (You mentioning "techincally effected by a Steward" is what confused me.) User:R4356th/Signature 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)[reply]
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)[reply]

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)[reply]

@R4356th: Pictogram voting wait.svg In progress.... Dmehus (talk) 20:43, 8 January 2021 (UTC)[reply]
@R4356th: Yes check.svg Done Dmehus (talk) 01:27, 9 January 2021 (UTC)[reply]
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)[reply]
@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)[reply]
Ah, Yes check.svg I see. Thank you. R4356th (talk) 16:46, 9 January 2021 (UTC)[reply]

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)[reply]

@R4356th: The change you requested has been Yes check.svg 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)[reply]
@Dmehus: Thank you very much. I was just curious about the Steward part. :) R4356th (talk) 11:17, 13 January 2021 (UTC)[reply]
@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)[reply]
@R4356th: Yes check.svg 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)[reply]
Thank you for fixing it. R4356th (talk) 16:25, 13 January 2021 (UTC)[reply]
No problem. Dmehus (talk) 16:25, 13 January 2021 (UTC)[reply]

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)[reply]

Yes check.svg Marked at deletion and warned by me and deleted by Dmehus HeartsDo (Talk / Global / Wiki Creator) 18:29, 19 January 2021 (UTC)[reply]
Many thanks Integer talk 18:30, 19 January 2021 (UTC)[reply]
No problem :) HeartsDo (Talk / Global / Wiki Creator) 18:35, 19 January 2021 (UTC)[reply]
It has been taken by User:Dmehus, thank you! Integer talk 18:30, 19 January 2021 (UTC)[reply]

Request for Reviewing Template:Documentation

Could someone please review Template:Documentation? It has a Lua error. I am guessing you may have to import a Lua module. Thank you. User:R4356th/Signature 17:38, 20 January 2021 (UTC)

@R4356th: Yes check.svg Fixed Integer talk 21:25, 20 January 2021 (UTC)[reply]
Please leave importing to admins from the next time. We should attribute the module authors by importing instead of merely copy-pasting. This is due to legal reasons. I hope this helps. To admins, this is X mark.svg Not done. User:R4356th/Signature 21:34, 20 January 2021 (UTC)
Oh, ok. Got it. Will note this for future reference. Integer talk 21:36, 20 January 2021 (UTC)[reply]
For what it's worth, past practice on Meta Wiki with respect to importing versus copying and pasting has been...mixed, to say the least, often without even a required edit summary linking to the source page (via an interwiki page link). Thus, while it's true attribution is required, full history attribution is not required, provided an edit summary link to the source page is included. Best practice here is to say something like Copied from [[w:Example]], where Example is the source page from English Wikipedia. Dmehus (talk) 23:50, 20 January 2021 (UTC)[reply]
R4356th I don't see where there's a Lua error on either Template:Documentation or Template:Documentation/doc. Can you clarify what you mean just a bit? Thanks. Dmehus (talk) 23:52, 20 January 2021 (UTC)[reply]

Category:Wikipedia pages with incorrect protection templates

Today I present to you a problem that has me completely baffled. If you look at Category:Wikipedia pages with incorrect protection templates, you can see that it has only translations of Custom domains. That said, the reason that it says "incorrect protection template" is most likely because the original Custom domains is in fact protected, but that doesn't carry over for translations. Do you think there is a fix to this or will this be permanent? Just to clarify once again, this is regarding Category:Wikipedia pages with incorrect protection templates --Integer talk 03:55, 21 January 2021 (UTC)[reply]