Meta:Community portal/Archive 1

Welp, not sure where to put this[edit source]

So I'm throwin it here. For user rights pages (Meta: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 Meta:Administrators redirecting since its an abreviation but is there a need to have one tense of wikicreator redirect to the other? — Preceding unsigned comment added by NDKilla (talk • contribs)

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[edit source]

See Stewards'_noticeboard#Dormancy_Policy 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[edit source]

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[edit source]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Not done. This discussion is closed per my latest comment. 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:55, 15 December 2016 (UTC)

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 | contribs | email} 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 (@Labster: 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 @Borderman: if you need a technical request expedited, let me know. Thanks for your kind words. Labster (talk) 10:01, 15 December 2016 (UTC)

@John: 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) @DeltaQuad: 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)

@DeltaQuad: 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Stewards vs. wiki founders[edit source]

In the IRC logs, @NDKilla: 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. — revi 18:49, 5 January 2017 (UTC)

@DeltaQuad: 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)

@NDKilla: 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[edit source]

Even though this page is almost never used this is the appropriate place for this. Please check out Meta: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[edit source]

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:

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)

@John: 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[edit source]

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[edit source]

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[edit source]

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

{{Autoarchive/config
|archive = Meta:Community portal/Archive %(counter)d
|algo = old(30d)
|counter = 1
|maxarchivesize = 100K
|archiveheader = {{Archive}} __NOINDEX__
}}

For your consideration. User:BlackWidowMovie0000Editor/signature 20:27, 29 October 2020 (UTC)

Header colors[edit source]

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, @Agent Isai: 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[edit source]

Void-bot (talk • contribs • logs) and TranslationHelper (talk • contribs • logs) 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: Meta: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 cvtwiki. 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. --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. --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 Meta:AN to remove the rights. Magogre (talk) 06:00, 8 February 2022 (UTC)

Magogre, the Meta: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 Meta: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 bot 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 confirmed 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 confirmed 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[edit source]

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. 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 (Main) 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[edit source]

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 Meta:Administrators' noticeboard, as your role is a sub-delegated role of a Meta bureaucrat. As to your first point, looking at the LocalSettings.php 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 ([[1]]), 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[edit source]

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 Dmehus 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 Meta: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)

Inability to use Meta on STB[edit source]

The page is blank when I go to meta.miraheze.org on my STB. Cigaryno66331 (talk) 08:05, 14 June 2022 (UTC)

Maybe this is only me as I am not completely up-to date with all new technologies but what is an STB? --DeeM28 (talk) 07:00, 15 June 2022 (UTC)

Change ConfirmEdit[edit source]

WARNING!: The MediaWiki developers suspected that ReCaptcha was cracked by most spambots. I think Miraheze must use SimpleCaptcha (math operation) or FancyCaptcha (words in an image). Cigaryno66331 (talk) 09:16, 14 June 2022 (UTC)

Thanks for the information. We are already aware of several problem with reCAPTCHA, both technical and ethical, and there was an ongoing RfC to change it that was improperly closed, which is currently being proposed for reopening. You can discuss that here: Stewards'_noticeboard#Requests_for_Comment/Replace_reCAPTCHA_with_another_CAPTCHA_2. Naleksuh (talk) 09:23, 14 June 2022 (UTC)

As a note, ReCaptcha 2.0 has been cracked by spambots. We use 3.0 so we aren't affected by the crack. Reception123 (talk) (C) 10:40, 14 June 2022 (UTC)

We should use SimpleCaptcha, FancyCaptcha, MathCaptcha, or QuestyCaptcha Cigaryno (talk) 13:00, 18 June 2022 (UTC)

Enable the 2017 wikitext editor on Meta[edit source]

Should we enable the 2017 wikitext editor as a beta feature or use it as the default editor in Meta? Cigaryno (talk) 11:15, 20 June 2022 (UTC)

I don't see a need to change the editor from how it works now, which allows for both visual and source. --Raidarr (talk) 13:11, 21 June 2022 (UTC)

Its VisualEditor, but inside there is source editing. See mw:Special:MyLanguage/2017 wikitext editor for more information. Cigaryno (talk) 13:22, 21 June 2022 (UTC)

The 2017 wikitext editor could be enabled in Special:Preferences#mw-prefsection-editing. Cigaryno (talk) 15:43, 27 June 2022 (UTC)

Question about bots[edit source]

I will create a bot and I need to find a page to request bots to be approved. Cigaryno (talk) 10:33, 21 June 2022 (UTC)

Cigaryno, bots approvals are requested at Meta:Requests for permissions. Thanks. Startus (talk) 12:51, 21 June 2022 (UTC)

I created a bot password but the account still does not exist. Cigaryno (talk) 13:08, 21 June 2022 (UTC)

A bot password is the password you use to sign into an account as an automated script, it's not a separate account. In order to create a separate bot account, you should use Special:CreateAccount while logged in. — Chrs (talk) 22:01, 21 June 2022 (UTC)

Move Tech:MediaWiki appserver to Tech:MediaWiki[edit source]

I want to move Tech:MediaWiki appserver to Tech:MediaWiki? Muhammad Alfarezal (talk) 07:37, 29 July 2022 (UTC)

I'm not delete Tech namespace Muhammad Alfarezal (talk) 08:01, 29 July 2022 (UTC)

@Muhammad Alfarezal: why do you want to change it at all? If you do not have a clear reason, it's best to leave it alone. Preferably either a) you have a clear organizational reason, ie, category work, or b) you're in SRE (the group that benefits from anything in that namespace) and have practical reason to modify the setup. --Raidarr (talk) 12:16, 29 July 2022 (UTC)

I'm moving page from Tech:MediaWiki appserver to Tech:MediaWiki. Muhammad Alfarezal (talk) 00:36, 30 July 2022 (UTC)

Again, why? --Raidarr (talk) 01:06, 30 July 2022 (UTC)

Declined – not enough deletion. Muhammad Alfarezal (talk) 05:17, 30 July 2022 (UTC)

Please explain what you are posting. --Raidarr (talk) 12:20, 30 July 2022 (UTC)

Unable to review wiki requests[edit source]

I don't know if you guys know this, but I ran into an internal error when trying to approve or decline wiki requests. Is anybody else having this issue? DarkMatterMan4500 (talk) (contribs) 15:50, 10 August 2022 (UTC)

GoW TOC[edit source]

Hello. I come here to seek consensus on the Table of Contents of this page if it is better on the left or right side. I prefer the right side as it doesn't pollute the list and you don't need to scroll down to look at the list. — Pixial ^[Talk] 16:23, 10 August 2022 (UTC)

The right side certainly is out of the way... so out of the way that I didn't even notice it at first, lol. Chantolove (talk) 23:07, 9 October 2022 (UTC)

Issue on Community noticeboard[edit source]

Is anyone getting an error where it says "Comments on this page can't be replied to because of an error in the wikitext" on the community noticeboard? This popped up when DeeM's proposals appeared and now affects the entire page for no discernible reason. --Blad (talk • contribs • global) 18:49, 6 November 2022 (UTC)

Hi @Blad: Can you try it again? I tried some magic.--MrJaroslavik (talk) 19:17, 6 November 2022 (UTC)

This worked, thank you! --Blad (talk • contribs • global) 19:22, 6 November 2022 (UTC)

`Autopatrolled` protection level?[edit source]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

There are no real objections to adding this protection level. As mentioned in the discussion, the protection level shouldn't be used on noticeboards/discussion pages. Reception123 (talk) (C) 08:51, 6 January 2023 (UTC)

Following a thread on my talk page requesting some pages be unprotected from sysop-level protection, I began to wonder about what everyone thinks about potentially adding an autopatrolled protection level to Meta. Autopatrolled users are users who Meta admins know are trustworthy and understand the scope of Meta and they are the ones who generally do the bulk of editing on Meta pages. It could be useful in the future to restrict editing to autopatrolled users in certain cases rather than a blunt protection to sysop-level. Perhaps we can also evaluate if some pages can be further lowered in protection, from sysop to autopatrolled so as to allow editing from that set of trusted users while also ensuring that these high visibility pages aren't disrupted. This would be a step up from autoconfirmed which an LTA can easily gain (autopromotion takes into consideration your global account age so if a vandal has a sleeper account and makes 10 edits on Meta quickly, now they're autoconfirmed) and would allow for trusted users (who make 99%+ of edits anyhow) to edit pages which don't really need sysop-level protection but are protected as such to prevent vandalism. Agent Isai ^{Talk to me!} 00:32, 14 December 2022 (UTC)

I think I would

Support this. There seems to be a reasonable need for the protection level, and it makes sense as most trusted users have the autopatrolled permission. Thanks - BrandonWM (talk • contributions • global • rights) 03:48, 14 December 2022 (UTC)

Normally I would oppose this kind of thing instantly, as while sysop protection can be used to protect against edit warring and other conflicts involving autoconfirmed editors, a protection level that only allows editing by users in a group given and removed at will by admins is in my opinion, just creating an in-group of editors (or at least legitimizing their existence). However, given the nature of metawiki, I will think about it instead of instantly opposing. However, right now I do not support such a thing. OrangeStar (talk) 17:10, 14 December 2022 (UTC)

I think I would support it if usage of this protection level was strictly limited to content pages, meaning no using this level on talkpages, RfC, Request for permissions, RfGR, RfS and other such pages. OrangeStar (talk) 17:18, 14 December 2022 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Redirects to Tech namespace[edit source]

Abuse filter produced a false positive when I am trying to create a redirect Db141 to Tech:Db141.

Can we create redirects:

Db101 redirecting to Tech:Db101
Db112 redirecting to Tech:Db112
Db121 redirecting to Tech:Db121
Db131 redirecting to Tech:Db131
Db141 redirecting to Tech:Db141

Can admins also soften the Abuse Filter no. 25, which prevents users from creating pages in main namespace, to autoconfirmed?

Any comments would be appreciated. Silicona (talk) 15:10, 19 December 2022 (UTC)

Heres a few more:

Cp22 redirects to Tech:Cp22
Cp23 redirects to Tech:Cp23
Cp32 redirects to Tech:Cp32
Cp33 redirects to Tech:Cp33
Ns1 redirects to Tech:Ns1
Ns2 redirects to Tech:Ns2 Silicona (talk) 15:18, 19 December 2022 (UTC)

As a general rule of thumb, we don't allow cross namespace redirects apart from some shortcuts like shortcuts to RfXs and such. Agent Isai ^{Talk to me!} 18:49, 19 December 2022 (UTC)

Modifying the wordmark[edit source]

Just an idea that came to me but some users have difficulty understanding that Meta isn't their wiki or they think the entire farm is called 'Meta'. A few have even thought that we're related to Facebook (whose parent company is now called 'Meta'). As such, I wanted to hear what users think about potentially modifying the wordmark from 'Meta' to 'Miraheze Meta'. Agent Isai ^{Talk to me!} 17:11, 31 January 2023 (UTC)

The wordmark of what? SITENAME is already called Miraheze Meta. Where else should it be changed? Naleksuh (talk) 17:13, 31 January 2023 (UTC)

Don't you know what a wordmark is?

Also, it's a good idea. Collei (talk) 17:15, 31 January 2023 (UTC)

The wordmark is the name of the wiki which appears next to the Miraheze logo on skins like Vector 2022. Agent Isai ^{Talk to me!} 17:16, 31 January 2023 (UTC)

Oh right, the absurd skin that shows the logo in a weird way. Sure, change it to Miraheze Meta there, on vector-2022 (not "skins like" vector-2022 since that's the only skin that does that). Naleksuh (talk) 17:18, 31 January 2023 (UTC)

I was unaware of that, thanks for the info. Agent Isai ^{Talk to me!} 17:20, 31 January 2023 (UTC)

Don't worry about it, you are better off being unaware of the nightmare that is vector-2022 Naleksuh (talk) 17:21, 31 January 2023 (UTC)

I would find Vector 2022 a lot easier to use if it wasn't for all the unused space. Collei (talk) 19:17, 31 January 2023 (UTC)

Support --NotAracham (talk • contribs • global) 22:02, 31 January 2023 (UTC)

I don't have a major problem with vector-2022, to be honest. There are some things I definitely find weird (purple for pages I've visited as opposed to dark blue), and the interface throws me a little bit. I use vector-2010 for the vast majority of my editing. But it's not that bad. Regardless,

Support. Thanks - BrandonWM (talk • contributions • global • rights) 00:29, 1 February 2023 (UTC)

Support I explained my reasoning for supporting earlier. Collei (talk) 18:46, 1 February 2023 (UTC)

I think its a good idea to ensure brand consistency across all skins and the like, so it does seem a good idea. However, I don't think changing the Vector wordmark is really necessary; the Miraheze logo to the left of it shows clearly that there is no association with Facebook. Minerva, however, it might be useful to address that, since it only says "meta", and the font is really similar to Meta's font so that could be misleading, perhaps adding the MH logo to it such as Vector?

Nonetheless, I don't personally see it as a huge issue. Nobody is likely to come across Miraheze Meta on accident if they're looking for anything in relation to Facebook—or Meta—I would think. --Original Authority (talk) 21:09, 2 February 2023 (UTC)

No objections to this proposal, but why not just Miraheze or miraheze as the wordmark in the New Vector and other applicable installed themse on this wiki? Meta Wiki is, after all, the official website for Miraheze, given the limited content on the landing page. Dmehus (talk) 23:38, 4 February 2023 (UTC)

Comment: Or better still we can say Miraheze Meta-Wiki, just as WMF's metawiki have it. Having just Miraheze might make it look like it's the company website, like the landing page, but something like Miraheze Meta-Wiki, would make it look like the project collaboration site and not the company site.

Also, saying just Miraheze Meta would look like Miraheze Facebook group or page... So, that doesn't look good either, in my humble opine. -- Joseph TB CT CA 00:07, 5 February 2023 (UTC)

I wouldn't say including just "Miraheze" would make it look like a company website, though technically it is that. It's just a company website the community can freely edit. Any part of Miraheze's website can be community edited, even landing page. That being said, I guess Miraheze Meta Wiki would be okay, too, but I don't see the need for "Meta-Wiki" to be punctuated in any way (whether that be a hyphen, en dash, or similar). :) Dmehus (talk) 00:54, 5 February 2023 (UTC)

IMO Miraheze Meta Wiki is too wordy. Miraheze Meta should be just fine, as I don't believe there's another "Meta" out there for the service. The "wiki" at the end seems unnecessary, as well, that part is obvious by looking at the site. Thanks - BrandonWM (talk • contributions • global • rights) 00:59, 5 February 2023 (UTC)

Maybe it's just me, but when I hear of Meta, I don't think of Facebook (because facebook.com still exists in its usual form), I think of the company that owns Facebook and several other products, and decided to go on a detour inventing something entirely unrelated to its original purpose and brand. Therefore, I would never associate the simple word "Meta" alone with a Facebook group, unless there is other context too. Collei (talk) 01:03, 5 February 2023 (UTC)

I see two directions this could go in.

One, do away with Meta and have this wiki just be Miraheze's homepage (i.e. could rename metawiki to wwwwiki to get it at www.miraheze.org?)

The issue though is that this could make people think this is their wiki (that's already an issue and this could make that worse) or make it harder to split tasks (i.e. wiki creations and SRE both live on Meta when I don't think they should). And these go in opposite directions. So, what does everyone else think? Naleksuh (talk) 22:51, 20 February 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘There is a mockup (https://commons.miraheze.org/wiki/File:MirahezeWordmark_MockupUbuntu.svg) on commons that I uploaded awhile ago for the previous RFC. (I uploaded a new version that doesn't rely on installed fonts, though caching may make it not look right initially). MacFan4000 ^{(Talk Contribs)} 23:28, 20 February 2023 (UTC)

Community portals[edit source]

How do I create a community portal for my wiki? Elijah Wilder (talk) 19:18, 15 February 2023 (UTC)

You can create a page named Project:Community portal on your wiki. Tali64³ (talk) 19:30, 15 February 2023 (UTC)

It won't have a button like it does here? Elijah Wilder (talk) 19:33, 15 February 2023 (UTC)

You can add the button by making sure InputBox is enabled on your wiki and then creating a form with the type property being set to commenttitle. Tali64³ (talk) 19:38, 15 February 2023 (UTC)

Twinkle doesn't work[edit source]

I have tried several ways of running twinkle on Free Editing Wiki (on my account, not as a gadget), and I have the following three problems:

"twinkleoptions.js could not be loaded."
The rollback links don't work.
After clicking a rollback link, it would bring me to <page name>&twinklerevert=norm

Bbbtest (talk) 20:10, 21 February 2023 (UTC)

I think you get the first error because you have to edit your settings at Meta:Twinkle/Preferences first. Agent Isai ^{Talk to me!} 20:11, 21 February 2023 (UTC)

@Agent Isai: I did! In fact I did it on three wikis: freeediting.miraheze.org, meta.miraheze.org, and dev.miraheze.org. Bbbtest (talk) 20:42, 21 February 2023 (UTC)

It doesn't even work here. Bbbtest (talk) 02:39, 22 February 2023 (UTC)

(That was using that gadget) Bbbtest (talk) 03:56, 22 February 2023 (UTC)

User:Bbbtest The dev wiki version works fine for me. It might be a browser issue. Is there anything in the console? Naleksuh (talk) 06:44, 22 February 2023 (UTC)

@Naleksuh: Using ios right now, will check tomorrow on my computer. Bbbtest (talk) 07:12, 22 February 2023 (UTC)

User:Agent Isai That page will only change the settings on Meta. To edit Twinkle across all of Miraheze, use Twinkle/Preferences Naleksuh (talk) 06:44, 22 February 2023 (UTC)

hotcat[edit source]

how do i get hotcat on my wiki? thank you Lolkikmoddi (talk) 15:52, 4 March 2023 (UTC)

Please see Gadgets/HotCat. BrandonWM (talk • contributions • global • rights) 16:11, 4 March 2023 (UTC)

Can't create a page[edit source]

I tried to create a redirect, but it got blocked by the abuse filter. Could someone fix this? Bbbtest (talk | contribs | e-mail) 22:11, 15 March 2023 (UTC)

Due to an extremely high amount of spam and accidental page creations by novice users, non-autopatrolled users can't create pages. Is there a page in particular which you want to create? Agent Isai ^{Talk to me!} 22:34, 15 March 2023 (UTC)

@Agent Isai: I wanted to redirect Fundraiser 2023 to Fundraiser. Could I have the autopatrolled right? Bbbtest (talk | contribs | e-mail) 00:00, 16 March 2023 (UTC)

I created. by Buehl106·Talk·e-mail 00:23, 16 March 2023 (UTC)