Meta:Community portal/Archive 1

Welp, not sure where to put this
So I'm throwin it here. For user rights pages (Bureaucrats, Wiki creator, rtc) we need to choose plural or singular (preferably plural imo) and stick with it. We shouldn't use singular on one page and plural on another. Also, I can see the need for Administrators redirecting since its an abreviation but is there a need to have one tense of wikicreator redirect to the other?
 * I know. I just went on ListUserRights and that's why the pages got created like that.--Reception123 (talk) 01:36, 8 August 2015 (EDT)

Dormancy policy
See Stewards'_noticeboard for a discussion on the dormancy policy proposals. -- Cheers, NDKilla ( Talk • Contribs ) 19:25, 24 December 2015 (UTC)

Proposal of a global "helper" user group
We should have a global "helper" user group for volunteers that aren't sysadmins (such as Me and ImBoPhl), that includes read permissions and whatever else is deemed useful for us. MacFan4000 (talk) 00:09, 13 December 2016 (UTC)
 * Okay I agree I ready MT7 (talk) 01:40, 13 December 2016 (UTC)
 * I'd suggest cranking out a list of permissions that you think this group should need, because right now, it's a lot too vague. To be honest, there is not a lot to stop you from requesting steward if you want to (except, where to put said request). It's worth a thought though. -- Void  Whispers 02:30, 13 December 2016 (UTC)
 * I from WMF maybe I want to help out in here. But I think not.But if you appointed me I can maybe agree. MT7 (talk) 12:23, 13 December 2016 (UTC)

Frustrated with Miraheze
I am totally frustrated with Miraheze. No offense to sysadmins and developers, I think you need to be a little more open. There are hundreds of wikis that have closed, mostly due to inactivity. However, I would be willing to bet that some of those communities have moved elsewhere for a larger setup, etc. My sister and I just wanted a place to host a MW wiki with lots of options as to how it looks and runs. Believe me, I've looked just about everywhere, and pretty much all of MediaWiki's free hosts are either dead, unable to be connected to, or are running an ancient version of MediaWiki and thus significantly lack features. I have a personal GitHub repository that contains what my sister and I would like to see out of a MediaWiki host.

I find myself running into the same roadblock that our cousin, MatthewPW, ran into. My sister never imagined needing these advanced features when she came to Miraheze. However, things changed, and she (as well as I) feel that control is important. I've seen so many wiki farms go dead because they were attacked by spam or other disruptive content, and our goal was to create a wiki that had everything possible to prevent that in our hands. Know that extensions like CU or some of the others aren't things that we would necessarily want to use, but feel that having access to them is important, just in case of something bad or otherwise unforeseen happening.

I understand and respect the need for user privacy, but there just aren't too many reasonable options out there. After some research, this is what it comes down to:


 * ShoutWiki charges you $5.50 just to get rid of page-cluttering ads.
 * Referata has a free plan, but it seriously lacks features and the requests page seems to have been ignored for some time.
 * MyWikis charges you $8/mo to do anything, and $35/mo to have a fully managed site
 * Several other hosts are located on Europe or elsewhere and don't have an English version
 * A large majority of farms have been dead for several years now
 * And the list goes on.

I hope you can see where I'm coming from any why I'm so frustrated. I did also try installing MediaWiki myself. I was doing well, extracting/decompressing data & copying files, until I hit a roadblock.... "Error: No independent database detected". Great! I don't have the foggiest of a clue how to set up an independent database. BTW I tried using Bitnami Cloud Hosting on their free plan, which is "fully managed", but yet that option has absolutely NO EXTENSIONS whatsoever included, with no obvious way to add/request them. Amanda (talk) 15:20, 13 December 2016 (UTC)
 * Paid Hosting is uasally better then free hosting as we have said before. MacFan4000 (talk) 15:29, 13 December 2016 (UTC)
 * Unfortunately it comes down to a lack of same values. Miraheze is a niche in the hosting industry in that it doesn't provide a service to a person but rather a community. Miraheze's core principles are:
 * 100% open-source code and management;
 * no ads;
 * no charges at all, ever;
 * and community centered.
 * The first 3 seem to be down your alley but the last one isn't. We're not a host you make a wiki with and get full access to manage it - we fuel communities and delegate all responsibility to communities. In the beginning, communities are definitely small so we don't demand community view for everything and different communities have their own ways of dealing with running elements which we respect.
 * We do give a lot of control to wikis, but we're community centered so the highly restrictive things are withheld from small communities and only given when the community themselves have developed a strong view they feel it is necessary to have the relevant tools - and when that happens we will work with communities to ensure delegation benefits everyone. The most notable issue surrounding this has got to be CheckUser. We're in no way holding it back. If a community of significant size presents a vote locally saying "we want access to CheckUser", we will work with the community to ensure a satisfactory resolution is met - if that means granting CheckUser locally under stipulated guidelines and policies then it will happen.
 * Stewards recently became a ratified community-handled group - it always was though there was no set in stone policy over how certain events would be handled. If someone presented a successful election as a steward, we will make them a steward. We don't hold back from communities - we do hold back from single people requesting something that doesn't block them in growing their community. Stewards are always open to handle the restrictive work on all wikis where necessary and system administrators are bound by consensus unless legal or otherwise security threats prevent it being carried out. John (talk) 15:59, 13 December 2016 (UTC)
 * Agreeing with John, we have never said 'we won't delegate CheckUser' or anything even remotely similiar, but like John said you are not a community with a thought out process asking for a tool that will benefit the community. You have actually explicitly said that (you|your sister|your cousin) want complete control, and this is something we are unwilling to give you. Complete control doesn't really benefit the communities, especially not for a public wiki about Canada. You have [no] users and [no] community. We want you to grow and thrive with Miraheze but you haven't gotten a community (or attempted to?), you haven't reasonably discussed why you want/need it, etc. etc.
 * "me/my sister" doesn't constitute 'community'
 * "I want to fight spam" isn't a valid reason. You need to explain to us why Stewards doing their jobs (as defined by the community) is not enough for you. We hate spam just as much as any wiki founder, this is why we've been working to resolve issues with Captchas, and why we use such a good captcha.
 * TL;DR since you literally copy/pasted half of your argument from a Phabricator task, I'm starting to think that you, like MatthewPW will never be happy with Miraheze since we are unwilling to give you [a single user] complete control over your wiki. -- Cheers, NDKilla ( Talk • Contribs ) 16:16, 13 December 2016 (UTC)
 * The main issue isn't the community, although that's part of it. The main issue here is that MediaWiki seems to have had so many free hosting services that did provide control of your wiki, but so many of them have gone down. I've seen a few where one or two wikis got attacked by spambots or hackers, and those two wikis were enough to kill the entire host. Also, I truly have nothing against paid hosting, I only am against the fact that the hosts I've researched, as noted in my list above, are so expensive to do anything. For a true example, look at WikiFree. This was a host that provided access to many advanced tools and extensions, but the entire site has gone down due to someone overloading the database server. Now, only an error message in Italian remains of the host. My family altogether has been fascinated with the concept of a wiki for quite some time. We even went to Wikimania one year and loved it. Our perfect paradise would be to have a wiki of which the configuration settings would be completely founder and co-founder controlled, but that the actual setup of a personal database could be eliminated. As noted above, Bitnami Cloud is the closest I've come to achieving that, however Bitnami has absolutely no extensions and therefore is useless. Amanda (talk) 17:19, 13 December 2016 (UTC)
 * BTW it's not my fault that I don't have a community. I do have plenty of users on my wiki, but none of them have ever attempted to contribute in a non-technical way. I also put up a tweet about WikiCanada a few days ago, which went nowhere. Amanda (talk) 17:22, 13 December 2016 (UTC)
 * Unfortunately full control is something you can't get without going fully managed. If you use a service, that service is legally responsible for ensuring the service provided obeys the relevant laws the service has to abide by. For Miraheze, we're bounded by US and Dutch law though Dutch law brings in caveats in that we're then also bound by European Law which is infamous for having extremely tough and awkward privacy laws. Even with community delegation of said rights, it's something we need to constantly monitor and at the first sign of plausible misuse would result in revocation of said rights and Miraheze looking at the impacts of misuse and coming to a reasonable conclusion which may in the end result in a ban for a user (or an entire wiki) from gaining access to said tools again. It's a very very fine line and a very risky one legally which is why we can't give out anything that can be deemed 'private' to people without a proper sense of vetting. If we were to, then the long run would mean we have to vet everyone who has the potential to gain the rights which means every user registering an account in order to protect us legally which is just not feasible. If you go hosted on your own, then you are legally responsible for your own use while with Miraheze, we are legally responsible in addition to you. John (talk) 18:16, 13 December 2016 (UTC)

(Reset indent) Having kept a curious interest in this ongoing topic, both here and on the recently archived Requests for Comment/Stewards page, I can understand why Amanda would want control of the her wiki but at the same time I can easily see the flipped of this argument as John has made some obvious points regarding the issues that come with full control. Having full control certainly brings a whole new bunch of issues. This is fine on a single, paid-for hosting package and you know how to legally and responsibly provide that service. You are in control: the problems, software testing and updates, the legalities, the whole kit and caboodle. I had a wiki for several years where I was in full control so I know what problems can come from this and believe me, having a wiki here is a whole lot better if you want all the perks of having a wiki but without all the technical and legal stuff that goes with it, which, if you don't really know you could be shooting yourself in the foot. I am nowhere near as technically savvy as the administrators and stewards, which is why am pleased they offer a service that takes care of the heavy lifting for you. They provide a service that is in the best interests for the community and this does mean there are some things you cannot do, especially when privacy is involved. I know that if I have a problem with my wiki I can ask someone about it. Yes, it might take a while for a response or to be resolved and I might not always get the answer I want but that's life. I have been knocked back a couple of times with requests but I don't take it personally. However, I can understand the frustrations of relinquishing full control to partial control. Not being able to add extensions and access to Localsettings.php was little strange at first and maybe still is. But the heavy lifting is taken care of for me and I know if there are spam/vandalism issues on my wiki I can ask for help and it will looked into and resolved, it is hoped, in a timely manner. Borderman  talk 22:24, 13 December 2016 (UTC)
 * This is totally getting out of control. I have made my point clear that CheckUser is not the main issue here. I understand that certain MediaWiki extensions will break Miraheze and CentralAuth, and do not challenge that. However, certain extensions I have requested (for example, this one) does not involve user groups altogether, and yet have been declined. It seems like the only extensions that I can have easily are ones that are pre-installed. Even ones that don't mess with any configuration settings (example) have been acknowledged and submitted but never done ( that comment is pointed at you). In other issues, I have now had to kick NDKilla off WikiCanada after they kicked me off TestWiki. The runaway train of Stewards getting in my way never stops. (Especially after I was told that Stewards try to help communities). Amanda (talk) 14:05, 14 December 2016 (UTC)
 * Note that Stewards have read globally which overwrites the local revocation. Also note that stewards have unblock self globally, so you can not fully kick out any steward. MacFan4000 (talk) 14:08, 14 December 2016 (UTC)
 * Perhaps, but I also have an abuse filter to stop edits by the annoying Stewards. Also, Stewards may have the technical ability to, but smart Stewards wouldn't intentionally evade local restrictions. Amanda (talk) 14:11, 14 December 2016 (UTC)
 * Regarding the SiteSettings extension, we have a process of handling things both technically and on a standard practise way. The time it would take to review the extension could be better placed in developing our own home-grown version that exact suits our needs and has a global back-door in to allow trusted people to aid and assist in supporting requests. Our own version also centralises config so we only have to realistically support one standard rather than ensuring n number of settings tables are secure, easily accessible and work with our system. ApprovedRevs is being reviewed, though with only one person reviewing and having a rather large backlog of existing reviews and at the same time maintaining a full time job - we can't commit to review and deploying extensions in the same day, or even same week. Regarding stewards, I note you don't have a filter to prevent edits by annoying stewards but rather all stewards currently. We also do work with communities to help them - we don't hinder them at all. The TestWiki incident to me seems valid as you unblocked users who has been blocked within local policies permanently. John (talk) 16:20, 14 December 2016 (UTC)
 * I'm kind of at the end of my rope here. Amanda has attempted to ban the founders of this wiki farm from her wiki (it won't work obviously), which is a slap in the face to the people who give her stuff for free, but an OK protest I guess?  Except that we've taken all of her requests seriously so far, so I'm not sure what she's protesting other than wanting different free stuff than the free stuff we're willing to give?  And then she's trying to play staff against each other by talking to them and granting privileges to some while revoking others (it won't work obviously).  This behavior seems to be in common between MatthewPW, Amanda, and DeltaQuad -- this big sense of entitlement to free stuff on their terms.  It doesn't even matter at this point whether it's a family or a sock-drawer or false-flag operation.   We are wasting everyone's admin time on this trio for a couple months now and it needs to stop.  I've said several times nicely that I think what she wants can't be compatible with what we are willing to offer, and that it was time to leave, but the hint was not taken.  So here's what I'm doing:
 * I refuse to review ApprovedRevs. It's big, complicated, unnecessary, and requested by a wiki that will never last on Miraheze.
 * I request an IP ban for Amanda. We need to stop wasting time on a problem customer, so that we can solve problems rather than talk about problems.
 * I propose we take wikicanada offline immediately. If Amanda or DeltaQuad wants a copy of the wiki database, she can email us.  Sorry DeltaQuad -- your sister messed things up for you, I guess.
 * That about does it. Hey  if you need a technical request expedited, let me know.  Thanks for your kind words.  Labster (talk) 10:01, 15 December 2016 (UTC)
 * OK, I understand. So basically, SiteSettings doesn't have technical issues, but would just duplicate another extension that is already in development? Amanda (talk) 12:29, 15 December 2016 (UTC)
 * Well yes. And the extension at hand stores all its configuration locally, while we are planning on doing this in a central location. This would mean the migration work would be exponentially more than not bothering over the extension and would in the long run perhaps delay the deployment of our own extension even longer. This is not even considering the effort we'd need to make sure that extension works with out deployment off the bat. John (talk) 16:01, 15 December 2016 (UTC)

(Reset indent) none of that was threatening. If a system administrator thinks you are wasting or time or resources, its a valid concern that operations and/or Stewards should do something about. -- Cheers, NDKilla ( Talk • Contribs ) 14:15, 15 December 2016 (UTC)
 * Saying that you are going to disable my wiki sure is threatening. Amanda (talk) 14:27, 15 December 2016 (UTC)
 * You either misread or misunderstood what User:Labster said. He didn't say 'I am closing that wiki right now and deleting the database damnit,' he proposed that we take the website offline since he believes you are more trouble than you are worth. None of the facts or requests were 'threats' they were just things he won't do (in the case of the first bullet) or requests (in the other bullets). -- Cheers, NDKilla ( Talk • Contribs ) 16:00, 15 December 2016 (UTC)
 * As the co-founder of the wiki, I herby forbid the wiki from being taken offline at least until after the New Year. This gives DQ a chance to completely recover and gives her and I a chance to discuss what we want to do. Amanda (talk) 18:34, 15 December 2016 (UTC)

Stewards vs. wiki founders
In the IRC logs, said: "they don't actually discuss anything they just want their way" - in response to that, now I will discuss.

The only reason that I requested steward is that I have a very high knowledge of the MediaWiki interfaces, and therefore can definitely help out the Miraheze community. I am nearing an expert level of every interface, from basic blocking to complex global account management. However, no one on this request has not allowed me to even demonstrate my abilities - instead they are just voting strong oppose over and over again. I believe the stewards should be able to be appointed just based on experience with the tools that they will have access to - no more, no less.

I also think that storing everything on a central database is causing issues. If Miraheze used one main database, but had smaller branches of said DB, none of these problems would even be an issue. The way I see it is that the reason certain highly-technical tools are restricted is because their use on a personal wiki could/would break their use on a global level. If each wiki was independent of each other, this wouldn't be an issue. --- DeltaQuad  (talk contribs email), 15:22, 5 January 2017 (UTC)
 * Your mediawiki experience do matter, but Steward is a community role. You're asking for a sensitive tool(with the potential ability to look up other's location, etc...), so you have to show others that you're reliable not to abuse your mobs, not to make serious mistakes or problems, not to make a dispute in disrespectful manner. You have to demonstrate not only your ability, but also your reliability seen by others. &mdash; revi  18:49, 5 January 2017 (UTC)
 * I think you're missing the point of the opposes. The main concern of most commenters is that even if your RfS is successful, sharing your account allows others to access tools only you should have access to. Also for the most part wiki databases are separate (local rights, pages, users, revisions and logs are all local) but central auth adds important functionality and links users across wikis. If wikis were completely separate there would be no global groups, and users on on each wiki wouldn't be the same name on another wiki; so impersonation would be possible. -- Cheers, NDKilla ( Talk • Contribs ) 18:53, 5 January 2017 (UTC)
 * As mentioned in the RFS, the stewards themselves told me to share an account. What am I supposed to do - deny my sister from editing? That's not very fair, especially considering the fact that she was the one who kept WikiCanada when it was still around up and running while I was in the hospital. --- DeltaQuad  (talk contribs email), 19:56, 5 January 2017 (UTC)

Main Policy

 * Even though this page is almost never used this is the appropriate place for this. Please check out Main policy/Draft and comment on it and perhaps edit it if needed. Reception123 (talk) ( contribs  ) 10:19, 26 March 2017 (UTC)

Possibility to translate more pages
Hi, I have seen that except for the Main Page, CheckUser, Oversight, Dormancy Policy and Help center there are no more pages that can be translated here, in fact there are a lot of pages and policies that would not hurt to mark for translation. Especially for users who do not speak or do not understand English. Some pages that could be marked are:


 * Wiki creators guide
 * Protected pages
 * Wiki creators
 * Rollbackers
 * Bots
 * Counter Vandalism Team
 * Miraheze Vacancies
 * Request features
 * Code of Conduct
 * Privacy Policy
 * Private wikis
 * Terms of Use
 * Security
 * Stewards
 * Backups
 * IRC

I could handle the translation tags (I have experience in that area) and then ask an administrator to mark the pages, but first I would like to know if the community would agree to this. I appreciate your comments. Thanks. —Alvaro Molina (✉  - ✔ ) 11:26, 22 May 2017 (UTC)
 * It won't hurt if pages are stable or almost stable. --逆襲的天邪鬼 (talk) 11:42, 22 May 2017 (UTC)
 * I've set a few up. Don't have time for others right now. John (talk) 13:30, 22 May 2017 (UTC)
 * I will follow the others. —Alvaro Molina (✉  - ✔ ) 15:48, 22 May 2017 (UTC)
 * Done, the pages that are not crossed out I could not prepare them since they are protected and I can not edit them, reason why you or an administrator will have to do that procedure. —Alvaro Molina (✉  - ✔ ) 16:56, 22 May 2017 (UTC)

Question
En Phabricator, FAQ y Dormancy Policy, no llega a mencionar el caso en el que el Fundador de una wiki pida su eliminación. En el IRC me dijeron que la solicitud es hacerlo en Phabricator pero no veo que en estas lo mencionen. ¿Porque no se mencionan en alguna de estas páginas? o ¿será que lo incluyen en esta frase «If you want to report a bug or anything else please use this form»?. Si es lo segundo, creo que debería especificarse mejor para que sea claro o abrir otra opción --Wiki1776 (talk) 21:08, 7 June 2017 (UTC)
 * If I understand correctly, you are asking why deletion isn't mentioned. If that is the question, that is because it is something specific, and I don't think it is necessary to mention every specific request. I guess, if needed, it could be added to the FAQ, but IMO it would be unnecessary to do so on the other pages mentioned. Reception123 (talk) ('C' ) 18:18, 16 September 2017 (UTC)

Help With Wiki Forum Extension
Hello, I installed the wiki forum extension for my wiki, Snap! Wiki (snapwiki.miraheze.org) but I cannot find out where the forum is. Could you please help me?R4356th (talk) 11:39, 10 June 2020 (UTC)
 * This got resolved a long time ago. So this could be archived. R4356th (talk) 21:05, 29 October 2020 (UTC)

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

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

Header colors
As you all know, Template:Header is used as a header on many pages. For the sake of variety and to clearly distinguish pages, what header color do you all think different page types should use? For example, I was thinking perhaps using green (the default) for documentation pages, purple for anything clerical (request pages, noticeboard, etc.), and yellow for talk pages. Any other suggestions? Agent Isai Talk to me! 08:52, 2 February 2022 (UTC)


 * I'm not picky on the particular tone, but I do strongly recommend it always remains a subtle color to use. Perhaps something can be done with the header line; reducing the colorful of the background, but making the line a subtle distinction. --Raidarr (talk) 13:05, 2 February 2022 (UTC)
 * I think the colors should remain the same regardless anyway. DarkMatterMan4500 (talk) (contribs) 13:17, 2 February 2022 (UTC)
 * I was planning to create a Community portal pretty much today. Do you have the power to read thoughts? Anyway, how like this will it be done? --YellowFrogger ( talk ) ( ✔ ) 18:13, 2 February 2022 (UTC)
 * Leave it the way it is, these colors match up a lot. --YellowFrogger  ( talk ) ( ✔ ) 18:17, 2 February 2022 (UTC)
 * Yes, that's the plan, to use a combination of light, pastel-ish colors. My reasoning for such a standardization is because all RfX and noticeboard pages already use purple and to prevent all pages from looking bland, I wanted to see if anything could be done so that Meta doesn't look so unstyled. Agent Isai  Talk to me! 18:44, 2 February 2022 (UTC)

Inactive bots
and have been inactive on this wiki since 23 December 2020 and 4 February 2021 respectively. Should the rights be removed? --Magogre (talk) 03:35, 6 February 2022 (UTC)
 * After reading the bots information page itself: Bots, I didn't see any part that inactivity of the tools with the bit can cause the revocation. Therefore, we will see the opinion of seconds. --YellowFrogger ( talk ) ( ✔ ) 03:59, 6 February 2022 (UTC)
 * I agree. So far as I know, there is no inactivity policy regarding bots. Magogre, you could propose removing the flag via regular means but I don't see a need to do that unless it is being misused. Naleksuh (talk) 04:02, 6 February 2022 (UTC)
 * I also agree that there is no policy regarding inactivity of bots (and that is why I posted here). The bots have been inactive with zero edits in the last year (Void-bot has zero edits overall). Why do they need the flag, if they are inactive. --Magogre (talk) 04:13, 6 February 2022 (UTC)
 * Regardless of whether or not they need it, usergroups are added and removed in line with policy, that's why they exist! Naleksuh (talk) 04:18, 6 February 2022 (UTC)
 * Well, therere is no policy regarding removal of bots which are inactive, so I don't need to be in line with no policy. The consensus here is what I am looking for to proceed with what to do with them (whether to remove or not)! --Magogre (talk) 04:30, 6 February 2022 (UTC)
 * The bot is correctly identified as such and while it is not active on Meta, it serves a crucial role on . It is advisable just to let it be imo, and instead focus on other applications such as the noted administrator inactivities as something that could reach the policy threshold or other forms of Meta cleanup with a more visible impact, something which I intend to contribute to myself in due course.. Raidarr (talk) 09:54, 6 February 2022 (UTC)
 * Void-bot indeed performs a great task on cvtwiki by logging actions by CVT. But it is completely inactive here (no single edit or log action since December 2020). TranslationHelper did a great job on Meta but gradually fell inactive. Redmin said the bot is no longer need and as such it will be inactive and they are fine with removing the flag. However, void hasn't responded yet.On a separate note, I am drafting an RFC related to user groups on meta that will cover the inactivity clause and other changes to user groups on Meta-Wiki. --Magogre (talk) 11:20, 6 February 2022 (UTC)
 * I'd be interested in contributing to a draft for this to clarify/combine language in certain areas. --Raidarr (talk) 11:56, 6 February 2022 (UTC)
 * Perhaps a discussion and vote can be made here on the Community portal to amend the bots policy to add an inactivity clause. For both bots in question, we can probably ask Void or Redmin if their bots still needs their flag. Agent Isai  Talk to me! 04:33, 6 February 2022 (UTC)
 * Furthermore, the bot flag is requested via RfP, which is usually done via community voting. To remove it then you will have to do the same thing, to see the votes of the community. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger ( talk ) ( ✔ ) 04:36, 6 February 2022 (UTC)
 * It is not necessary to request on RfP, policy doesn't say that anywhere, if I am not wrong. A discussion here would be valid too. --Magogre (talk) 04:42, 6 February 2022 (UTC)
 * So that's why Agent mentioned that you could implement a vote about bot inactivity, which interfered with these two bots mentioned by you. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger ( talk ) ( ✔ ) 04:46, 6 February 2022 (UTC)
 * I'll leave both of them a note about their bots and this discussion. For the ammendment of policy, if anyone has any ideas they may start a discussion here or on RFC. Magogre (talk) 04:46, 6 February 2022 (UTC)
 * Even if there is no written policies about inactive bots in my view it is perfectly reasonable to request that a bot is removed by a bureaucrat if it has not been active in a long time and if the owner of the bot does not respond to messages. DeeM28 (talk) 05:30, 8 February 2022 (UTC)
 * Yes, that's what I was planning. It is clear that TranslationHelper isn't going to be active (confirmed by bot owner, though off-wiki) I don't know how to proceed with the Void-bot after they said they might need the bot for some purposes but not until May this year (though my personal preference is to remove the flag as they have to file the approval request anyway, it might be granted again if its task will be approved). Waiting for some other comments, if any, before requesting bureaucrats on AN to remove the rights. Magogre (talk) 06:00, 8 February 2022 (UTC)
 * Magogre, the Bots policy permits revocation by Meta bureaucrats for discretionary reasons. If the bots are not active on Meta Wiki, this would be reason for removal. The correct venue, however, would be to request revocation at Administrators' noticeboard. In fact, the two bots you mentioned have been on my "to do list" to request removal. I believe Void-bot may have had the  flag on Meta Wiki for functionality it no longer has. Any user rights it needs for updating OAuth consumers and things are included within the   group. As for TranslationHelper, it seems pretty evident it's no longer active here. In short, I concur completely with DeeM28 100% in that if revocation criteria is not specifically codified, removal is subject to the applicable user group's discretion, which, in this case, would be, principally, Meta bureaucrats. Dmehus (talk) 00:00, 13 February 2022 (UTC)
 * I've gone back though Void-bot's code, and I was honestly surprised to see that it hasn't needed to touch metawiki since at least early 2019. There may have been a few things since then, but yeah it does not seem to need the flag. I also don't think I'll be needing it any time soon, so it can probably be remove until I can come up with an actual reason to do something on Meta. -- Void  Whispers 02:04, 13 February 2022 (UTC)
 * Thanks, Void. Yeah, if there's any missing OAuth-related user rights that should be added to the  group, I think we can add them, but I'll link Reception123 to this thread when he's up. Dmehus (talk) 02:07, 13 February 2022 (UTC)
 * Both removed. Reception123 (talk) ( C ) 07:54, 13 February 2022 (UTC)

Is User:Anpang/Socks are stinky essay ready to go into mainspace
Is this in construction essay ready to go into the mainspace? It's still very short but I have seen many short essays in the mainspace before. <span style="display:inline-block;border:2px solid #bfff00;border-radius:8px;background-image:linear-gradient(to bottom right, #75ff75, #ffff80)"> Anpang 📨 04:08, 17 February 2022 (UTC)


 * No, I don't think so, but also, I don't see a problem with it remaining in your userspace. Not all essays, especially those with a somewhat humourous angle, should be in  namespace. Areas to improve include the "how to a spot sockpuppet" section. "Requesting a CheckUser" should not be given as the first step in such cases. Overall, it needs more elucidation. Dmehus (talk) 04:10, 17 February 2022 (UTC)
 * I strongly agree with Doug here that leaving it in the userspace is both entirely acceptable and quite desirable in this case. Actually, one thought I've been musing is a dedicated Essay namespace, allowing subcategorizations including for humor and apparent consensus involved (the highest level on that ultimately just becoming a standard mainspace help page). Per topic though, its content is indeed quite slim.
 * What has been done in the past has largely been absent of an organized approach, so pages in the mainspace that are too short should be considered as well. This was an intention of the meta project that I've unfortunately fallen behind on pushing or acting for. --Raidarr (talk) Raidarr (talk) 12:21, 17 February 2022 (UTC)

2FA to be required for certain local Meta Interface rights
Meta Interface administrators,

Following concerns raised by a fellow Interface administrator, it will now be required that 2-factor authentication be enabled on your account to edit sitewide JavaScript and other user's personal JavaScript. This requirement will be enforced via our configuration and if you do not have 2FA enabled, you will lose access to editing JavaScript pages and other user's personal JavaScript but you will not lose the ability to edit sitewide CSS interface pages. This change will go into effect shortly. Thank you for your understanding. Agent Isai Talk to me! 19:53, 14 April 2022 (UTC)
 * This change requires consensus. I would most certainly be opposed to such a change. Also, JavaScript and CSS are treated the same. Naleksuh (talk) 16:55, 16 April 2022 (UTC)
 * It also appears this change was authored by a user who multiple people have advocated for removal of their SRE permissions in the past. Why are they now making extreme changes to the config without consensus? Naleksuh (talk) 17:00, 16 April 2022 (UTC)
 * Though I would've preferred that a community discussion taking place prior to implementation, it certainly doesn't need a Meta RfC. I suggested a short discussion at the talk page rather than here, so I'm not sure why Agent Isai posted it here. In any case, RhinosF1 has already implemented it in his SRE capacity. It applies only to Meta Wiki, and is a prudent best practice. Given that all existing Meta interface administrators are either (a) already required to have 2FA enabled as a result of certain global groups or (b) support the change (i.e., chrs, I think this is fine, so +1 from me as well. Dmehus (talk) 17:01, 16 April 2022 (UTC)
 * This doesn't appear to be implemented as I can still edit at https://meta.miraheze.org/w/index.php?title=MediaWiki:Common.js&action=edit - either the production deploy has not taken place yet or the unauthorized changes were reverted. Either way since I do not carry a smartphone this "security change" essentially disables interface admins, especially when this was just a random change with no related incident leading to it. Naleksuh (talk) 17:11, 16 April 2022 (UTC)
 * Naleksuh, firstly, as a security best practice, you should not be making sensitive changes to sitewide CSS and JS while mobile. Secondly, without a request from a Steward or a Meta bureaucrat, and typically following some sort of request Stewards' noticeboard or Administrators' noticeboard, as your role is a sub-delegated role of a Meta bureaucrat. As to your first point, looking at the  history, it was not reverted, so it seems to have had no effect. Dmehus (talk) 17:17, 16 April 2022 (UTC)
 * you should not be making sensitive changes to sitewide CSS and JS while mobile Then you would support it being reverted, since this change means you must have a mobile phone with you in order to edit the CSS/JS. Naleksuh (talk) 17:19, 16 April 2022 (UTC)
 * I didn't say that, and where does it mean you must have a smartphone to edit CSS/JS? Dmehus (talk) 17:22, 16 April 2022 (UTC)
 * I do not see your edit, so it seems that it has been implemented. Dmehus (talk) 17:21, 16 April 2022 (UTC)
 * I didn't actually save anything beforehand, just looked at if I could view the edit screen. It does appear I can save though. However, that's not the important part. The important part is that this change was arbitrarily made and, while having no meaningful security benefit, does hinder interface admins ability to do their job (since I do not carry a mobile phone, this would mean me resigning as an interface admin). It was also made without consensus for it randomly by one particular person. Based on all of the above, this random, unauthorized, all-negative change should be reverted. Naleksuh (talk) 17:25, 16 April 2022 (UTC)

Draft proposal for Meta codification
As I have already set out in a previous Community Noticeboard post that was positively welcomed by Raidarr I have now created an initial draft proposal to codify some existing rules and conventions into policy here on Meta. I have explained there why I believe this is necessary to be done. I would like to invite all users that form part of the Meta community to add proposals that they think should be codified to achieve more clarity and to otherwise develop or improve the proposals I have already set out. If there are no additional proposals I intend to move the draft into RFC space in a few days but I hope that others will contribute to this draft. DeeM28 (talk) 17:31, 4 May 2022 (UTC)


 * This is sufficiently broad, open, yet also fundamental on meta that perhaps it would merit a sitenotice to collect input. Certainly when the proposal starts, but perhaps even in this stage. I'll probably have feedback on the wording soon in the meantime, either here or on the talk for the draft. --Raidarr (talk) 18:39, 4 May 2022 (UTC)
 * I've made a few changes to the wording but perhaps it can be improved even more. If there's not much activity a sitenotice during the drafting stage might be a good idea. Reception123 (talk) ( C ) 10:02, 5 May 2022 (UTC)
 * Added a short sitenotice for the draft itself. Reception123 (talk) ( C ) 06:54, 8 May 2022 (UTC)
 * This is a pretty good idea in terms of concepts (I do hope makes an appearance today at some point, but it's like 3:36AM as of this writing in his area right now). DarkMatterMan4500 (talk) (contribs) 10:36, 8 May 2022 (UTC)
 * I don't really understand the idea behind continuing to edit the draft and even in doing so changing what the RfC is. Obviously I will be opposing 1 and 4, but what good would editing the RfC do? So people can edit them or remove them? Naleksuh (talk) 18:00, 8 May 2022 (UTC)
 * While reviewing the Community portal archives, I stumbled upon this thread made by Recepetion123 in which he proposes the codification of a "main policy" of which the draft is located at Main policy/Draft. The draft mentions 2 things that may seem trivial to us but perhaps would be useful in codifying such as what is on topic for Miraheze Meta. By convention, we delete pages that don't directly relate to Miraheze or Meta (i.e. pages for wikis, etc.) but this isn't codified (as far as I can see) so would codifying that perhaps be useful too? Agent Isai  Talk to me! 01:23, 9 May 2022 (UTC)
 * As far as this conversation of "codification" has been going on for some time, I'm not all that convinced that Meta conventions are consistent enough to reliably document and codify any standards at this time. Meta has realistically failed to develop any sort of "community" and has become stuck as a procedural hub. I think it is for this reason that Meta does not see the engagement necessary for observable trends, standards, and expectations to take hold in any form of a code. As anxiety inducing as it can be, the current "flow state" of community (dis)approval toward administrative actions is probably the best possible space for Meta to exist right now. dross  (t • c • g) 07:19, 9 May 2022 (UTC)
 * I also meant to note in this that Meta has proven itself to be very fluid. Users not only come and go, but every group of users to inhabit Meta so far have proven to possess entirely different cultures. Meta has always changed with these users. Codifying standards in the current state where turbulence is the norm would create additional unnecessary bureaucracy to the processes which exist here. dross  (t • c • g) 07:31, 9 May 2022 (UTC)
 * I agree with Dross that unfortunately Meta has not developed a 'community' per se, and that's a shame. At the same time though, while I don't think we need to codify everything some particularly controversial things need have clear community endorsement in order to stop repeated arguments taking place about whether they're convention or not. If there's no interest to codify any other things, I would personally think it would be good to proceed with the RfC as it currently is to at least codify these principles which have proven to be controversial and in dispute. Reception123 (talk) ( C ) 10:51, 9 May 2022 (UTC)
 * Thank you to all for the comments, suggestions and modification you have made to the initial draft. Because there have been no additional comments or suggestions recently I have decided that it is a good time to begin the voting period and have created Requests for Comment/Endorsement of Meta conventions accordingly. DeeM28 (talk) 16:35, 15 May 2022 (UTC)