Meta:Administrators' noticeboard

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:
 * 1) Requests for blocking a user and revision deletion shall be moved to the Report extension.
 * 2) An administrator becomes a semi first point of contact for suppression requests.
 * 3) 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,, 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:
 * 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 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)  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)
 * 1)   06:52, 17 December 2020 (UTC) ］ |
 * 2)  as a reasonable second alternative to Proposal 2, where  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)
 * 3)  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

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

Proposal 2: Move 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)  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)
 * 2)  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)
 * 3)  per my articulated proposal rationale,  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)
 * 4)  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)
 * 5)  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)
 * 6)  Since the   and   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

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

Neutral/Abstain

 * 1)  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

 * 1)  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)
 * 2)  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)
 * 3)  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 -  13:58, 17 December 2020 (UTC)
 * 4)  per Rhinos Zppix (Meta &#124; Sysadmin &#124; talk to me) 14:03, 17 December 2020 (UTC)
 * 5)  per R4356th and RhinosF1. --Sabelöga (talk) 01:31, 18 December 2020 (UTC)
 * 6)  per above Bray (talk) 03:55, 19 December 2020 (UTC)
 * 7)  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)
 * 8)  per R4356th and RhinosF1. Frigg (talk) 18:22, 28 December 2020 (UTC)

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)
 * 2)  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 Administrators' noticeboard to expand the usage of the tool to the   group. However, at present, since we have no way to revoke one's   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 -  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)
 * 1)  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)
 * 2)  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)
 * 3) 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)
 * 4)  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)

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&mdash;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)
 * 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 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  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 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)
 * 1) 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  and/or   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)
 * 1) 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)
 * 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 " " 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)
 * 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)
 * 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)
 * 1)  per my comments in reply to  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)
 * per John. Bray (talk) 03:00, 21 December 2020 (UTC)
 * 1)  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

 * 1)  Waldo (talk) 23:45, 17 December 2020 (UTC)
 * Why exactly do you oppose? This is a discussion, not a vote. Naleksuh (talk) 00:14, 18 December 2020 (UTC)
 * I would concur with 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)
 * It's both. You don't need to tell me what I already know. 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)
 * Thank you, that's fine now then, yes. It was fair of 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,  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)
 * 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)
 * 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 !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, 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)
 * 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)
 * 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)
 * "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)
 * 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 &#124; Sysadmin &#124; 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 &#124; Sysadmin &#124; talk to me) 07:03, 18 December 2020 (UTC)
 * 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&mdash;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)
 * 1)  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   and   user groups to use it. R4356th (talk) 17:47, 18 December 2020 (UTC)
 * 2)  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)
 * 3)  per Hypercane. Danner (talk) 07:56, 28 December 2020 (UTC)
 * 4)  I am for giving the extension a chance. Bray (talk) 02:53, 30 December 2020 (UTC)
 * 5)  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)
 * 6)  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)

Request for closure
Request for Uninvolved Stewards:
 * 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. 09:57, 19 January 2021 (UTC)
 * 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)
 * Oops, yeah, I forgot that Meta bureaucrats are supposed to do this. (You mentioning "techincally effected by a Steward" is what confused me.) 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 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. 17:38, 20 January 2021 (UTC)


 * ✅ Integer talk 21:25, 20 January 2021 (UTC)
 * 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 ❌. 21:34, 20 January 2021 (UTC)
 * Oh, ok. Got it. Will note this for future reference. Integer talk 21:36, 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 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, where   is the source page from English Wikipedia. Dmehus (talk) 23:50, 20 January 2021 (UTC)
 * 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)
 * The errors have been fixed by copy-pasting the required modules mentioned in the error by Integer. However, as we do not have any link to WP or MW.org stating that we imported them from those sites in a widely visible place for modules, conventionally, we import them instead of merely copy-pasting. This is what you are requested to do now. 09:23, 21 January 2021 (UTC)
 * R4356th I don't see where Integer fixed these issues by copying and pasting, though, unless you don't mean Template:Documentation and Template:Documentation/doc? I just don't see a revision issued by this user. These templates we did actually import correctly, though; however, we could do well to provide a link in an edit summary to the source templates, so I will do that now. Assuming it was only these two templates, I'm going to mark this as ✅ following my correction. Dmehus (talk) 12:31, 21 January 2021 (UTC)
 * The template needed a Lua module which Integer copy-pasted themselves. This sadly means that this is ❌. 13:16, 21 January 2021 (UTC)
 * I am assuming you forgot about this. 22:01, 21 January 2021 (UTC)
 * R4356th Oh, you didn't link to the Lua module. I thought I checked Module:Documentation and saw it was already imported or properly attributed, but I'll have another look. What other module(s) need to be imported? Dmehus (talk) 22:25, 21 January 2021 (UTC)
 * It needed some other module. I cannot remember the name right now. Perhaps, can. Nevertheless, I will recheck the template.  12:51, 22 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, 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  --Integer  talk 03:55, 21 January 2021 (UTC)


 * Please note that I have moved this here from SN as this only concerns Meta where Stewards generally should not interfere. Thank you. 07:57, 21 January 2021 (UTC)
 * Also, I noticed this while cleaning up Special:WantedCategories. It is likely caused by a template imported from Wikipedia. 08:26, 21 January 2021 (UTC)
 * Integer Thank you for raising this issue. R4356th was correct in moving this thread from stewards' noticeboard to Administrators' noticeboard, where this request is now more in scope. I would quibble just a bit with the phrasing of R4356th's explanation, though, as stewards do have some managerial responsibility for Meta Wiki. It's a governance structure that is somewhat complicated, to put it mildly. For example, Meta bureaucrats oversee most local user group permissions requests requiring a community election (i.e., at Requests for permissions) or which can only be granted by Meta bureaucrats as a discretionary appointment at Administrators' noticeboard (i.e., interface administrator) whereas stewards oversee the global group permissions requests plus one local Meta user group permission request, wiki creator, which was functionally implemented as a local rather global user group for various reasons, but it very much is a global role (i.e., it's just only used on Meta, essentially). Meta bureaucrats generally close most local Meta Wiki discussions, whereas stewards close most global discussions. ManageWiki settings changes are done by stewards. Extensions are enabled by stewards, though in most, but not necessarily all, cases, stewards should consult with a Meta bureaucrat to see whether a community discussion of some sort is needed. In short, it's quite complicated. Alas, I digress. Nevertheless, R4356th is correct that stewards have little concern for which pages or templates are appropriate to Meta, or even such matters as how pages should be titled, generally speaking. Thus, Administrators' noticeboard is the best venue for anything concerning Meta Wiki only. Most requests here can be handled by either a Meta administrator or Meta bureaucrat, whether a community discussion is warranted or not. That's not to say that there may never be a particular request at Administrators' noticeboard that would never be handled by a steward, depending on the specific change required. For example, a minor change to Special:ManageWikiDefaultPermissions might be requested here, though community noticeboard would probably still be a better venue, it's not unreasonable for it to be requested here. In any case, to your specific question, I've gone ahead and just ✅ Template:Pp-template that was causing this issue. While we could have corrected the template to improve the category by which the template categorized pages, since it was only used on one or perhaps two pages, it wasn't really used. And, to be honest, unless we have a bot like AnomieBOT that updates the page protection icons automatically when page protection levels change or expire, these errors will be commonplace. Since one can easily view the protection status in the "page information" feature of a given page, it's not that useful. Hope that helps. Dmehus (talk) 13:21, 21 January 2021 (UTC)
 * Got it, and very much! Integer  talk 13:23, 21 January 2021 (UTC)
 * Integer ✅. Dmehus (talk) 13:28, 21 January 2021 (UTC)

Request for Updating Miraheze
Could someone please update the news section in "Miraheze" to note that Miraheze now hosts more than 4000 wikis? Thank you. 10:52, 21 January 2021 (UTC)


 * R4356th I'm going to mark this as ❌ because (a) we've hosted over 4,500 wikis before and (b) a large swath of closed wikis is due to be added to Special:DeletedWikis in the next few days, which will likely drop us below 4,000 wikis again. Thus, if it's considered significant enough news to note on Main Page, I'd rather wait until it's over 4,100-4,200 wikis. Dmehus (talk) 11:08, 21 January 2021 (UTC)
 * : ( Okay. 11:10, 21 January 2021 (UTC)
 * Yeah, I have to agree as I believe we did once update the News like that and afterwards it was quite awkward when the number went down because of the wikis deleted per the Dormancy Policy Reception123 (talk) ( C ) 20:05, 21 January 2021 (UTC)

Request for Making a Translation-related Configuration Change
Hello, as a Meta Translation Administrator, I would like  (can be found in the Localisation section) to be checked in ManageWiki. It will help translators by showing machine translation suggestions. Thank you. 16:08, 21 January 2021 (UTC)

✅. Dmehus (talk) 21:42, 21 January 2021 (UTC)
 * R4356th I personally would have no objections to this. I'm going to ping Reception123 to this thread to say whether he feels this needs a full Administrators' noticeboard discussion. I personally don't feel it does, as we have no policy on translations. We primarily rely on users' common sense that only those users who know a language should be doing translations in said language. This is a tool that would help users who know a language, but may not be native speakers of said language. Dmehus (talk) 18:12, 21 January 2021 (UTC)
 * Since it doesn't ultimately change the workflow of this wiki and just provides a translation aid I would personally think it's fine to proceed without a formal discussion, especially since I can't really see a reason to oppose this. I don't think it would encourage users doing machine translations, but if that happens they can be told accordingly. Reception123 (talk) ( C ) 20:01, 21 January 2021 (UTC)
 * Yeah, that's a good way of looking at it, I think. Additionally, if the extension proposed to add any new local Meta user groups, or alter existing Meta user groups in a significant way, I would also think we'd want to have a local community discussion on Meta Wiki. As you and R4356th have articulated, this is just adding an additional tool to existing translators' and translation administrators' toolkits to ease their translation work. If it becomes an issue, then we may need to have a larger community discussion towards adopting as translation policy or guidelines for translators to adhere to, but we can have that policy discussion at a later time when it's required. Accordingly, this requested settings change is now
 * Thank you very much. 21:55, 21 January 2021 (UTC)
 * Um... I do not see any change? 22:00, 21 January 2021 (UTC)
 * Hrm, are you still seeing no change? Is there any other setting change needed? Dmehus (talk) 22:27, 21 January 2021 (UTC)
 * I still do not see any change. I will take a look at the Translate extension's documentation and Miraheze's mw-config repositroy. 12:49, 22 January 2021 (UTC)
 * I took a quick look at Yandex's translation service and looks like the languages I have tested with are supported. I will further look into this. 14:16, 22 January 2021 (UTC)
 * On second thoughts, a really simple answer could be that we are not paying Yandex. 14:18, 22 January 2021 (UTC)
 * Never mind. I think I found the problem. I will make a pull request. 14:24, 22 January 2021 (UTC)
 * CSP seems to be causing this. Universal Omega has made a pull request to add Yandex to the CSP whitelist. 15:49, 22 January 2021 (UTC)
 * Per finding on Discord or IRC, this has likely been caused by Miraheze's API key becoming invalid. 16:01, 22 January 2021 (UTC)
 * R4356th Ah, that makes the most sense actually because I was sure I'd used the Yandex translation hints on TestWiki in the past year. Nevertheless, if you can advise when this has been corrected, that'd be awesome. Thanks Dmehus (talk) 23:27, 22 January 2021 (UTC)
 * Miraheze was using a free API key given by a user (they cannot remember where they got it) which got expired in August of 2020. So I am not sure whether it is coming back. 13:33, 23 January 2021 (UTC)

R4356th Ah, okay, thanks for the update. Yeah, we likely don't have the budget to pay for a premium API key. I thought I saw that the Translate extension has configuration variables that can work with either of Google Translate, Yandex Translate, Bing Translate, and possibly even Naver Translate? I wonder if either of those has a free plan, without usage limitations, that we could try. Dmehus (talk) 17:27, 23 January 2021 (UTC)

meatball
Ho ho ho,

links to, but it is 301'ing to. One less 301s are always better, so can we modify this?

Thanks. &mdash; revi  14:30, 26 January 2021 (UTC)
 * ✅,--MrJaroslavik (talk) 14:35, 26 January 2021 (UTC)

Translation administrator
I know I don't have many edits yet, but yes, the number of edits would increase if I had translation administrator rights: I could use them to translate pages and also mark them for translation. On my chat page, I was talking to a Miraheze user when I asked how I could help Miraheze and collaborate with others so if I understood correctly, translation was taken up. Therefore, I would like the rights of a translation administrator. Anton (talk) 20:20, 28 January 2021 (UTC)


 * Anton I'm not opposed to this, but which language(s) do you speak fluently or fairly fluently, and on which wiki(s) have you used the Translate extension? Thanks. Dmehus (talk) 20:23, 28 January 2021 (UTC)


 * I speak Swedish, Spanish and French, moderately English and Finnish well. I have learned Russian, but I do not know about than a couple of sentences.  Yes, and I would use that Translate tool.  In addition to this, I would mark the pages for translation - and I would translate them as well. --Anton (talk) 20:34, 28 January 2021 (UTC)
 * Anton I'm going to put this on hold for a week or two, at minimum, as I would like to see you doing some translations first in languages in which you're most fluent, doing translation reviews of existing translations, and experimenting with the translation administration tools on one of your wikis. How's that? Dmehus (talk) 20:39, 28 January 2021 (UTC)
 * While I am not an administrator, I would suggest you to become an active translator first. 20:39, 28 January 2021 (UTC)
 * Yeah, that's what I was suggesting as well. Basically, you don't need translation administrator tools to translate. If you're active translating, you'll usually be invited to participate in fairly short order. Dmehus (talk) 20:43, 28 January 2021 (UTC)
 * Okay, you can grant me translator rights and later even a translation administrator :) it's good to go to traffic.  I am now really going to participate in Miraheze. Anton (talk) 20:47, 28 January 2021 (UTC)
 * You do not need the Translator rights to translate anything here! You can just visit Special:Translate or click the "Translate" button on any translatable page. I hope this helps. :) 20:50, 28 January 2021 (UTC)
 * Thank you!  This helped.  I got started! Anton (talk) 21:08, 28 January 2021 (UTC)
 * Anton ✅! I'll follow up with you in a couple weeks on your user talk page. Dmehus (talk) 01:23, 29 January 2021 (UTC)

FuzzyBot breaks bulleted lists
FuzzyBot breaks bulleted lists, see Special:Diff/159755 and Miraheze/eo for example. Why does this keep happening and what can we do about it? --Sabelöga (talk) 12:54, 30 January 2021 (UTC)


 * I am to blame for this, apparently. I updated the translation syntax which seems to have caused this. Having said that, we should always keep the syntax up to date from time to time. I will look into switching back to the previous one in a few hours. We should consider making an upstream task on Wikimedia Phabricator regarding this as well. Also a note for Interface Admins: it may be possible to fix the issue with CSS. 13:46, 30 January 2021 (UTC)
 * Do you have a list of broken pages? 16:05, 30 January 2021 (UTC)
 * For what it's worth, I don't think R4356th's translation edits or administration is to blame for this. If I'm understanding correctly, this occurs when a translated source page is marked for translation. The Translate extension, via FuzzyBot, adds  with a Translate extension-specific CSS class that breaks bulleted lists. It's an upstream bug almost certainly, but usually what translators do is they just remove this special div the next time they go to update the translation subpage. Dmehus (talk) 16:18, 30 January 2021 (UTC)
 * What Dmehus said above seems right. Updating the syntax should had used another HTML element. 17:56, 30 January 2021 (UTC)
 * Okay, so how does one manually update the translation syntax?
 * Also, I do think there is a fix to this as it doesn't seem to happen on MediaWiki.org where the syntax keeps the text on the same line which doesn't split the bullet from the text and prevents this from happening in the first place. --Sabelöga (talk) 07:28, 31 January 2021 (UTC)
 * Never mind the above: the text was aligned that way on the source page which caused the translation to get mangled when FuzzyBot added that syntax. This has been fixed on the discussed page. Oh, and can you do the same on the Main Page? --Sabelöga (talk) 07:36, 31 January 2021 (UTC)