Meta:Administrators' noticeboard

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


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

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

Thanks,

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

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


 * I will try and have all the user group lists updated later this evening. Thanks. Dmehus (talk) 03:30, 5 December 2020 (UTC)
 * This has been ✅ by . If you ever see minor inconsistencies between the user list subpages, please don't hesitate to make the update(s) yourself, taking care to leave a clear edit summary and, optionally, linking to a relevant permalink/diff in said edit summary. Thanks again for your reporting this, and for your community contributions. Dmehus (talk) 17:37, 5 December 2020 (UTC)
 * This is unfortunately, ❌. List of Stewards has not been updated yet. R4356th (talk) 20:23, 6 December 2020 (UTC)
 * And I cannot edit that page since it is protected. :( R4356th (talk) 20:33, 6 December 2020 (UTC)
 * Thank you. I didn't even know that List of Stewards existed, actually. It looks like it existed prior to Stewards/List being created, so I've simply ✅ in the revisions prior to today, since the wikitable was broadly similar to that at Stewards/List, and now is appropriately credited as page creator of Stewards/List. So, now ✅. Dmehus (talk) 21:20, 6 December 2020 (UTC)
 * Thank you very much. R4356th (talk) 21:36, 6 December 2020 (UTC)
 * ✅. Dmehus (talk) 21:37, 6 December 2020 (UTC)

I have destroyed User:Lily/global.js
I did not realize that I was in metawiki when I moved my global.js and edited the redirect link, now I cannot edit the page because it redirects to a page outside user namespace. Pls delete the page, so I can restore my old global.js, thank you very much Lily (Lilypond Wiki · talk to me · little garden · my wiki of everything) 14:19, 5 December 2020 (UTC)
 * I've moved it back to the original page. Reception123 (talk) ( C ) 14:59, 5 December 2020 (UTC)
 * Thank you very much! Greetings LilyLilyu - smile.svg (Lilypond Wiki · talk to me · little garden · my wiki of everything) 15:18, 5 December 2020 (UTC)
 * Note that I have procedurally moved this request from stewards' noticeboard to Administrators' noticeboard. Basically, Administrators' noticeboard is the venue for any requests about users or pages on Meta that requires administrator intervention]], local, small-ish community proposals, and local discretionary appointment permissions requests granted by either a local administrator or bureaucrat. Community noticeboard is technical support questions regarding your wiki, small-ish global community proposals, questions about Miraheze or MediaWiki generally, and requests to add interwiki prefixes to your wiki. Stewards' noticeboard is basically for anything requiring steward attention that isn't handled elsewhere on other related noticeboards (i.e., requests for adoption). Hope that helps. Glad the issue was ✅, too. Dmehus (talk) 16:50, 5 December 2020 (UTC)

Unassigned user right
I noticed that the steward user group is able to view the number of page watchers of a given page on Meta Wiki, something the local Meta administrators cannot do, presumably because the user right  is unassigned locally. It's included within the  and   global groups, but not any local user groups. On TestWiki, we have it assigned to the  user group and, indeed, on English Wikipedia, they, too, have assigned it to the   user group, though interestingly, the number of page watchers is still visible to non-administrators on that wiki, so that suggests, perhaps, there's some sort of additional configuration change we'd need to make? Nevertheless, as I can see a use case for Meta administrators, or even all users, potentially, being able to see the number of page watchers of a given page, I'd like to add the  user right to either (a)   or, perhaps, (b)   and   maybe? As Meta Wiki is rather unique in its management structure in that it is a steward-managed wiki with local Meta bureaucrats managing the closing of local permissions requests, RfCs, and Meta community discussions at AN, I thought I'd post this idea here to see if anyone had any objections to me making this change? Though local bureaucrat approval is not likely required, since it does affect the the user rights of Meta administrators, feedback from any Meta bureaucrats is of particular interest to me. Thanks. Dmehus (talk) 13:59, 10 December 2020 (UTC)
 * I have no objections to this and think it was likely an oversight. Sysops on EnWiki also have the right, and I don't see why sysops here on Meta shouldn't. Reception123 (talk) ( C ) 14:06, 10 December 2020 (UTC)
 * With the endorsement of local Meta Wiki bureaucrat and no objections from anyone in more than two days, this is now ✅. Meta administrators can now view , something that was most likely an inadvertent oversight. Dmehus (talk) 22:41, 12 December 2020 (UTC)

Request for Enabling Extensions Report and EditCount
The Report extension will allow registered users to report revisions privately to sysops (default, can be changed). And sysops will be able to review the reports from Special:HandleReports. I think this will be helpful for fighting vandalism and sharing private information with admins. said that he would propose it for enabling here on the Phabricator task for installing this on Miraheze and on Discord. EditCount will implement a special page for showing users' local edit count allowing users to transclude their edit count in their signatures. This extension is not very important but would be good, in my opinion. R4356th (talk) 17:08, 11 December 2020 (UTC)
 * I would have no objection to these extensions be enabled on Meta Wiki as they're both either useful or small, but will wait to see if either of have any thoughts, so will give it a few days before enabling. My only concern with the Report extension is whether or not that extension will create a new   user group and overwrite the existing   group. If not, that is to say, if the extension first checks if an existing group exists prior to overwriting and creating, then I have no concerns. Dmehus (talk) 17:20, 11 December 2020 (UTC)
 * It adds a new user right called  which is assigned to Sysops by default (but as I mentioned earlier, it can be changed). R4356th (talk) 17:27, 11 December 2020 (UTC)
 * Ah, my mistake...I was thinking of Patroller, which I haven't requested be installed on Miraheze yet&mdash;still debating whether to request it, but may file a Phabricator task in a few weeks. I'll wait until at least adds a comment, giving his blessing to Meta administrators having no opposition to having that added user right. Dmehus (talk) 17:35, 11 December 2020 (UTC)
 * I think EditCount should be fine to enable and may be useful. As for Report, I'm not sure how useful it would be to us really, but I don't object to us giving it a try and if it doesn't work out disabling it afterwards. Reception123 (talk) ( C ) 07:35, 12 December 2020 (UTC)
 * Considering Report might turn out to be problematic if there are spam reports or new users mistakenly using it, do you think community consensus is necessary here? R4356th (talk) 07:49, 12 December 2020 (UTC)
 * It's a potentially valid question, but considering that Meta administrators are the only ones that would be viewing the special page, I would say no, actually. And actually, that would be a stronger argument against requiring a formal community proposal to enable the extension, as we want to be able to disable the extension quickly if it were misused. I see no problem trying it out, as the use case for this would be for Meta patrollers to report problematic revisions requiring revision deletion (i.e., editor who logged out or grossly defamatory or insulting comments, etc.), since revision deletion requests can't simply be tagged with delete like page deletion requests. Since administrators are the only users that can see the reports, this is an ideal way to report such requests. Plus, creating a new thread at Administrators' noticeboard for every grossly defamatory or insulting revision requiring deletion is a bit much, in my opinion (though reporting revisions of users who likely edited while logged out would normally be reported privately; however, since administrators are the only ones that can see the page, this is a reasonable reporting avenue). Dmehus (talk) 13:44, 12 December 2020 (UTC)
 * I agree that I don't think there's much harm in at least trying it out and seeing if it works for us, it could be an interesting tool for us. If it doesn't, it can be quickly removed as Dmehus says. Reception123 (talk) ( C ) 15:58, 12 December 2020 (UTC)
 * okay, great. R4356th (talk) 16:35, 12 December 2020 (UTC)
 * With that, this is now ✅. Dmehus (talk) 22:50, 12 December 2020 (UTC)
 * Thank you so much! R4356th (talk) 09:57, 13 December 2020 (UTC)

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

Enabled the Purge extension on Meta Wiki
Hi everyone,

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

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

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,, 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)
 * 3) *"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)

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)

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)

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)

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

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

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


 * Could the What is the initial state of my new wiki? section be updated, too? It currently says, "In addition, your user name will be designated the wiki's first bureaucrat." CreateWiki previously used to put the bureaucrat's name on the main page long ago but that is no longer the case. R4356th (talk) 14:34, 19 December 2020 (UTC)
 * Could the How does a wiki close? section be updated, too? It says, "A wiki is also closed by stewards after a period of inactivity, as specified by the Dormancy Policy." It is outdated and System administrators are the ones who run a maintenance script to close this wikis currently. R4356th (talk) 15:29, 19 December 2020 (UTC)
 * Also, could the "How does a wiki close?" section be updated to say that wikis not closed by Sysadmins can be reopened by local bureaucrats, too? I am sorry for the noise but I am working on translating FAQ and these caught my eyes. R4356th (talk) 15:33, 19 December 2020 (UTC)
 * ✅ with regards to the closing section. Anyone else can get round to the other two. ~ RhinosF1 - (chat)· acc· c -  15:33, 19 December 2020 (UTC)
 * Thank you very much. R4356th (talk) 15:36, 19 December 2020 (UTC)