Requests for Comment/Content Policy reform

Our current Content Policy was initially created around 2017 and has had some minor modifications since then. Since 2017 however, the project has grown substantially and a lot of new challenges have arisen which the current Content Policy is simply not equipped to deal with. What an outdated Content Policy does is it forces Stewards to rely on vague clauses to close clearly problematic wikis. That's why we are proposing a large Content Policy reform which reflects the current reality and allows Stewards and Global Sysops to deal with problematic situations in a better way. It should also be made clear that this Content Policy doesn't attempt to give more power to Stewards or to limit wiki autonomy. This RfC includes: clarifications, slight modifications to the status quo as well as completely new proposals. These new proposals attempt to ban certain types of wikis that that do (and have done) damage to Miraheze and which cause a lot of issues and drama as well as a generally negative reputation for Miraheze. Anything that is not mentioned here will remain part of the current policy unchanged.

It should be noted that all proposals are independent from each other so if you wish to oppose some and support others that is fine.

In order to make it easier for the closing Steward to implement the new proposals but also for users to better visualise the proposals, a model Content Policy has been created with each proposal organised into different sections. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)

Co-sponsored by: Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)

Proposal 1 (Scope)

 * The Content Policy outlines the types of content that Miraheze is not willing to host. Wiki creators are expected to know this policy and apply it to new requests. Wiki administrators are also expected to know this policy and are responsible for ensuring that their wikis do not fall outside the bounds of these rules. If administrators repeatedly ignore or do nothing about violations of this policy, the wiki in question will be closed. This policy is mainly directed to wiki leadership but ordinary editors should also make sure to also follow this policy and any local content policies that may exist on the wikis on which they edit.

Explanation: Minor modification of the current status quo

Support (1)

 * 1) As proposer. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) No objections, just minor wording change.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) Seems fair enough. FatBurn0000 (sandbox | CentralAuth) 06:16, 13 September 2022 (UTC)
 * 4) Fair and clear. KatozzKita (talk) 06:52, 13 September 2022 (UTC)
 * 5) Bertie (talk) 07:56, 13 September 2022 (UTC)
 * 6) No objections, all clear. --Soukupmi  (talk) (✔) 08:39, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8) --Executive2 (talk) 10:00, 13 September 2022 (UTC)
 * 9)  per above - no issues with slight changes. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 10) ZeusDeeGoose (talk) 10:38, 13 September 2022 (UTC)

Proposal 2 (Illegal content)

 * Miraheze does not host any content that is illegal in the United Kingdom.

This includes but is not limited to sales of various forms of contraband (ivory, fissionable material, roofies, controlled substances), incitement to violence or hatred, or underage nudity. While we expect wiki administrators to help police this, Miraheze reserves the right to delete illegal content without prior notice. Generally, content will be removed by Stewards or Global Sysops if not done so by local administrators but in more severe cases, content may be removed by Trust and Safety under the Terms of Use.

Under United Kingdom Copyright Law (Copyright, Designs and Patents Act of 1988), Miraheze must remove material reported as infringing copyright, but editors or administrators may file a counter-notice if they believe the content is not, in fact, infringement. To file a Takedown Request, please use TSPortal.

Explanation: Replacing DMCA mentions with the Copyright, Design and Patents Act (as Miraheze is incorporated in the UK), add link to TSPortal, fix grammar, and very minor modification of the current status quo.

Support (2)

 * 1) As proposer. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) No objections. Minor wording changes that help update the policy like changing mentions of DMCA to UK copyright law and adding a link to TSPortal which T&S prefers now versus email reporting.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) Again, should be fine. FatBurn0000 (sandbox | CentralAuth) 06:17, 13 September 2022 (UTC)
 * 4) Obviously more clear. KatozzKita (talk) 06:58, 13 September 2022 (UTC)
 * 5) Yes. Bertie (talk) 07:59, 13 September 2022 (UTC)
 * 6) No objections. --Soukupmi  (talk) (✔) 08:42, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8)  per above - no issues with slight changes. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)

Proposal 3 (Difficult for other wikis)

 * A wiki must not create problems which make it difficult for other wikis.

Things which have a tendency to draw unwelcome attention to the wiki farm, such as hate speech, routine denial of service attacks, excessively violent content, references to self-harm, or places in which illegal activity is discussed can create conditions that penalise other wikis, either in SEO, domain blacklisting, downtime, trust in the wiki farm, or excessive Steward or Global Sysop time usage, especially in terms of policing content.

If we believe that your wiki proposal will hinder other wikis, we may decline your request. Additionally, we may suspend your wiki if these problems occur later, though this is very rare.

Note: Minor modification of the current status quo such as replacing the mention of 'staff' with Stewards/Global Sysops. It should be noted that this section should (and has) only be used as a last resort and decisions to invoke this section should not be taken lightly.

Support (3)

 * 1) As proposer. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) No objections. The term 'staff' is rather vague nowadays as Miraheze has no staff so this helps clarify who this policy is directed towards.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) FatBurn0000 (sandbox | CentralAuth) 06:18, 13 September 2022 (UTC)
 * 4) Full agreement Bertie (talk) 08:02, 13 September 2022 (UTC)
 * 5) No objections. --Soukupmi  (talk) (✔) 08:54, 13 September 2022 (UTC)
 * 6) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 7)  I would like to say that I do strongly believe that this part of the Content Policy should not be used excessively by Stewards simply for the reason that some outside users do not like a wiki - it should be reserved to extreme cases. I think that is it a useful part of the Content Policy but I would have appreciated if it was less vague and if it was more clear that Stewards are not meant to interpret it in the way that they want. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 8) --Executive2 (talk) 10:17, 13 September 2022 (UTC)

Comments (3)

 * 1) To be honest, the phrase "must not create problems for other wikis" - or entite farm, kind of feels like the entire purpose of CP? Especially w/ section regarding toxic and deceiving wikis. And mentioned heavy topics not being referenced - does it mean described in details, or being positive, encouraging? If a book or song deals w/ such themes, directly or not, it can't have a wiki or an article? Some of them may be inevitable part of biographies too. I personally look at these subjects as something that goes along w/ NSFW (there is even separate term tho, NSFL), and can be warned about or hidden as well. Also I remember stumbling on one rather morbid wiki, I forgot its name, but the scope was describing death of various individuals; how it fails under this policy? KatozzKita (talk) 08:06, 13 September 2022 (UTC)
 * Forgot to add horrors, plenty of horror games are pretty graphic and deal w/ a lot of themes, take Silent Hill or Resident Evil for example. And just to make it clear - section sounds way too vague, it might be interpreted incorrectly, that's why I'm asking.KatozzKita (talk) 08:24, 13 September 2022 (UTC)

Proposal 3.1 (Forking)

 * Direct forks of other Miraheze wikis where no attempts at mediations are made are not allowed.

A direct fork of another Miraheze wiki where little to no attempts have been made to mediate situations on the existing wiki or existing community are prohibited. If mediation has been attempted and failed, contact a Steward who will be able to support the community through any follow up processes deemed necessary including but not limited to acceptance of a fork wiki as an exemption to this clause.

Explanation: Current status quo but made into a separate section for more clarity.

Support (3.1)

 * 1) As proposer. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) No objections. Same wording as current already enacted clause just that it has been separated into its own proper section.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) I am very much against forking other wikis. FatBurn0000 (sandbox | CentralAuth) 06:18, 13 September 2022 (UTC)
 * 4) KatozzKita (talk) 07:00, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:02, 13 September 2022 (UTC)
 * 6) Absolutely. --Soukupmi  (talk) (✔) 08:56, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8)  per above - no issues with slight changes. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)

Proposal 3.2 (Wikimedia project forks)

 * Direct forks and forks where a substantial amount of content is copied from a Wikimedia project are not allowed.

Because Miraheze runs on a finite amount of space, direct forks (forks which seek to recreate and emulate a Wikimedia project by copying all of their content from there) and forks where a substantial amount of content is copied from a Wikimedia project are prohibited. If you believe you have a valid reason to fork a Wikimedia project (such as to save a project which is closing), please contact a Steward who will be able to grant an exemption to this policy depending on the circumstances. Existing wikis which are in violation of this clause are exempted from this policy.

Explanation: We have a lot of people who try to recreate Wikimedia projects such as Wikipedia on a common basis. These wikis usually tend to be a carbon copy of Wikimedia projects which tends to be a mess of copyright attribution issues and broken content. A full copy of a Wikimedia project like Wikipedia would also use up a lot of database space. We have my Wikipedia-like encyclopedic projects already so there shouldn't be a need more of these. If there is a legitimate need to fork a project such as if a small wiki in a different language is shutting down, there should be no issue with Stewards granting an exemption to this clause.

Support (3.2)

 * 1) Per the explanation above, it doesn't make sense for us to just host Wikipedia mirrors. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Miraheze cannot host Wikimedia/Wikipedia mirrors, it's silly to try and replicate a big Wikimedia project such as Wikipedia, especially big Wikipedias such as the English one. We have seen time and time over attempts to do this which fail badly and only end up being copyright disasters or broken projects where pages are missing templates, missing styling, have errors related to Lua, and more, and they end up not even being used most of the times and only take up database space. For this reason, I strongly support.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) Forking just any wiki is one thing, but forking Wikipedia and other Wikimedia projects? Also, good luck with that BTW. FatBurn0000 (sandbox | CentralAuth) 06:19, 13 September 2022 (UTC)
 * 4) Wikimedia forks are blight not only of Miraheze, but entire Internet. The idea to copy Wikipedia alone is undoubtedly silly. KatozzKita (talk) 07:03, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:03, 13 September 2022 (UTC)
 * 6) Absolutely. --Soukupmi  (talk) (✔) 09:11, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8)  There is no reason why Miraheze should accept to host content that already exists on Wikipedia - it is a waste of space. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 9) --Executive2 (talk) 10:21, 13 September 2022 (UTC)

Proposal 4 (Anarchy)

 * Miraheze does not host wikis that operate on the basis of an anarchy system (i.e. no leadership and no rules)

This policy requires local administrators to help enforce it, so a wiki where there is no local leadership willing to enforce this policy and which declares to have no rules is not compatible with this policy.

Explanation: This policy doesn't mean that every wiki has to have written rules. By 'leadership' what is meant is simply an administrator who is able to make sure content doesn't violate this policy. This policy should be strictly interpreted.

Support (4)

 * 1) Per the explanation above, anarchy wikis are not compatible with what we currently demand in the CP and would just create extra work for Stewards and Global Sysops. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Anarchy wikis tend to be very hard to moderate in a global sense and sometimes necessitate a lot of global intervention which is something we don't want to do on a regular basis. Even before I was a Steward, I watched on the sidelines as Stewards or Global Sysops would sometimes have to intervene in such wikis and from their comments, I can deduce it wasn't much a pleasure to have to constantly enter those wikis to delete, RevisionDelete, warn, or block users. Anarchy is incompatible with our entire system so as such, I support this.  Agent Isai  Talk to me! 06:13, 13 September 2022 (UTC)
 * 3) Provided that this doesn't include "free vandalism" wikis, I'm okay with it. FatBurn0000 (sandbox | CentralAuth) 06:21, 13 September 2022 (UTC)
 * 4) Fair, basic policies must be followed. KatozzKita (talk) 07:10, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:04, 13 September 2022 (UTC)
 * 6) Yep. --Soukupmi  (talk) (✔) 09:12, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8)  Stewards cannot be expected to police the Content Policy instead of local administrators who do not care about global policies. It should be a given that wikis that do not follow this policy by their very nature should not be allowed. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 9) --Executive2 (talk) 10:22, 13 September 2022 (UTC)

Proposal 5 (Toxic)

 * Miraheze does not host wikis where the community has developed in such a way as to be characterised as toxic

This may include wikis where there have been repeated personal attacks, harassment of users, 'doxxing', hate speech and other Code of Conduct violations and where local administrators have ignored, enabled, and/or done little to stop this. Stewards and/or Global Sysops will attempt to remediate the issue first where possible with local administrators and the community.

Support (5)

 * 1) This proposal is necessary because unfortunately some wikis may start out well but then they end up being toxic places where users are harassed and personally attacked and with the current policy there is no clear indication that these wikis are to be closed. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Reception123 summed up well what has happened time and time again. These sorts of wikis which harass users or engage in harmful practices have no room on our project and should not be allowed. Stewards and Global Sysops will always try to remediate any issues however which is very good as this allows communities which perhaps have swayed from their original intent or scope to rectify the issues and avoid being closed.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) Great idea. FatBurn0000 (sandbox | CentralAuth) 06:21, 13 September 2022 (UTC)
 * 4) Absolutely needed. KatozzKita (talk) 07:12, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:04, 13 September 2022 (UTC)
 * 6) We are not 4chan or Bitchute. Firestar464 (talk) 08:13, 13 September 2022 (UTC)
 * 7) Sad that it's needed, but necessary to have. --Soukupmi  (talk) (✔) 09:13, 13 September 2022 (UTC)
 * 8) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 9)  As with the proposal above I believe that Stewards must be careful when interpreting this I think this proposal is specific enough to prevent an abuse of power and is reasonable. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 10) --Executive2 (talk) 10:23, 13 September 2022 (UTC)

Proposal 6 (Sexual nature involving minors)

 * Miraheze does not host wikis of a sexual nature which involve minors in any way.

Whether content is of a sexual nature and whether it involves minors will be determined by reference to all the circumstances and descriptions. Content includes written content, real images and animated or fictional images.

Support (6)

 * 1) Even though most of this is likely illegal in the UK, this section is useful to avoid the gray areas between illegality and legality. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Clear cut policy. This sort of content (which is mostly illegal should not be allowed on Miraheze and will be very helpful in avoiding gray area situations.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) Fair enough. FatBurn0000 (sandbox | CentralAuth) 06:22, 13 September 2022 (UTC)
 * 4) KatozzKita (talk) 07:19, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:05, 13 September 2022 (UTC)
 * 6) No objections. --Soukupmi  (talk) (✔) 09:14, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8)  As mentioned above by others I do not think Miraheze needs to host such content even if determined to be almost legal. Hosting such content is likely to taint Miraheze's image and is disapproved by the vast majority of people. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 9) --Executive2 (talk) 10:25, 13 September 2022 (UTC)

Comments (6)

 * 1) Unless MH got takedown notice from government or something similar, this section is pretty much gray zone especially about anime stuffs. I would say normal person is fine when looking at a normal image but if it is a pedo, anything could be their fantasies regardless sexual or not. Max20091 (talk) 07:34, 13 September 2022 (UTC)
 * Many platforms have already banned animated content which portrays children sexually or suggestively. This has even extended to anime and furry content. I presume Miraheze would follow suit, and there may be some legal ramifications as well. dross  (t • c • g) 07:43, 13 September 2022 (UTC)
 * 1) Not to be too much of a stickler about specificity here... Where would topics which document (most likely illegal) activities/events fall under this proposal? For example, subjects such as CSAM, murder, terrorism, etc. While the sharing and portrayal of the subject content would be clearly prohibited by other sections (e.g. no illegal content), how does the proposal treat neutral and effective documentation of such subjects?  dross  (t • c • g) 07:43, 13 September 2022 (UTC)
 * This proposal only deals with sexual content. Things like CSAM, murder and terrorism aren't really that much of a gray area and would clearly fall under the illegal activity clause and either way likely be dealt with by T&S by applying the Terms of Use as the examples you give are really serious. Documentation of subjects like that will not be banned by the CP as long as it's not illegal in the UK, though of course many things related to those subjects will undoubtedly be illegal (such as a 'how to guide' for example). This proposal is aimed at wikis where users attempt to make things ambiguous and don't explicitly show that the content is about underage users but where the circumstances may say otherwise. Reception123 (talk) ( C ) 08:22, 13 September 2022 (UTC)
 * Indeed, this proposal may go beyond what UK law currently bans as the idea really is that anything that's sexual and to do with minors will be banned, regardless of what form it takes (like anime). Reception123 (talk) ( C ) 08:24, 13 September 2022 (UTC)

Proposal 6.1 (Sexual fetishes involving minors)
Additionally to Proposal 5.1,
 * Wikis which focus on fetishes that are sexual in nature which involves minors are not allowed. This includes written, real images and animated/fictional material.

Support (6.1)

 * 1) While some of these may not be illegal in the UK, they are something that is considered by many to be morally reprehensible and something that a lot of users on Miraheze would probably not want us to host. We try to be as least restrictive as we can about which wikis can't be hosted, but I feel like hosting wikis like this really creates (and would create) a negative image for Miraheze and even makes Miraheze users uncomfortable. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Reception123 sums it up perfectly. We do get the occasional report or comment from time to time on Discord and IRC about certain wikis which relate to fetishes involving minors and sadly, for the most part, we haven't been able to do much because policy does not allow for their closure unless they violate a global policy but most users will agree that these wikis are rather reprehensible and do not have any room on Miraheze.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) This could be part of the previous one, but sure. FatBurn0000 (sandbox | CentralAuth) 06:23, 13 September 2022 (UTC)
 * It being a separate proposal doesn't actually change anything since if approved it would be part of the same section (see the model CP). The only reason why it was separated is in case some users wish to support 6 but wouldn't go so far as 6.1. Reception123 (talk) ( C ) 06:25, 13 September 2022 (UTC)
 * 1)  UK banned possessing minor pornography so sure sexual fetishes shouldn't be allowed in the first place Max20091 (talk) 06:53, 13 September 2022 (UTC)
 * 2) Much needed and understandble addition. KatozzKita (talk) 07:23, 13 September 2022 (UTC)
 * 3) Bertie (talk) 08:06, 13 September 2022 (UTC)
 * 4) Yep, as above. --Soukupmi  (talk) (✔) 09:23, 13 September 2022 (UTC)
 * 5) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 6)  Same as for Proposal 6 I believe that this is not something we want to be hosting and is a liability for the project. A small minority of people may enjoy such content and think it to be innocent but I do not believe that is the view of the majority. The latest world trends are definitely in the area that such content is not to be tolerated even if not real. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 7) --Executive2 (talk) 10:27, 13 September 2022 (UTC)

Proposal 7 (NSFW Wikis)

 * Wikis which primarily host content deemed 'not safe for work' (NSFW; including but not limited to wikis focusing on lewd games/TV series, etc.) must follow the following rules:
 * 1. No content deemed 'not safe for work' (i.e. explicit imagery) may be posted on the main page of the wiki.
 * 2. A dismissable sitenotice must be displayed which alerts users that the content is not appropriate for those under 18.
 * 3. Explicit imagery, where possible, should be collapsed by default.

Explanation: This is already the status quo for most wikis. In their wiki request, we ask them to follow these guidelines and all wikis agree to them but it is voluntary, there is nothing requiring a wiki to put a notice telling users it deals with NSFW subjects or stopping them from putting lewd imagery on their front page so it would be good to codify this. Any currently existing wiki not following this would be given ample time to get into compliance and would receive assistance where needed.

Support (7)

 * 1) Per explanation above. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) This is already the status quo for most wikis. A long standing convention which precedes me is asking these wikis if they voluntarily agree to these terms. While all wikis that I've processed their request for have happily obliged, it would be best to formally codify this practice.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) I think this is okay? FatBurn0000 (sandbox | CentralAuth) 06:24, 13 September 2022 (UTC)
 * 4) About time, lack of clear and accessible reference sure seemed a bit strange. KatozzKita (talk) 07:26, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:07, 13 September 2022 (UTC)
 * 6) Not on Main page - yes. --Soukupmi  (talk) (✔) 09:25, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8)  While I believe numbers 1 and 2 are reasonable requirements I do not fully agree with 3 for two reasons. The first reason is that it if people have accessed that page on the wiki already does that not likely mean that they wish to view the content? The second is that it is too vague by saying "where possible". --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 9)  Same as above…--Executive2 (talk) 10:32, 13 September 2022 (UTC)

Proposal 7.1 (NSFW subdomains/sitenames)

 * Wikis may not feature subdomains or sitenames which mention lewd items or subjects such as sexual organs, sexual fluid, sexual acts, and other lewd and explicit topics.

Explanation: A perennial complaint you'll see on Discord is someone complaining wikis such as 'cumclicker.miraheze.org' or similar wikis with other explicit subdomains appear on user's CentralAuth. We understand that concern and believe it would be good to prohibit mentions of this. Any currently existing wikis incurring in a violation of this would be given help in transitioning subdomains, redirecting their old subdomain, and general SEO help.

Support (7.1)

 * 1) Per explanation above, it seems very inappropriate to have such terms included in subdomains and there is no need for that. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) As mentioned, you'll find a complaint every now and then from people who find out that their CentralAuth lookup states that they've visited such wikis. Many times, people aren't even aware that they've visited such wiki but due to the nature of the login system, their account has become permanently attached to the wiki. If you search up the name for any wiki which features a lewd subject in their subdomain on Discord, you'll probably find a few complaints from users asking if they can get rid of that on their CentralAuth query. It isn't, in case anyone is wondering which many times aggravates users. I strongly support this.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) I mean something like "pornography.miraheze.org" should be fine but this seems to be not that bad. FatBurn0000 (sandbox | CentralAuth) 06:25, 13 September 2022 (UTC)
 * Yeah, something like that would be allowed but overly lewd mentions of explicit things wouldn't. Agent Isai  Talk to me! 06:27, 13 September 2022 (UTC)
 * 1) There are proper terms, and then there's profanity, but w/ people not wanting to be associated w/ such wikis because of CentralAuth is a fair reason (although the link will still be there, "normal" or not?). At least such  can go w/ abbreviations. KatozzKita (talk) 07:30, 13 September 2022 (UTC)
 * 2) Bertie (talk) 08:08, 13 September 2022 (UTC)
 * 3) No objections. --Soukupmi  (talk) (✔) 09:26, 13 September 2022 (UTC)
 * 4) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 5)  Unwilling people should not be exposed to such NSFW wiki names if they do not wish to visit the wiki. I cannot imagine that many wikis will fall under this category but as an example was given I think it is fair to ban this. In addition users between the ages of 13 and 18 may visit Miraheze and therefore it is completely inappropriate to have such domain names. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 6) --Executive2 (talk) 10:33, 13 September 2022 (UTC)

Proposal 8 (Hateful content)

 * Miraheze does not host wikis that promote violence, hatred, or harassment against a person or group of people.

This include wikis which promote violence or hatred against people or groups of people based on factors such as race, ethnicity, gender, sexual orientation, religious affiliation, age, disability, or other marginalised groups.

Explanation: This only applies to promotion of violence, hatred, or harassment. This section does not affect or prohibit criticism or critical commentary.

Support (8)

 * 1) As proposer, hateful content is not something that we want to host and many times such behavior could be borderline illegal. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) This policy is pretty straight forward. Hatred has no place on Miraheze and so this new addition to the Content Policy makes perfect sense.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) Fairly simple. FatBurn0000 (sandbox | CentralAuth) 06:26, 13 September 2022 (UTC)
 * 4) Long due. KatozzKita (talk) 07:38, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:08, 13 September 2022 (UTC)
 * 6) YES. --Soukupmi  (talk) (✔) 09:27, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8)  The explanation under the proposal is satisfactory to me that this proposal will not be used to silence uncomfortable opinions and will focus on hatred or violence. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 9) --Executive2 (talk) 10:34, 13 September 2022 (UTC)

Proposal 9 (Deceptive content)

 * Miraheze does not host wikis with the sole purpose of deceiving, defrauding, or misleading people.

Wikis which willfully engage in deceiving, defrauding, or misleading people are prohibited. Wikis are prohibited from engaging in disinformation, misrepresenting information purposefully to deceive and defraud, or from concealing their origin in order to mislead users on their intentions. Wikis may not engage in impersonating any person or organization. Misleading claims on health which have the potential to cause serious harm to people or public health are prohibited. This is not an exhaustive list of practices deemed deceptive but helps illustrate what sorts of behaviors are.

Wikis which make it clear that their intention is not to deceive (which may include fantasy world, role-playing, humor wikis, etc.) would not fall into a violation of this policy.

Explanation: In the wake of a changing internet landscape, platforms are abused more and more to mislead people into believing certain things. This clause will ensure that willful and deliberate deceptive content is prohibited on Miraheze. Stewards will only act on this where it is clear that the content is there to trick people negatively into believing something harmful. Stewards will never remove content they don't like and will always strive to enforce this policy in clear cases where the deceiving, defraudment, or misleading of users impacts them negatively. Where possible, Stewards should discuss with their colleagues before closing a wiki under this section.

Support (9)

 * 1) Per the explanation, this section would not be used lightly and really only in cases of clear deception so that seems reasonable to me. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) As with proposal 8, this is pretty straight forward. Deceptive content which willfully and deliberately tries to trick people shouldn't be hosted on our platform. Such abuse of the platform, which could range from scamming to political purposes, should not be harbored on Miraheze as it may prove harmful to people, including leading to real life danger if the deception reaches such heights. As stated in the explanation, this policy would be applied only where it is clear that the content is there to deceive or defraud people, not for any other purposes.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) Reasonable. FatBurn0000 (sandbox | CentralAuth) 06:26, 13 September 2022 (UTC)
 * 4) Much needed w/ current and recent events. KatozzKita (talk) 07:39, 13 September 2022 (UTC)
 * 5) Bertie (talk) 08:09, 13 September 2022 (UTC)
 * 6) Needed. Though probably hard to define/identify alternative facts, but as it is about harmful content it should be easier. --Soukupmi  (talk) (✔) 09:32, 13 September 2022 (UTC)
 * 7) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 8) --Executive2 (talk) 10:38, 13 September 2022 (UTC)

Oppose (9)

 * 1)  I do not feel fully comfortable supporting this proposal. Even if many platforms are adopting such rules they not only remain controversial but the main problem is that the people who enforce them are not accountable and transparent enough. I am in agreement that Miraheze should not allow disinformation - but who decides what is disinformation? Respectfully I am not sure whether the current small Steward team is really able to make such difficult decisions. There is also a possibility that this would get into political areas which I do not think anyone wants to get into. I support the fraud elements of the proposal but I cannot support the vague disinformation part as written. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)

Proposal 10 (File hosting)

 * Miraheze does not host wikis whose main purpose is to act as a file sharing service

Wikis whose main purpose is to act as a file hosting or sharing service are prohibited. Because Miraheze has finite resources, files on wikis should be used to upbuild the wiki. This does not affect 'commons'-type wikis that serve multiple wikis that are part of a group or network.

Support (10)

 * 1) Some current wikis use up a lot of file space but many of those files aren't used on pages. This should not be the case as no other free file host offers as much space as us. We aren't a file host but a wiki host so files should mostly be used in articles and not just  for viewing separately. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Wikis aren't file hosts and they shouldn't be. Such usage of the platform invokes images of the tragedy of the commons. If you aren't using files to build a wiki then you should look for another host. We have finite resources and while we've managed to be well off with our current donations, those donations wouldn't be enough to cover being everyone's own personal image hosting service. If someone were to abuse our resources for their own personal reasons or gain, such abuse could very well cause us to run out of space and impact common users who are trying to upload files which would lead to user dissatisfaction.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) You need an entire wiki just to upload pictures? That seems unnecessary. FatBurn0000 (sandbox | CentralAuth) 06:27, 13 September 2022 (UTC)
 * Unless it's Wikimedia or Miraheze Commons, as wiki veterans like me already know. As long as both are around, you don't really need to upload locally (unless it relates to your site's projects/focus/scope/T&Cs). --Routhwick (talk) 06:49, 13 September 2022 (UTC)
 * 1) Totally reasonable, and FANDOM made a lot of people to not care about resources and usage of files - and copyrights. KatozzKita (talk) 07:43, 13 September 2022 (UTC)
 * FANDOM ads made way more money than its own hosting services so storage isn't a problem. About MH, I would say people loves hosting on MH is because it's much cheaper to host than self-hosting (if they do donate). One particular case is the gallery section which can be extremely big compared to others. About copyrights, what you can do further than declare as fair uses in most cases? Max20091 (talk) 09:05, 13 September 2022 (UTC)
 * What I said is that average user lacks of concept of finite resource, although social media are also to blame here. FANDOM can afford resources and so users don't question should they control the size of their file vault or not, and hosting doesn't force them to do so. There are plenty of FANDOM wikis w/ loads of unused files, or just bloated w/ files which have no real significance but to be here like on a file hosting - extensive amount of screenshots is a prime example (bonus points if they are PNGs). I tried to clean up files on a 5k article video game wiki - and nobody helped me. Editors and admins moderate articles as primary content of the wiki, but not files.
 * There are also a lot of abandoned wikis on FANDOM - and blogs, and pages on various platforms, they're hanging out there because hosting can afford that, whereas Miraheze has dormancy policy, it's quite unusual for some people.
 * Kind of the same problem w/ copyright - sure you can say it's fair use, but for 5 years I haven't stumbled on FANDOM on a wiki which adds license plates to every uploaded files, a lot of users have no concept of properly applied copyrights (hell, I didn't until I tried to make a big update on a WP article - that was a revelation). I often encountered how users on FANDOM would upload fan arts off DA or other places - ofc w/o asking artists first. Meanwhile Miraheze clearly states the whole copyright deal and encourages you to specify licensing, be it fair use or, say, permission granted by game's developers.
 * KatozzKita (talk) 10:10, 13 September 2022 (UTC)
 * 1) Bertie (talk) 08:11, 13 September 2022 (UTC)
 * 2) Max20091 (talk) 09:05, 13 September 2022 (UTC)
 * 3) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 4)  Per above - excessive hosting of files on a free project is not right. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 5)  Should be obvious. --Soukupmi  (talk) (✔) 10:39, 13 September 2022 (UTC)

Proposal 11 (Steward conservatorship)

 * Where there is concern that a wiki is unable to meet its obligations in enforcing the Content Policy or other global policies, a wiki may be placed under a conservatorship.

Local administrators may petition Stewards to place their wiki under a conservatorship. Under a conservatorship, Stewards (and Global Sysops, unless otherwise requested not to by Stewards) would assume joint administrative control of a wiki alongside local administrators and Stewards would seek to help the community develop in a healthy manner that allows for the community to flourish and for the local community to effectively self-govern and for leadership to enforce all global policies. Stewards would temporarily fully assume a local role of bureaucrat (and Global Sysops, administrator) or equivalent and would consult the local community and administrators on proposed changes to local policy, practices, and convention, in order to help the wiki. Stewards and Global Sysops would not be above local policy and would follow all local community-endorsed policies, as would any local bureaucrat or administrator. While there is no set timeframe for a conservatorship to end, it will be the goal of Stewards for it to end as soon as possible. Stewards will determine when a local conservatorship should conclude or they may be petitioned by local administrators or the community on the Stewards' noticeboard. Conservatorships for other circumstances may be considered on a case-by-case basis.

Under special and mostly extraordinary circumstances, Stewards may place a wiki in a conservatorship if they believe that local leadership is unable to address global policy enforcement concerns adequately and where previous remediation efforts involving the local administrators have failed (this includes where local administrators are chronically inactive and where reaching out to them has failed). While under these circumstances, Stewards will attempt to work alongside local administrators but if they refuse to cooperate positively or engage in self-sabotage of the wiki, Stewards may disregard them in wiki administrative affairs.

Explanation: There have been requests in the past for Stewards to step in and help local communities by acting as a sort of 'bureaucrat.' This new addition to the Content Policy would seek to codify further our role in that and give Stewards basis in policy to step in, at the request of local administrators of course. It also clarifies Stewards/GS positions on these wikis and what their end goal will be. The latter clause would be especially helpful for larger communities which require assistance and which we may not want to outright close due to the great impact it would have on their local communities (of course, provided that there are no egregious and systemic CP violations). With the latter clause, Stewards would be able to step in and institute changes in the local community (with their consent, following local voting or equivalent, in accordance to policy if any) if they deem it necessary but where local administrators are either unwilling or unable (in the case of inactivity) to do so themselves. Stewards would work with local administrators to help the community but if they are hostile to them or engage in sabotaging the wiki, Stewards will disregard them in administrative affairs (i.e., when it comes to moderation and such, Stewards will not pay too serious attention to them when it comes to proposal or complaints but will not demote them).

Support (11)

 * 1) This is an interesting idea that I think is worth trying for the reasons given above. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) A conservatorship would be voluntary for the most part and could prove very useful. There have been occasions in the past where Stewards have been asked to step in to help ensure project stability in cases of wiki instability so this would formally codify such practice and add rules which Stewards must follow such as having to listen to the local community, not being above policy, and such. There have also been cases in the past where quasi, 'light' conservatorships have been imposed on wikis where there is an active community with issues but where there are no local administrators around to intervene and help local users. Codifying our role as Stewards would greatly help formalise a practice and institute rules and requirements for such a thing which occurs. It is within the Stewards role descriptor that they are here to "work with communities to address issues facing them locally such as disputes" and a conservatorship to help restore project stability would be very helpful. As for a forced conservatorship, I am aware of cases in the past where such a conservatorship in the full meaning of the word may have helped resolve a case. I know of a semi-recent case (which was before my time as Steward but still recent) where such conservatorship would have potentially helped resolve a case to satisfaction but where Stewards couldn't do much to mediate a local dispute. It is important to note that as the explanation says, this would be done where it is deemed necessary and as the proposed change to policy says, this would be done under mostly extraordinary circumstances so this would not be the first course of action for Stewards and should be the last. This could also help a lot on wikis with inactive bureaucrats and administrators where Stewards, while already acting as 'global bureaucrats' in a sense, would be able to locally intervene to a greater extent than normal to help wikis which face problems in the enforcement of policies to help ensure that they can develop effective self-governance and autonomy. Stewards main goal would be that and wouldn't be to 'take over wikis just because' (we have neither the time nor the interest to do so).  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) This could certainly help. FatBurn0000 (sandbox | CentralAuth) 06:28, 13 September 2022 (UTC)
 * 4) Bertie (talk) 08:12, 13 September 2022 (UTC)
 * 5) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 6)  I believe this is a useful proposal as long as Stewards really do only intervene without local authority in exceptional circumstances. If this will be used regularly then I would not think it is the right balance between wiki autonomy and global help. --DeeM28 (talk) 10:13, 13 September 2022 (UTC)
 * 7) --Executive2 (talk) 10:42, 13 September 2022 (UTC)
 * 8)  Sounds good. --Soukupmi  (talk) (✔) 10:47, 13 September 2022 (UTC)

Proposal 11.1 (Conservatorship, extended)
In addition to the above, the following is added:


 * In extreme cases of uncooperative, overly hostile, and/or sabotaging behavior, Stewards (following consensus amongst them) may demote a local administrator from any extended local permission they hold. Stewards will only do this in extreme circumstances where other remediation efforts involving the local administrator in question have failed and where demotion is a necessity to ensure project stability.

Explanation: There may be times where a local bureaucrat simply refuses any change and may want to sabotage anything proposed. In these cases, the previous section stipulates that these administrators may be disregarded by Stewards but does not provide a recourse of action to address overly hostile behavior. This section would seek to codify that Stewards are able to demote these users under extreme circumstances, for the benefit of the community. Any such demotion would only happen during truly extreme circumstances and would be a last course of action for overly disruptive behavior from any administrator or bureaucrat.

Support (11.1)

 * 1) I have seen recent situations where having a clear rule about this would have been useful. It's sometimes the case that administrators are very hostile and act in a 'dictatorial' way so it may be necessary for Stewards to bring back stability and enforce the local communities wishes if these differ with the one administrator. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Realistically, Stewards should be able to demote anyone if it's rightful to do so. FatBurn0000 (sandbox | CentralAuth) 06:29, 13 September 2022 (UTC)
 * 3) Bertie (talk) 08:13, 13 September 2022 (UTC)
 * 4) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 5)  I think it would have been preferable if it was specified that a local administrator could only be demoted if they are openly defying their community. However this proposal is acceptable as it is indicated that it would be very exceptional in nature. --DeeM28 (talk) 10:14, 13 September 2022 (UTC)
 * 6)  Consensus among them and very exceptional are the right keywords IMO. Sounds good. --Soukupmi  (talk) (✔) 10:49, 13 September 2022 (UTC)
 * 1)  Consensus among them and very exceptional are the right keywords IMO. Sounds good. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:49, 13 September 2022 (UTC)

Proposal 12 (General and individual violations)

 * There are two types of violations of this policy that can be observed:
 * Individual violations: A single page or a few pages may violate this policy. In that case, the issue can easily be resolved by removing the violating content and if necessary warning the user(s) who added it and taking further measures if they continue adding violating content. The wiki as a whole cannot be said to be violating this policy.
 * General (or systemic) violations: If the entire scope of a wiki or a large amount of pages violate this policy, it is considered that the entire wiki is in violation of the policy. In this case, local administrators must attempt to resolve the systemic issues and remove the violating content. If this is not done so within a reasonable period, Stewards may close the wiki for violating this policy.

Support (12)

 * 1) This doesn't really change the status quo but just makes it clear to users that a violation doesn't necessarily need to be a whole wiki. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Very reasonable and is the status quo any how so it's important to codify this so that users know more about how violatons work.  Agent Isai  Talk to me! 06:13, 13 September 2022 (UTC)
 * 3) You shouldn't close wikis just because of a few pages. FatBurn0000 (sandbox | CentralAuth) 06:30, 13 September 2022 (UTC)
 * 4) Good addition. KatozzKita (talk) 07:47, 13 September 2022 (UTC)
 * 5) Badly needed. Firestar464 (talk) 08:16, 13 September 2022 (UTC)
 * 6) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 7)  This is a good clarification as the current policy as written gives the impression that either a wiki is violating it or it is not - there does not seem to be an in between. --DeeM28 (talk) 10:14, 13 September 2022 (UTC)
 * 8) Bertie (talk) 10:33, 13 September 2022 (UTC)
 * 9) --Executive2 (talk) 10:44, 13 September 2022 (UTC)
 * 10)  Clarifies the grey area - support. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:51, 13 September 2022 (UTC)

Proposal 13 (Wiki creation)
NOTE: This proposal modifies Wiki creators specifically but is otherwise related to the Content Policy


 * When approving a wiki, wiki creators should be quite confident that it is unlikely that the wiki will violate the Content Policy. Wiki descriptions must be sufficiently precise as to be able to help the wiki creator make that determination. If a wiki creator is in doubt, they should contact a Steward for assistance.

Support (13)

 * 1) It's important to emphasise to wiki creators that their job is to make sure that wikis don't violate the CP, as sometimes it seems that isn't clear enough. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Per Reception123, it's very important to emphasise this to wiki creators that they must be certain a wiki will not violate the Content Policy. In the past, it was perfectly acceptable to approve a wiki whose request consisted of a word or two. That is no longer the case as we've seen that that leads to problems as vague scopes many times end up in questionable wikis being approved.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) This should prevent problematic wikis from causing drama. FatBurn0000 (sandbox | CentralAuth) 06:31, 13 September 2022 (UTC)
 * 4) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 5) Bertie (talk) 10:34, 13 September 2022 (UTC)
 * 6)  re-iterate to emphasize. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:55, 13 September 2022 (UTC)

Oppose (13)

 * 1) Procedural  I support the principle described here but do not support a new addition to the policy. This is because not only is this already clear but it is already explicitly mentioned as a reason to revoke wiki creators so I am not sure why it needs to be once again re-iterated. I understand that this proposal might have been created in order to signal to wiki creators that the community wishes them to pay more attention to the Content Policy but this does not feel necessary as a policy addition. --DeeM28 (talk) 10:15, 13 September 2022 (UTC)

Abstain (13)

 * 1) I simply do not know enough about wiki creation on Miraheze--Executive2 (talk) 10:45, 13 September 2022 (UTC)

Proposal 14 (Wiki requests)

 * A wiki's scope (as defined in the initial wiki request) must not be radically and completely changed without obtaining approval from Stewards. Users who radically change the scope of their wiki without approval may be restricted from requesting other wikis.

Explanation: The terms radically and completely are to be interpreted strictly. This only applies if the scope is completely changed from what was initially thought of. For example: requesting a wiki for a personal project with friends and then turning it into a wiki berating or attacking a person. Small changes to the original scope are not affected.

Support (14)

 * 1) If we allow users to radically change their scope of their wiki without any sort of approval process, then the wiki request system would be useless as people can just lie and then do whatever they want. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Pretty straight forward. Currently, it's not exactly a violation of any policy to drastically change the scope of a wiki and many wikis do it without encountering any warnings. This is a problem as wiki creators approve requests that they believe will abide by global policies so such as practice is deception but Stewards can't really do much unless the new wiki scope violates a global policy though many times, the new scope of a wiki falls into a gray area where it's not exactly a full blown Content Policy issue but is definitely something rather questionable.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) I have to admit that I've done this before, but thinking about it I think it's a bad idea. I apologise for doing that. FatBurn0000 (sandbox | CentralAuth) 06:32, 13 September 2022 (UTC)
 * 4) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 5)  It is a good idea to close this loophole which would easily allow the entire wiki requests system to be abused and defied by a malicious user. It would be easy to request a wiki about approved topic A and then change it to unapproved topic B with no consequences. --DeeM28 (talk) 10:15, 13 September 2022 (UTC)
 * 6) Bertie (talk) 10:35, 13 September 2022 (UTC)
 * 7) Pretty straight forward. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:57, 13 September 2022 (UTC)

Proposal 14.1 (Wiki requests)
In addition to Proposal 14:
 * A wiki whose scope has been radically and completely changed may be closed by a Steward. Stewards will attempt to remediate the issue first but if the new scope of a wiki violates this policy, it may be closed.

Support (14.1)

 * 1) per above. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Per my support of 14. This formally clarifies that Stewards should try to remediate the issue rather than outright closing a wiki and clarifies that Stewards are able to close a wiki whose new scope violates this policy.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) It's a bad idea to do this, and therefore stewards can stop it. FatBurn0000 (sandbox | CentralAuth) 06:33, 13 September 2022 (UTC)
 * 4) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 5)  per supporting Proposal 14. --DeeM28 (talk) 10:15, 13 September 2022 (UTC)
 * 6) --Executive2 (talk) 10:47, 13 September 2022 (UTC)
 * 7) --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:57, 13 September 2022 (UTC) per above.

Proposal 15 (Transition)

 * If any new proposals are adopted, existing wikis that violate the new proposals will be treated more leniently and given time to resolve any violations. If the entire scope of an existing wiki clearly violates new proposals, they will be given a reasonable amount of time (i.e. 30-60 days) until closure.

Note: If this proposal fails that means that all wikis (existing and new) are treated equally and may be closed for violations immediately.

Support (15)

 * 1) Makes sense to be more lenient to current wikis since they would not have known about any changes. Reception123 (talk) ( C ) 04:59, 13 September 2022 (UTC)
 * 2) Per above, it makes sense to be more lenient to currently existing wikis to help them fix any issues and not pull the rug out from under them, so to speak.  Agent Isai  Talk to me! 06:02, 13 September 2022 (UTC)
 * 3) I'd rather have a chance to do something with my wiki before you close it (if you need to). FatBurn0000 (sandbox | CentralAuth) 06:34, 13 September 2022 (UTC)
 * 4) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 5)  It would not be fair to give existing wikis no foreseeability about new policies by immediately wanting to close them for violating something that did not exist at the time. --DeeM28 (talk) 10:15, 13 September 2022 (UTC)
 * 6) Bertie (talk) 10:36, 13 September 2022 (UTC)
 * 7) --Executive2 (talk) 10:48, 13 September 2022 (UTC)
 * 8)  Giving notice and time to react to the existing wikis are only fair. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:59, 13 September 2022 (UTC)