Meta:Administrators' noticeboard

From Meta
Jump to navigation Jump to search
Administrators' noticeboard
Shortcuts:
This noticeboard is for anything that requires administrator intervention on Meta wiki only (anything related to global policies, global groups, or in some way involves Miraheze customer wikis should be discussed at the Community noticeboard!)

On Meta:Administrators' noticeboard (this page), you can:

If you would like to:

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

Archives of Administrators' noticeboard [e]   



Enabled the Purge extension on Meta Wiki

Hi everyone,

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

It seems to only need putting the following code on MediaWiki:common.js or one's own common.js page:
$('#p-cactions ul').append('<li><a href="?action=purge">purge</a><li>');
--开炸弹车 (talk) 14:31, 20 December 2020 (UTC)

Request to delete my Meta user page

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

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

Meta community proposal regarding the use of the Report tool

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

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

Notes:

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

Proposal 1: Move report to patroller user group

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

Support

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

Oppose

  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. Oppose I find that allowing only the patroller user group to submit reports with this extension to be a waste (lack for a better word). There aren't too many patrollers (I think so at least) to simply report questionable revisions. Waldo (talk) 21:40, 19 December 2020 (UTC)
    "There aren't too many patrollers (I think so at least) to simply report questionable revisions." There are not too many active patrollers currently but the number is enough, in my opinion. R4356th (talk) 21:43, 19 December 2020 (UTC)
  3. If this is being used for the purpose of allowing people to report things to sysops in private, surely everyone should have that right? John (talk) 18:04, 20 December 2020 (UTC)
  4. Agreed with above Bray (talk) 03:27, 22 December 2020 (UTC)
  5. Oppose Per Naleksuh and John. Danner (talk) 08:01, 28 December 2020 (UTC)

Neutral/Abstain

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

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

Support

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

Oppose

  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. Pictogram voting comment.svg Comment: As in my opinion I do think perhaps we can limit it to autopatrolled users while experimenting this tool (Reporting tool) just for the time being Cocopuff2018 (talk) 21:50, 19 December 2020 (UTC)

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. Support If staff can help users gage what qualifies as a reportable rev (which is anything that compromises the wiki) then all users should be able to report. Afterall anyone can report by default (extension or not). Waldo (talk) 00:23, 17 December 2020 (UTC)
  2. Support I do not think two reports are enough to decide it is time to restrict this right to users in specific user groups. R4356th (talk) 07:55, 17 December 2020 (UTC)
  3. Support The two uses of it might have been incorrect but we could add guidance and help users. If there was a clear sign over numerous occasions, I might consider it. ~ RhinosF1 - (chat)· acc· c - (WB) 13:58, 17 December 2020 (UTC)
  4. Support per Rhinos Zppix (Meta | Sysadmin | talk to me) 14:03, 17 December 2020 (UTC)
  5. Support per R4356th and RhinosF1. --Sabelöga (talk) 01:31, 18 December 2020 (UTC)
  6. Support per above Bray (talk) 03:55, 19 December 2020 (UTC)
  7. Strong support I have a great feeling that continuing to let all users use this extension to be a worthy move. Danner (talk) 07:16, 19 December 2020 (UTC)
  8. Support 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. Oppose per my articulated comments in the proposal rationale/lede, and per my voting argument in favour of Proposal 2, the Report extension would be used only for reporting (a) blatant vandalism or (b) revisions requiring revision deletion. While it would be wonderful to allow all registered, logged in users to use this tool, the reality is that, without a lack of codified guidelines, the probability for a high number of superfluous and incorrect reports is high, needlessly wasting limited volunteers' time that is both scarce and valuable. Thus, it is better to allow both experienced patrollers and trusted, experienced autopatrolled users to make these limited reports. Users wishing to report such things can reach out to a patroller or Meta administrator privately via e-mail or on Discord and IRC, as we're already doing anyway. Moreover, once we've codified the guidelines further in a few months' time, we can always have a brief community discussion at Meta:Administrators' noticeboard to expand the usage of the tool to the user group. However, at present, since we have no way to revoke one's user group, this proposal is non-viable for my articulated reasons. Dmehus (talk) 07:41, 18 December 2020 (UTC)
    2 reports aren't enough of a pattern. You could also create guidelines. ~ RhinosF1 - (chat)· acc· c - (WB) 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)
  3. Oppose I do not believe that all logged-in users should be able to use the report extension at this time. Not only the fact that we all know it will be misused if it is extended that far but a lot of nonsense reports could come out of it too. Maybe once a general guideline of sorts is established I could perhaps consider it, but not right now. Hypercane (talk) 06:51, 19 December 2020 (UTC)
  4. Oppose Per the comments made about by Dmehus and Hypercane. Since this extension is new and rather experimental (it was approved for that purpose) I feel it's a better idea to limit it to specific groups at the beginning and see if it works out, and consider expanding it with further guidelines. I don't feel like this extension replaces reporting altogether, which can and should still be done via M:AN or by contacting a sysop otherwise (on-wiki or via the other platforms). Otherwise, I feel like rather than allowing everyone to use it, the extension should be disabled until further discussion. Reception123 (talk) (C) 18:32, 19 December 2020 (UTC)
  5. Status quo is misleading, so I can't support it by nature of the definition. Agree on a procedural basis with Naleksuh. John (talk) 18:06, 20 December 2020 (UTC)
  6. Strong oppose Agree with what is said above. It is not at all clear what the "status quo" even is as it was never really clearly said what the Report extension should be used for. I think that moving forward it is not possible to keep the "status quo" and have a very ambiguous and uncertain use of this extension. If this extension is desired, there should be a Request for Comment to define how it will be used, in what circumstances and by which users. DeeM28 (talk) 08:55, 24 December 2020 (UTC)

Neutral/Abstain

Proposal 4: Remove report extension

Support

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

Oppose

  1. Oppose Waldo (talk) 23:45, 17 December 2020 (UTC)
    @Waldo: Why exactly do you oppose? This is a discussion, not a vote. Naleksuh (talk) 00:14, 18 December 2020 (UTC)
    @Waldo: I would concur with @Naleksuh: that, as I articulated in the reminder and explanatory notes following the background information on the proposal, all votes should be accompanied by an argument. The argument can very; arguments can be weaker or stronger. It is incumbent upon the closing bureaucrat to apply appropriate weight to all arguments made, as it's not simply about counting noses. Well, it can be, when the result is very clear. However, in particularly close results, votes without any arguments whatsoever can be discounted or even, where applicable and there is no indication of an implied argument, eliminated from consideration entirely, depending on the bureaucrat's assessment of the prevailing consensus. Dmehus (talk) 00:28, 18 December 2020 (UTC)
    @Naleksuh: It's both. You don't need to tell me what I already know. @Dmehus: I want the extension to stay, which you can sense by my writing cues, such as me voting in favor for a different proposal while opposing this one. Here's your confirmation though since you somehow need it. Frankly not everyone has your length of free time. Waldo (talk) 02:03, 18 December 2020 (UTC)
    @Waldo: Thank you, that's fine now then, yes. It was fair of @Naleksuh: to remind you to include an argument with votes, as we're not mind readers here, and others have observed in other discussions you including only a voting template and your signature. Indeed, @Reception123: was actually planning on reminding you of this point on your user talk page the next time you voted without making an argument. So, with this gentle reminder sidebar discussion, he no longer likely needs to do that. As to your final sentence, there's no need to personalize your arguments by including extraneous, negative, and hurtful comments directed towards me. That's not very nice. :( Dmehus (talk) 02:11, 18 December 2020 (UTC)
    @Dmehus: Well it wasn't extraneous since I don't always have time to use my usual brain power (which is used–among many other things–for making coherent points) and I find being quick and efficient to work fine for me. It was negative and I will agree to that, sorry I was just trying to make it known that some people need to make way for hobbies with the short time they are given and writing short is supposed to help with that (for me at least). I pretty much have to stop soon now so I hope this ties some loose ends. Also you know Zppix has left out arguments too? I thought it was fine because he did it. Waldo (talk) 02:29, 18 December 2020 (UTC)
    @Waldo: It absolutely was extraneous, as your passive aggressive and negative comment was directed towards and at me, not the discussion at hand. That's not okay, and cannot continue. As to your voting without an argument, it is okay as you didn't know at the time, but now you do know, so just keep that in mind for the future, okay? Related to that, if you do not have time to put together a thoughtful argument, then you do not need to rush to participate or vote in a discussion. Not everyone needs to participate in every discussion. It is best if you only participate once you have formulated and composed your argument. Regarding @Zppix: !vote, he actually did have an argument, in that he cited RhinosF1's argument. The only other one who did not have an argument, besides you, actually was @Universal Omega:, and I've just noticed that as well. I'm sure he will add to his vote in the next day or two. Hope that helps. Dmehus (talk) 02:45, 18 December 2020 (UTC)
    @Dmehus: Zppix didn't add text besides his vote when voting for you for Steward. I believe Waldo meant that, not THIS particular vote. He may have done more than that in the past. Danner (talk) 05:54, 18 December 2020 (UTC)
    @Danner: Yes, I suppose that's possible, yes, but at any rate, that's even less relevant as it wasn't in this discussion. Plus, I'm not sure about this apparent preference for citing Zppix as an example, too. Nonetheless, it's a minor point, and I've nonetheless articulated the explanation above to Waldo, so it's probably best not to beat this dead horse any longer. Dmehus (talk) 06:04, 18 December 2020 (UTC)
    @Dmehus: "I thought it was fine because he did it." I assume that means he was explaining why he thought it was fine to vote without the text because a staffer did it too. Not irrelevant because understanding people is pertinent to seeing from a point of view and having empathy. Explanations are key. Danner (talk) 06:12, 18 December 2020 (UTC)
    @Danner: For what it's worth, I didn't say it was an entirely irrelevant example; I said it was less relevant. And, indeed, as I have articulated, I have shown a tremendous amount of good-faith and empathy, as you say, in my explanations to Waldo that votes should be accompanied by arguments. I can see why he thought that it was acceptable, but it is nonetheless important to clarify this for him, as a number of examples of Waldo voting have been cited by Naleksuh, Reception123, myself, and others. As such, it's best to clarify than let incorrect assumptions continue. Thanks. Dmehus (talk) 06:20, 18 December 2020 (UTC)
    I was wondering the same, it kind of feels like targeting Zppix (Meta | Sysadmin | talk to me) 06:43, 18 December 2020 (UTC)
    Keep that to yourself next time, Zppix. You have no substance to go on. Danner (talk) 06:47, 18 December 2020 (UTC)
    Hi, I do infact suggest you read up on all global and local policies before you continue to participate in discussions. Zppix (Meta | Sysadmin | talk to me) 07:03, 18 December 2020 (UTC)
    Weak oppose per my voting argument in favour of Proposal 2, as the leading proposal, and my opposing rationale to Proposal 3, we can certainly consider removing the Report extension in a few months time if it is indeed proving to be rather useless, pointless, and generally unused. However, it's only been enabled for a few days, at best; what this needs is a bit of time—time both to assess its utility and to further codify our guidelines on how it should be used. Separately, as a procedural point of view, I noted that Naleksuh added Proposal 4 after the discussion had begun, which generally should not be done; however, since I did consider adding this Proposal 4 anyway to my community proposal set for discussion, and because only a limited number of voting arguments had been cast, it is acceptable that it was nonetheless added. That being said, it's far too early and we don't have enough hard data to assess its utility for the purposes of potential removal at this point. Now, come, say, March 2021, that would likely be a very different story. Dmehus (talk) 08:31, 18 December 2020 (UTC)
  2. Strongest oppose as the person who requested this to be installed on Miraheze. I believe that this extension can be properly used and it is too early to decide if it is being useful or not. We should ideally have clear guidelines on how to use the extension instead as stated by RhinosF1. If any modifications to things related to this extension must be made then we should at least allow users in autopatrolled and patroller user groups to use it. R4356th (talk) 17:47, 18 December 2020 (UTC)
  3. Oppose I do not believe we should remove it this soon without at least trying the extension first. If it doesn't work out later on, then I could support its removal, but not now. Hypercane (talk) 06:51, 19 December 2020 (UTC)
  4. Strongly oppose per Hypercane. Danner (talk) 07:56, 28 December 2020 (UTC)
  5. Weak oppose I am for giving the extension a chance. Bray (talk) 02:53, 30 December 2020 (UTC)
  6. Oppose Put much thought into this. Settled on opposing removal since I have no problems toward the extension. Frigg (talk) 18:09, 6 January 2021 (UTC)
  7. Oppose It's too early to decide whether to remove it or not, as there have only been 2 reports. Justarandomliberal (talk) 13:49, 7 January 2021 (UTC)
    It has been used 7 times now (last time was 11 day ago). From a quick analysis, 3 reports should not have been reported to Administrators, but rather oversighters in a more private venue, 1 was a test report, 1 was a retaliatory complaint and 2 were legitimate reports. This means the extension so far has a successful rate of approximately 30%. John (talk) 16:29, 7 January 2021 (UTC)

Neutral/Abstain

Request for Updating FAQ

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

Could the What is the initial state of my new wiki? section be updated, too? It currently says, "In addition, your user name will be designated the wiki's first bureaucrat." CreateWiki previously used to put the bureaucrat's name on the main page long ago but that is no longer the case. R4356th (talk) 14:34, 19 December 2020 (UTC)
Could the How does a wiki close? section be updated, too? It says, "A wiki is also closed by stewards after a period of inactivity, as specified by the Dormancy Policy." It is outdated and System administrators are the ones who run a maintenance script to close this wikis currently. R4356th (talk) 15:29, 19 December 2020 (UTC)
Also, could the "How does a wiki close?" section be updated to say that wikis not closed by Sysadmins can be reopened by local bureaucrats, too? I am sorry for the noise but I am working on translating FAQ and these caught my eyes. R4356th (talk) 15:33, 19 December 2020 (UTC)
 Partially done with regards to the closing section. Anyone else can get round to the other two. ~ RhinosF1 - (chat)· acc· c - (WB) 15:33, 19 December 2020 (UTC)
@RhinosF1: Thank you very much. R4356th (talk) 15:36, 19 December 2020 (UTC)
Could the FAQ#How do I confirm that my wiki has been created? section be updated, too? It currently states, "There are some cases where a wiki can't be created, such as... In this case, you will be advised on your user talk page." This is not usually done unless the user makes too many duplicate requests. This should be ideally updated to say that they should follow the comment(s) left on their request in such cases. R4356th (talk) 21:00, 20 December 2020 (UTC)
@R4356th: Since we're all very busy around here, and you're trusted, I've temporarily lowered protection on FAQ to autoconfirmed, allowing you to effect this change and any additional change(s) requested. When you're done, please just leave a reply here and {{ping}} me to reprotect it. Dmehus (talk) 23:04, 20 December 2020 (UTC)
@Dmehus: Thank you very much. R4356th (talk) 09:55, 21 December 2020 (UTC)
@Dmehus: This is now  done. Please note that I made some changes to other sections on that page, too. Also, Sysadmins should consider giving the How many servers do you have, and where are your servers located? section another look since I suspect it may still be outdated. R4356th (talk) 11:48, 21 December 2020 (UTC)
@Dmehus:  Please wait. I spotted something else. R4356th (talk) 12:25, 21 December 2020 (UTC)
I am done updating what I wanted to update. R4356th (talk) 13:03, 21 December 2020 (UTC)
@R4356th:  No problem, and thanks for the updates. Your updates to FAQ all looked useful, and it looks like you also updated the question on how many servers we have and where said servers are located, so that seems to be  done as well, correct? One question I had was in this edit in which you removed an translation unit containing outdated and superceded information. No concerns with the edit, but do you happen to know if the Translate extension will correctly pull a list of all translation units when a page is proposed for deletion (when you select to list all translation units)? In other words, will it list both live + removed translation units? As long as the answer to that is "yes," then I have no concerns. Dmehus (talk) 15:19, 21 December 2020 (UTC)
@Dmehus: Even though I updated the section about servers it may still be outdated (see Discord) as enough information regarding them was not present. As for the translation-related question, the Translate extension does not forget about translation units even if they are removed from the source page. So, this should not cause any issue. R4356th (talk) 16:58, 21 December 2020 (UTC)

Discussion concerning MediaWiki:Mainpage-description

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

@Naleksuh: Do we even need this anymore? I think we have a MirahezeMagic global interface message for this? Dmehus (talk) 20:36, 26 December 2020 (UTC)
@Dmehus: No, it's a lowercase p on most Miraheze wikis, even newly created ones. Naleksuh (talk) 20:38, 26 December 2020 (UTC)
@Naleksuh: Okay, yeah, I see that there is no MirahezeMagic global interface message, though I'm wondering if we should create one? Local wikis can always override it with a local interface message. Alternatively, I guess I'd be fine with this, but would rather see it described as "Home," since the name of the page is Miraheze. Dmehus (talk) 20:40, 26 December 2020 (UTC)
@Dmehus: I believe it is referencing what is the main page here, although it is not necessarily called Main Page. Naleksuh (talk) 21:48, 26 December 2020 (UTC)
@Naleksuh: Okay, fair enough, though I don't think this ideally the best descriptor. For now, this is sort of meh, so will call this  done, without prejudice to a future discussion about how to describe that sidebar link in the future, or making the change globally with a MirahezeMagic interface message. Dmehus (talk) 21:59, 26 December 2020 (UTC)
@John: Why was this page deleted? Naleksuh (talk) 01:07, 27 December 2020 (UTC)
@Naleksuh: I've reached out to @John: to explain the reason for the deletion. I'm okay with the deletion, provided there's a MirahezeMagic global interface message that exists in our GitHub repository; however, I haven't been able to find it. At any rate, I do agree that some explanation should've been provided given that there was a discussion on the matter here. Dmehus (talk) 01:45, 27 December 2020 (UTC)
The following has been moved from MediaWiki talk:Mainpage-description now that the companion page has been deleted. Dmehus (talk) 02:50, 27 December 2020 (UTC)
I deleted it because the requested change reverts the message back to what is provided in MediaWiki core, therefore there is no reason to maintain the override if it is the software default. John (talk) 02:54, 27 December 2020 (UTC)
@John: Ah yes, the purpose of recreating it was due to its talk page showing up as an orphaned talk page, however the discussion is now moved here with talk page deleted so all is good. Naleksuh (talk) 02:56, 27 December 2020 (UTC)
@John: Thanks. I just figured that out afterward—was just about to message you. Thanks for your follow up. Dmehus (talk) 02:56, 27 December 2020 (UTC)

Request for Importing Some Userboxes from Login Wiki

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

@R4356th:  In progress.... Dmehus (talk) 20:43, 8 January 2021 (UTC)
@R4356th:  Done Dmehus (talk) 01:27, 9 January 2021 (UTC)
Thank you very much though I assume you thought I was requesting these userboxes to be imported to Login Wiki which is why you moved this to SN in the first place? R4356th (talk) 09:43, 9 January 2021 (UTC)
@R4356th: No problem, and precisely. That's exactly what I thought initially. When I moved it back to Meta:Administrators' noticeboard, I didn't provide as detailed of an edit summary, as it was essentially a self revert. Dmehus (talk) 16:40, 9 January 2021 (UTC)
Ah,  I see. Thank you. R4356th (talk) 16:46, 9 January 2021 (UTC)

Request for Updating Stewards, Global Sysops and Counter Vandalism Team

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

@R4356th: The change you requested has been  done. With regard to your latter comment, I'm not sure an RfC on this is necessary. Stewards will generally only intervene when there's been a local request from the wiki, or in matters that haven't been dealt with by local administrators in a reasonable period of time (i.e., reverting spam or blatant vandalism). Hard time limits don't really work that well, particularly, in the case of blatant spam page creations, as leaving spam for too long could cause problems for Miraheze subdomains by search engines, so it shouldn't be left too long, really. Feel free to discuss this with me further in a direct message on Discord, though, as that's probably the best venue for clarifying any specific concerns. Dmehus (talk) 06:48, 13 January 2021 (UTC)
@Dmehus: Thank you very much. I was just curious about the Steward part. :) R4356th (talk) 11:17, 13 January 2021 (UTC)
@Dmehus: There is a minor grammatical mistake in Global Sysops: "Once consensus has been achieve" should be "Once consensus has been achieved" instead. Also, you have written "stewards' noticeboard" instead of "Stewards' noticeboard" in both places though it is not that big of an issue. R4356th (talk) 11:36, 13 January 2021 (UTC)
@R4356th:  Typo fixed. I've double-checked both places, and indeed, it does say stewards' noticeboard, not Stewards' noticeboard. Dmehus (talk) 16:13, 13 January 2021 (UTC)
Thank you for fixing it. R4356th (talk) 16:25, 13 January 2021 (UTC)
No problem. Dmehus (talk) 16:25, 13 January 2021 (UTC)