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)
 * 11) CrazySpruiker2001 (talk) 12:23, 13 September 2022 (UTC)
 * 12) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 13) TigerBlazer (talk) 15:03, 13 September 2022 (UTC)
 * 14) SquirtSquirtle (talk) 16:24, 13 September 2022
 * 15)  Fair and clear. Universal Omega (talk) 17:11, 13 September 2022 (UTC)
 * 16)  This is fair, no comment needed from me. Dragonite (talk) 17:24, 13 September 2022 (UTC)
 * 17) per above. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 18)  per nom. Zabby (talk) 18:05, 13 September 2022 (UTC)
 * 19)  NutrientEK (talk) 18:10, 13 September 2022 (UTC)
 * 20)   Xena   (talk)  20:10, 13 September 2022 (UTC)
 * 21)  This is pretty wordy but does the job of describing the purpose of the Content Policy.--SchizoidNightmares (talk) 21:50, 13 September 2022 (UTC)
 * 22)  Very clear wording and very good idea. A larger policy would help not only help but also because the older version seems outdated. Spencers (talk) 22:52, 13 September 2022 (UTC)
 * 23) The truth, I had experiences of users "wikis administrators" that knowing that they were doing wrong, they kept on creating offensive content towards other groups and I think even towards me, if I remember correctly. I think this is the first or second time I have made this topic public. --Hispano76 (talk) 23:30, 13 September 2022 (UTC)
 * 24) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 25) Addycakesball (talk) 21:00, 13 September 2022 (EST)
 * 26) as obvious. Missile1945 (talk) 01:24, 14 September 2022 (UTC)
 * 27) Imamy (talk) 04:32, 14 September 2022 (UTC)
 * 28) --   Joseph  TB  CT  CA   20:46, 15 September 2022 (UTC)
 * 29) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 30) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 31)  Fully approve. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (1)

 * 1)  I don't want the scope. Why we need this? WHY??? Am0ngU$ (talk)
 * If we don't have a scope, then we might as well remove wiki requests, but obviously Miraheze doesn't have the resources to do that. ZeusDeeGoose (talk) 13:31, 13 September 2022 (UTC)
 * This is already the scope of the Content Policy expect a few minor word changes. You opposing this wouldn't do much to repeal the Content Policy. Agent Isai  Talk to me! 13:32, 13 September 2022 (UTC)
 * Your definition of a threat is very deeply flawed. Myself and Agent are simply informing users of the intended effects of our proposals. Reception123 (talk) ( C ) 19:06, 13 September 2022 (UTC)
 * Sometimes, owners might be vandals or purely disruptive to their wiki. Spencers (talk) 23:31, 13 September 2022 (UTC)

Comments (1)
In the context of scope -- it seems the current Content Policy is primarily a list of negatives, describing things which are not Miraheze content.

This potentially presents some issues -- perhaps difficulties for would be new users. What sort of content belongs on Miraheze?

Possibly the Miraheze FAQ is the best document to address this issue, though perhaps other significant documentation exists?

In any event, adding an explicit mention of the FAQ (or a link to some more suitable page) at the top of the content policy page might be worthwhile as a part of this reform. --Rdm (talk) 21:05, 13 September 2022 (UTC)
 * You are right that the content policy is phrased in a way of saying "you cannot do this," rather than saying "do this," it may be possible in the future to rewrite aspects of it. I do not think the current phrasing in this proposal is a problem though, imperfect but most should understand what it is trying to say. Good enough is good for now.--SchizoidNightmares (talk) 21:55, 13 September 2022 (UTC)
 * It might not be great but I think it would be impossible to have an exhaustive list of what content we do want. Reception123 (talk) ( C ) 08:29, 15 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 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)
 * 9)  No comment. CrazySpruiker2001 (talk) 12:20, 13 September 2022 (UTC)
 * 10)  Yes, obviously. Am0ngU$ (talk)
 * 11) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 12)  No comment needed here. ZeusDeeGoose (talk) 13:34, 13 September 2022 (UTC)
 * 13) Should definitely be a given by now. TigerBlazer (talk) 15:03, 13 September 2022 (UTC)
 * 14) I have no objections whatsoever. SquirtSquirtle (talk) 16:24, 13 September 2022
 * 15) --Revival (talk) 15:45, 13 September 2022 (UTC)
 * 16) I see no problem.
 * 17)  Just minor wording changes. No objections. Universal Omega (talk) 17:14, 13 September 2022 (UTC)
 * 18) We should respect the laws of any countries regardless, no objections from me. Dragonite (talk) 17:24, 13 September 2022 (UTC)
 * 19) This is common sense. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 20)  per nom; a much needed change. Zabby (talk) 18:06, 13 September 2022 (UTC)
 * 21)  NutrientEK (talk) 18:11, 13 September 2022 (UTC)
 * 22)  Oh absolutely. You get my 100% strongest support here. No exceptions whatsoever. --DarkMatterMan4500 (talk) (contribs) 19:12, 13 September 2022 (UTC)
 * 23)   Xena   (talk)  20:20, 13 September 2022 (UTC)
 * 24)  Complying with the laws of the host country is non-negotiable.--SchizoidNightmares (talk) 21:58, 13 September 2022 (UTC)
 * 25)  It should've been given earlier. Glad it's proposed. Spencers (talk) 23:26, 13 September 2022 (UTC)
 * 26) No objections. --Hispano76 (talk) 23:32, 13 September 2022 (UTC)
 * 27) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 28) This shouldn't be given to the Polcompball, Polcompball Anarchy and Polandball wikis, but the rest can do with this feature. Addycakesball (talk) 21:01, 13 September 2022 (EST)
 * 29) Missile1945 (talk) 01:26, 14 September 2022 (UTC)
 * 30) No problems for me, but strip off the "of" in "Copyright, Designs and Patents Act of 1988" cuz that is not the legal name of the Act AudioAnimatronic1874 (talk) 03:37, 14 September 2022 (UTC)
 * 31) Imamy (talk) 04:38, 14 September 2022 (UTC)
 * 32)  I have nothing to say. Marxo Grouch  (talk) 16:42, 14 September 2022 (UTC)
 * 33) I love the fact that it was clearly explained here. --   Joseph  TB  CT  CA   20:48, 15 September 2022 (UTC)
 * 34) This draft is safest for miraheze. by Buel ·Talk·Wikimail 08:59, 18 September 2022 (UTC)
 * 35) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 36) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 37)  No issues. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (2)

 * 1)  - "inflammatory content" is a very vague description that could be detrimental to the quality of the site. --Biomaster (talk) 15:43, 13 September 2022 (UTC)
 * Mentions of 'inflammatory content' are already within the current Content Policy and has been since 2016. This amendment only seeks to change mentions of DMCA to UK copyright law to not mislead users (either way, DMCA doesn't apply to Miraheze so this mention of DMCA is wrong) and adds a link to TSPortal to report copyright infringement. Agent Isai  Talk to me! 15:51, 13 September 2022 (UTC)

Comments (2)
Are all of the things listed as examples of illegal materials actually illegal under UK law? I ask primarily because the list includes "underage nudity" instead of "underage sexual acts", which are two different things that do not completely overlap, and somebody is likely to attempt to use the distinction as a perceived loophole to bypass the intent of this rule. --Robkelk (talk) 13:14, 14 September 2022 (UTC)
 * Actually that's something that I wrote, so I can answer it: I wrote it when we were under US and NL law. It's honestly just things that I do not think it is worth it for Miraheze to host; underage nudity is banned in a lot of regions, so I included it.  Under the current policy, both are subject to removal if shown in photographic form.  IIRC UK also bans sufficiently realistic-looking fake underage nudes.  In any case, it was never meant to be an exhaustive list, but examples of things that could be banned for being illegal.  --Labster (talk) 03:29, 18 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)
 * 9)  CrazySpruiker2001 (talk) 12:26, 13 September 2022 (UTC)
 * 10) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 11) ZeusDeeGoose (talk) 13:35, 13 September 2022 (UTC)
 * 12)  Universal Omega (talk) 17:14, 13 September 2022 (UTC)
 * 13) Definitely. Dragonite (talk) 17:24, 13 September 2022 (UTC)
 * 14) per above. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 15)  NutrientEK (talk) 18:13, 13 September 2022 (UTC)
 * 16)  Very obvious here. --DarkMatterMan4500 (talk) (contribs) 19:14, 13 September 2022 (UTC)
 * 17)   Xena   (talk)  20:22, 13 September 2022 (UTC)
 * 18)  It is necessary to avoid a "tragedy of the commons"-like scenario.--SchizoidNightmares (talk) 22:30, 13 September 2022 (UTC)
 * 19)  should be right. Spencers (talk) 23:17, 13 September 2022 (UTC)
 * 20) See my comment on proposal 1. --Hispano76 (talk) 23:33, 13 September 2022 (UTC)
 * 21) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 22) Definitely! Addycakesball (talk) 21:00, 13 September 2022 (EST)
 * 23) Imamy (talk) 04:41, 14 September 2022 (UTC)
 * 24) Clear here --   Joseph  TB  CT  CA   20:51, 15 September 2022 (UTC)
 * 25) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 26) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 27)  Obviously. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Comments (3)

 * 1) To be honest, the phrase "must not create problems for other wikis" - or entire 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, or an outright taboo? 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. 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 mention horror genre, plenty of it is pretty graphic and deal w/ a lot of heavy 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)
 * This clause is more meant to deal with wikis which cause Miraheze exceptional headaches. Wikis which discuss taboo subjects wouldn't be an issue per se unless they engage in practices which causes the entire farm to be penalized such as DDoS attacks, blacklisting in search results, etc. This clause has existed in the Content Policy since it's very beginning but has only been invoked once, a month or two ago by Raidarr, to close a "children's feet" wiki which was subject of constant complaints. Wikis focusing on the horror genre would be far from causing other wikis problems and this clause is here for more exceptional cases where those wikis affect others gravely. Agent Isai  Talk to me! 15:15, 13 September 2022 (UTC)
 * 1) I forgot to mention this yesterday. Anyway, my thoughts: Criticism, ok. Insults/toxicity, no. Content also should not give the project a bad reputation (significant, consistent criticism by the public). Firestar464 (talk) 11:12, 14 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)
 * 9)  CrazySpruiker2001 (talk) 12:25, 13 September 2022 (UTC)
 * 10) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 11) This would violate 3, so this is fine. ZeusDeeGoose (talk) 13:37, 13 September 2022 (UTC)
 * 12)  Universal Omega (talk) 17:15, 13 September 2022 (UTC)
 * 13) This would be helpful for organization. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 14)  NutrientEK (talk) 18:14, 13 September 2022 (UTC)
 * 15)  No objection from me here. --DarkMatterMan4500 (talk) (contribs) 19:18, 13 September 2022 (UTC)
 * 16)  Good thing that it's getting its own section.  Xena   (talk)  20:26, 13 September 2022 (UTC)
 * 17)  Reduces redundancy.--SchizoidNightmares (talk) 22:37, 13 September 2022 (UTC)
 * 18) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 19) Agree with SchizoidNightmares. Addycakesball (talk) 21:03, 13 September 2022 (EST)
 * 20) This would help stop counterfeit wikis and fake wikis from being made. --Afunhumaninter (talk) 02:57, 14 September 2022 (UTC)
 * 21) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 22) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 23)  This seems reasonable and appropriate. We don't need duplicates. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)
 * 24)  Imamy (talk) 02:05, 22 September 2022 (UTC)

Oppose (3.1)

 * 1)  - most wikis here are not copyrightable as they're under the GNU GPL, so there should be no restrictions when it comes to forking --Biomaster (talk) 15:46, 13 September 2022 (UTC)
 * This clause is already within the Content Policy, it only seeks to put it into its own section. Opposing this will not prevent this clause from being enacted as it's already policy, it'll only prevent it from being made into its own section. Agent Isai  Talk to me! 15:52, 13 September 2022 (UTC)

Comments (3.1)

 * What is a fork wiki? Imamy (talk) 06:25, 14 September 2022 (UTC)
 * A fork wiki is a wiki where most content comes from an outside source, usually with attribution. ZeusDeeGoose (talk) 11:14, 14 September 2022 (UTC)


 * Regarding the statement: Direct forks of other Miraheze wikis where no attempts at mediations are made are not allowed. --- Does this mean that fork wikis are generally created by other users without the approval by the original site that is on Miraheze? I'm trying to understand what this means, still not sure what fork wikis or what fork means.  The statement does it mean that the original site or Miraheze or both are telling the copycat to stop duplicating / mirroring the content.  Yet the copycat is just continuing silently copying and ignoring incoming correspondence?  Thank you. Imamy (talk) 20:51, 14 September 2022 (UTC) edited to make my comment look like my comment / belongs to me Imamy (talk) 02:05, 15 September 2022 (UTC)


 * So, to put in simplier terms, a "direct fork of another Miraheze wiki" is a wiki that's either an exact copy or a partial copy of another Miraheze wiki.
 * For example, imagine this scenario. There is a big Miraheze wiki about different types of fruits. One of the editors decides that they don't want any articles about apples, so they make an exact copy of that wiki and delete all articles about apples. They didn't ask anyone for permission or discuss it before doing so. This scenario is what would be considered wrong by the policy.  Xena   (talk)  09:14, 21 September 2022 (UTC)
 * I'd also make clear that this is already the current policy but has just been made into its own section. There is not necessarily a need to ask for permission but at least attempts to resolve issues should be made. Reception123 (talk) ( C ) 11:18, 21 September 2022 (UTC)
 * I can see why this is objectionable, like hijacking someone's idea and content and then taking the project in a completely new direction. My research pulled up forklifts and other types of forks.  I didn't know enough about this topic to find anything on my own.  I can't thank you enough.  Imamy (talk) 01:52, 22 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)
 * 10)  CrazySpruiker2001 (talk) 12:27, 13 September 2022 (UTC)
 * 11) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 12)  Universal Omega (talk) 17:16, 13 September 2022 (UTC)
 * 13) per above. Tali64³ (talk) 17:59, 13 September 2022 (UTC)
 * 14)  NutrientEK (talk) 18:14, 13 September 2022 (UTC)
 * : Per Isai. The likes of Callipedia (one of the first Miraheze domains I visited, back last summer) and TME were nothing short of a noble experiment. This time around, I can see part of why staff have begun to clean house. --Routhwick (talk) 18:53, 13 September 2022 (UTC)
 * 1)  Makes perfect sense and should be a clear rule in the policy.  Xena   (talk)  20:30, 13 September 2022 (UTC)
 * 2)  Unnecessary use of resources. --SchizoidNightmares (talk) 22:35, 13 September 2022 (UTC)
 * 3) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 4) per reasons outlined in the proposal. Missile1945 (talk) 01:29, 14 September 2022 (UTC)
 * 5)  Rando111 (talk) 02:08, 14 September 2022 (UTC)
 * 6)  Beyond the legal and functional concerns of forking such massive projects, many fork requests are motivated by disagreement with or confusion regarding the operations of Wikimedia projects. Inability of a user to abide by relevant conventions or rules of the original project is not justification for a fork.  dross  (t • c • g) 08:09, 16 September 2022 (UTC)
 * 7)  Imamy (talk) 03:33, 18 September 2022 (UTC)
 * 8) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 9)  I'm supporting this as it makes general sense but if the WMF wiki count continues to grow, this may have to be revisited. — Preceding unsigned comment added by BrandonWM (User talk:BrandonWM • Special:Contributions/BrandonWM) 01:12, 19 September 2022

Oppose (3.2)

 * 1) - Wikipedia is around ~80% GNU GPL compliant. No need to restrict unless there's absolutely no intent in diverging the content from the original source, in which case there may be problems --Biomaster (talk) 15:56, 13 September 2022 (UTC)
 * But why should Miraheze use its limited space to duplicate Wikipedia content? What's the point of that? Reception123 (talk) ( C ) 16:27, 13 September 2022 (UTC)
 * 1) What's the point of this issue? Why do we need to duplicate Wikimedia and Wikipedia content into Miraheze? Addycakesball (talk) 21:05, 13 September 2022 (EST)
 * I think you meant to support this proposal, is that correct? — Preceding unsigned comment added by Agent Isai (User talk:Agent Isai • Special:Contributions/Agent Isai) 01:25, 14 September 2022 (UTC)
 * 1) per above

Abstain (3.2)

 * 1)  With or without this policy, fork-wikis will be deleted.  Before this policy was proposed, our wiki was falsely accused of copyright violation and deleted (of course we used a Special:Export/Import correctly, and just imported articles that were about to be deleted from Wikipedia), and the staff would not even agree to export the data. And the email I sent to SRE was also ignored.. :( --クールトレイン７７７ (talk) 15:30, 18 September 2022 (UTC)

Comments (3.2)

 * 1) This proposal seems to be seated on the idea that mirrors serve no purpose, which is false, however, the argument that Miraheze should not get into mirroring is reasonable, but different. Thoughts? Naleksuh (talk) 07:13, 15 September 2022 (UTC)
 * 2)   from what I'm starting to understand about forks, the difference between a fork and a mirror is not about maintaining accessibility to content but rather about the changing the direction of how the content is to be presented and shared.  A mirror allows one to access the content from a different site when the original site is not available.  A fork is a copy of content from another site, where new portions may be introduced while certain old portions may be removed.  Thus, that the new site is not a mirror but rather it is a site with an identity that is distinct and separate from the site that was copied.  The original and the fork may appear similar but upon closer inspection, more than likely they will have different agendas and those differences will become greater as time passes. Imamy (talk) 02:57, 22 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)
 * 10)  CrazySpruiker2001 (talk) 12:28, 13 September 2022 (UTC)
 * 11) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 12) ZeusDeeGoose (talk) 13:41, 13 September 2022 (UTC)
 * 13)  Per Agent's support TigerBlazer (talk) 15:10, 13 September 2022 (UTC)
 * 14)  Universal Omega (talk) 17:17, 13 September 2022 (UTC)
 * 15) Per all the votes above. Dragonite (talk) 17:24, 13 September 2022 (UTC)
 * 16) Even though I (ironically) run an anarchy wiki, this policy should be helpful to keep order. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 17) NutrientEK (talk) 18:15, 13 September 2022 (UTC)
 * 18) Cough cough, Polcompball Anarchy Wiki anyone? Cough cough --DarkMatterMan4500 (talk) (contribs) 19:22, 13 September 2022 (UTC)
 * Polcompball Anarchy wouldn't necessarily be affected by such a proposal. The "Anarchy" in their name implies that anything not allowed on the main Polcompball Wiki is allowed on there, thus, 'anarchy' in a certain sense. Since they do have local administrators, I wouldn't dee them violating this policy. Agent Isai  Talk to me! 19:32, 13 September 2022 (UTC)
 * 1)  Xena   (talk)  20:33, 13 September 2022 (UTC)
 * Honestly, stuff like reception wikis should fall under this, due to them having a long history of causing drama, along with ruining this wiki farm's reputation. GyrineZ (talk) 21:54, 13 September 2022 (UTC) Whoops, wrong section. GyrineZ (talk) 21:57, 13 September 2022 (UTC)
 * 1) Rules require enforcers. Ungoverned wikis are liabilities.--SchizoidNightmares (talk) 22:51, 13 September 2022 (UTC)
 * 2) People need to trust enforcers more than unenforceable people. Unenforceable wikis are like playgrounds that aren't good at all. Spencers (talk) 23:18, 13 September 2022 (UTC)
 * 3) Related to my comment in proposal 1. --Hispano76 (talk) 23:36, 13 September 2022 (UTC)
 * 4) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 5) Maybe if it violates the Content Policy enough --Afunhumaninter (talk) 03:02, 14 September 2022 (UTC)
 * 6) Imamy (talk) 06:31, 14 September 2022 (UTC) Number 25
 * 7) Reasonable. Marxo Grouch  (talk) 16:43, 14 September 2022 (UTC)
 * 8) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 9) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 10)  For wikis, anarchy just makes no sense. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (4)

 * 1) Adding this feature would take down the Polcompball Anarchy Wiki, which would feel pretty baaaaaad for Miraheze. Addycakesball (talk) 21:06, 13 September 2022 (EST)
 * It would not. This targets wikis which have no leadership, not PCBA (which has mods, their name just means that they accept anything PCB doesn't). Agent Isai  Talk to me! 01:21, 14 September 2022 (UTC)
 * 1)  This is poorly phrased enough to be misinterpreted as a political statement.  I had no idea what anarchy system was before I read the definition in the second line.  I would phrase the rule using a positive voice, like this instead:
 * Miraheze requires all wikis to have administrators who are empowered to enforce global rules
 * You cannot have an "anarchy system" managing your wiki, with no administrators or rules. Miraheze requires each wiki have at least one person (and preferably more) responsible for that wiki, helping to enforce the rules in this policy.

Comments (4)
would suggest rewording to "free-for-all," "lawless," or "ungoverned" instead of "anarchy," to avoid conflation with the political philosophy Gifted9 (talk) 00:42, 14 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)
 * 11) ZeusDeeGoose (talk) 11:06, 13 September 2022 (UTC)
 * 12) Absolutely needed. This will help put an end to the Qualitipedia wikis. ShawnTehLogoBoi (talk) 12:22, 13 September 2022 (UTC)
 * 13) Wholeheartedly. Toxic communities like the Qualitipedia community have really damaged the reputation of the wiki farm (given the example I listed applies to the QP network). Marxo Grouch  (talk) 12:49, 13 September 2022 (UTC)
 * 14) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 15) No objections TigerBlazer (talk) 14:59, 13 September 2022 (UTC)
 * All of what was said in this proposal applies to QP, which is why I made this RfC to close them. They ruined Miraheze's reputation, and if this proposal passes, then that means that Miraheze will hopefully become a nice and quiet place once more and its reputation is restored. --Blazikeye535 (talk) 15:07, 13 September 2022 (UTC)
 * 1) I started Crappy and Awesome Games which began Qualitipedia and I've grown to deeply regret it with how toxic the community has become.  This nightmare must end. ElementalHeroes (talk) 15:25, 13 September 2022 (UTC)ElementalHeroes
 * 2) Universal Omega (talk) 17:18, 13 September 2022 (UTC)
 * 3) Per all the votes above, no objections from me, because as a long time contributor of Qualitipedia for nearly 2 years already, I can already see that toxicity is a problem, so this may help keep Miraheze a calm wiki-hosting site. Dragonite (talk) 17:24, 13 September 2022 (UTC)
 * 4) This is a reasonable policy that'll prevent another Outcast Network. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 5) NutrientEK (talk) 18:17, 13 September 2022 (UTC)
 * 6) Unfortunately, it is very common, so obviously, I'm casting my 100% strongest support here. --DarkMatterMan4500 (talk) (contribs) 19:26, 13 September 2022 (UTC)
 * 7) This is a priority for Miraheze to crackdown. The Reception Wikis is by far the quintessential example of the problem. It's not the only one of course but regardless, this is a must for Miraheze to restore its reputation. Portrock1566 (talk) 20:22, 13 September 2022 (UTC)
 * 8)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:36, 13 September 2022 (UTC)
 * 9)  DuchessTheSponge (talk) 21:14, 13 September 2022 (UTC)
 * 10) This issue is by far the main reason why Miraheze is considered not as good as Fandom. Tamagotchifan35 (talk) 21:24, 13 September 2022 (UTC)
 * 11) every so often someone tries to make another encyclopedia dramatica or whatever. having a rule that prevents it from being done here is only a good thing (also i hope i did this right this is my first time contributing to one of these votey thingies) ~ (this is chantolove i dont know why my signature isnt working im not very good at wiki)
 * 12) Honestly, reception wikis should be banned altogether for this reason alone, due to them having a long history of causing drama, along with ruining this wiki farm's reputation. GyrineZ (talk) 21:57, 13 September 2022 (UTC)
 * 13) It is not too much to ask that editors show basic respect to each other and the subjects their wikis cover.--SchizoidNightmares (talk) 23:02, 13 September 2022 (UTC)
 * 14) Toxic behavior should be totally banned. Spencers (talk) 23:19, 13 September 2022 (UTC)
 * 15) Related to my comment in proposal 1. --Hispano76 (talk) 23:37, 13 September 2022 (UTC)
 * 16) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 17) Good idea! Addycakesball (talk) 21:06, 13 September 2022 (EST)
 * 18) Imamy (talk) 06:33, 14 September 2022 (UTC)
 * 19) Don't see why not. [Also, stop applying this to QP when it says "where local administrators have ignored/enabled/done little to stop this". QP as a whole has put a somewhat decent hold on toxicity within their community and frankly it's not as bad as people make it out to be. Now, given it's attracted bad press for Miraheze if it would be affected by this policy then go ahead and close it on that basis, but if your only reason to support this is b/c 'reception wikis bad shut them down' then you really need to come up with a better argument. If this section comes off as misinformed/innacurate/uncivil let me know on my talk page and I will cross this out/remediate it in some way.] War Incarnate (talk) 20:59, 14 September 2022 (UTC)
 * 20) --   Joseph  TB  CT  CA   20:55, 15 September 2022 (UTC)
 * 21) LGTM :+1: --Labster (talk) 03:55, 18 September 2022 (UTC)
 * 22) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 23) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 24)  Toxic wikis should be closed immediately. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (5)

 * 1) - "toxic" content is an incredibly vaguely defined criterion that runs against free speech as something purely subjective. Ban ad hominem attacks, but not personal opinions others may consider "toxic". --Biomaster (talk) 15:49, 13 September 2022 (UTC)
 * "Toxic" would not include personal opinions. As long as you're respectful, personal opinions are perfectly fine. As stated in the proposal, it would encompass clear cut cases such as "repeated personal attacks, harassment of users, 'doxxing', hate speech," etc. Stewards would interpret this very strictly. Agent Isai  Talk to me! 15:55, 13 September 2022 (UTC)
 * Indeed, the proposal lists what things would qualify as 'toxic'. Wikis will not be closed lightly because of this provision, it mentions that the entire community has to be toxic for it to apply and defined what toxic means. Reception123 (talk) ( C ) 16:22, 13 September 2022 (UTC)
 * On second thought, a toxic community should be dealt with using blocks and demotions if the staff are involved. FatBurn0000 (sandbox | CentralAuth) 20:11, 13 September 2022 (UTC)
 * Stewards do not have the power to demote local staff if a community becomes toxic. We do not have any basis in policy to do that. This clause would let us intervene in toxic communities. Agent Isai  Talk to me! 20:41, 13 September 2022 (UTC)
 * 1) I'm guessing that this proposal is to avoid another Kiwi Farms situation, but policies, especially ones like these that are intended to be for sanctions, need to be unambiguous, clear, and well-formed. Permit and prohibit certain things. "Toxic" is none of them. This proposal uses a weasel word as well. to be characterized as toxic w:template:by whom? This can also lead to abusive manipulation of policy, for example, the Dmehus edit warring incident. Naleksuh (talk) 07:09, 15 September 2022 (UTC)
 * In terms of it not being vague that was attempted by providing examples of what would be toxic. As for the argument about manipulation this once again isn't a policy issue, it's a Steward trust issue. I don't think it's possible or desired to have the most strictly worded policies just because one Steward may have overstepped. If Stewards are not trusted there are ways to hold them to account and even remove them, but that doesn't mean policies need to be extremely strict and Stewards should have no discretion. Reception123 (talk) ( C ) 08:33, 15 September 2022 (UTC)
 * 1) "Toxic" is a vague word. Ban doxxing and specific things, as it stands it could be interpreted as "behaviour I don't like". Instead of trying to come up with a list of all assholery people may engage in, perhaps it'd be best to assume this coverd by the clause on not causing problems for other wikis and hateful content? Zap (talk) 07:13, 16 September 2022 (UTC)

Comments (5)

 * 1) To, , , , , , and  Why would this proposal apply to Qualitipedia? The proposal says this applies to places with repeated personal attacks, harassment, doxing, hate speech, etc. Qualitipedia does not have those things. FatBurn0000 (sandbox | CentralAuth) 20:33, 13 September 2022 (UTC)
 * 2) I'm struggling with characterizing the community of a project as that project's content here. This area feels more like a scenario where perhaps it is sufficiently covered by the Code of Conduct and should be enforced regarding behavior on the individual user basis. Deleting wikis which do not have any local activity or leadership also makes sense in this context (e.g. if every user on a project were TS banned or otherwise sanctioned). I'm just not so sure community matters belong in the Content Policy, nor am I sure it is appropriate to sanction/discard the entire project if there may be users able to clean it up.  dross  (t • c • g) 08:22, 16 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. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">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)
 * 10)  CrazySpruiker2001 (talk) 12:29, 13 September 2022 (UTC)
 * 11)  Yes, it's illegal, so we need to ban it! Am0ngU$ (talk)
 * 12) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 13) Definitely TigerBlazer (talk) 15:13, 13 September 2022 (UTC)
 * 14)  Definitely 100% Universal Omega (talk) 17:19, 13 September 2022 (UTC)
 * 15) Definitely. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 16)  NutrientEK (talk) 18:17, 13 September 2022 (UTC)
 * 17)  It's so obvious why I casted my strongest support. Child pornography is so sickening, and should be reported to Trust & Safety as soon as it becomes transparent. --DarkMatterMan4500 (talk) (contribs) 19:28, 13 September 2022 (UTC)
 * 18)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:40, 13 September 2022 (UTC)
 * 19)  NSFW involving minors (including teens 13-17) should be baned as it's a crime in most contries. Tamagotchifan35 (talk) 22:42, 13 September 2022 (UTC)
 * 20)  Sexual material must not be conducted by minors (especially me when I'm 16 years old). It hurts the wiki, especially pornographic content. These topics and/or images should be banned and users should be banned for those types of infos. Minors should not be looking at sex at the first place, especially because it's against the law in many countries, such as the United Kingdom and South Africa, and wikis are no different in cases like these. Therefore, I agree entirely and people should spread the word out loud. Spencers (talk) 23:12, 13 September 2022 (UTC)
 * 21)  Sexualization of minors is unacceptable.--SchizoidNightmares (talk) 23:19, 13 September 2022 (UTC)
 * 22) Definitely and self-explanatory. Dragonite (talk) 23:56, 13 September 2022 (UTC)
 * 23) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 24) Sexualizing minors is unacceptable. Addycakesball (talk) 21:07, 13 September 2022 (EST)
 * 25) This is a no-brainer. No way should we have stuff like this on the wiki farm. <span style="background:linear-gradient(90deg,crimson,indigo, #ADD8E6); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">Marxo Grouch  (talk) 16:46, 14 September 2022 (UTC)
 * 26) Imamy (talk) 00:31, 15 September 2022 (UTC)
 * 27) --   Joseph  TB  CT  CA   20:58, 15 September 2022 (UTC)
 * 28) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 29) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 30)  In no way shape or form should Miraheze be hosting content that depicts minors in a sexual manner. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (6)

 * 1) If I'm going to be the only voice against this proposal, then so be it. I would overwhelmingly support a ban on sexual depictions of real-life minors, but I do not support using this as an excuse to police fiction. As a victim of abuse myself, I (and many others like me) use fiction and artistic expression as an outlet to process, explore, and assert power over our traumas. (Not all victims of abuse do this, mind you, but certainly more do than you might expect.) No harm is being done to real-life minors through these fictional depictions, especially in cases of private wikis intended to be read only by the author themselves—such as my own, where such content is admittedly only a minor element. But I understand this proposal was put forward to prevent harm toward Miraheze's public image in the face of a world where such expressions are increasingly taboo, so if you believe hurting people like me is worth that goal, then I will gladly take my work and go elsewhere. As it stands, the current wording of this proposal is something I cannot support. Luca Trulyworth (talk) 19:56, 13 September 2022 (UTC)
 * Is the fiction you're talking about meant to be transgressive art? Nabokov's Lolita being the most famous example, I suppose. Then it kind of sounds like my question regarding taboo subjects. However, the border between transgression and pornography is very thin, and w/ same Lolita, people tend to interpret it differently. KatozzKita (talk) 12:06, 14 September 2022 (UTC)
 * I would argue no such line exists at all. Erotica is art, and peoples' interpretations are a private matter. There's no way of determining whether someone is consuming it for trauma reasons or otherwise unless they say so upfront—which takes a lot of bravery—or someone asks them directly—which is very rude. From a harm-reduction perspective, the best way is to have an absolute ban on content that requires the abuse of a real life child to produce—such as actual child pornography/CSEM—and a system of properly tagging content that contains such themes otherwise. Luca Trulyworth (talk) 16:41, 14 September 2022 (UTC)
 * 1) I can't support it when includes fiction. Fiction is harmless. HornyLikeIAmA14YearOldGirl (talk) 00:12, 14 September 2022 (UTC)
 * I'm pretty sure that type of content is taboo in the UK (where Miraheze is hosted). ZeusDeeGoose (talk) 01:01, 14 September 2022 (UTC)
 * Taboo does not mean illegal. There are many sites with sexual depictions of fictional minors that are not banned in the UK. Luca Trulyworth (talk) 01:25, 14 September 2022 (UTC)
 * Alright then, I rephrase my statement. I'm pretty sure that content is illegal in the UK (where Miraheze is posted). Also, not being illegal doesn't make said content good. ZeusDeeGoose (talk) 11:07, 14 September 2022 (UTC)
 * As I and one other have mentioned downthread, it is not illegal in the UK, as there are several sites available in the UK, where Miraheze is posted, where such content is openly available. Archive of our Own is one, Pixiv (a for-profit site at that!) is another. Also as I've mentioned downthread, there are plenty of "good reasons" for people to make or consume such content—such as abuse victims (like myself) using it to explore and take power over their own traumas. Luca Trulyworth (talk) 16:34, 14 September 2022 (UTC)
 * That's not the point. They are talking about real-life images of sex, not fictional characters. Fictional characters are different in the context of using it appropriately. Also, read this to find the law of sexual material with minors in the United Kingdom here. Spencers (talk) 21:00, 14 September 2022 (UTC)
 * Yes, and if you read the thread, no one here is proposing that pictures of real life CSEM should be permitted. Not one. If this proposal will allow fictional characters "in the context of using it appropriately", and only targets real life CSEM, it should say so explicitly in the proposal itself. But the proposal specifically says: "Content includes written content, real images and animated or fictional images", which is the part that everyone in opposition takes issue with. Luca Trulyworth (talk) 21:16, 14 September 2022 (UTC)
 * No, I meant fictional. AFAIK that content is not permitted in the UK. If the opposite is true, feel free to tell me. ZeusDeeGoose (talk) 22:35, 14 September 2022 (UTC)
 * Besides the fact I mentioned before that there are multiple public facing sites that openly have such content that are not blocked in the UK, the link shared above doesn't seem to have anything relating to fictional depictions, if I'm reading it correctly. Luca Trulyworth (talk) 23:00, 14 September 2022 (UTC)
 * 1) I have no problems with removing real-life child porn and obviously photorealistic depictions thereof, but I disagree with the blanket ban on fictional depictions. --GentlemensDame883 (talk) 05:12, 14 September 2022 (UTC)
 * 2) This should not apply to fictional characters, as it would show an inability to differenciate fiction from reality. GyrineZ (talk) 19:20, 14 September 2022 (UTC)
 * 3) I'm for a ban of material that is actually exploitative/abusive of real people, but strongly against encroachment on fictional content. It would not do to ban all hentai that somebody deems too young-looking. Especially against this proposal as it seems mostly moralisticly motivated. Miraheze is not beholden to advertisers or the like, so let us not ban unnecessary things just because people don't like it. Zap (talk) 07:10, 16 September 2022 (UTC)
 * 4) If this one passes, All The Tropes will certainly have to leave Miraheze.  This far outstrips legal obligations, and prohibits discussion of widely known anime like Neon Genesis Evangelion and Revolutionary Girl Utena.  And some famous books, too.  The founding of the wiki was to avoid issues like this in legitimate literary criticism, and because of our history it feels like this policy is a prelude to introducing advertising on every wiki.  I only marked it weak-oppose because we're already thinking of leaving over the constant 502 and 503 errors which we all experience for a few minutes every day.  --Labster (talk) 04:15, 18 September 2022 (UTC)
 * ATT not not be in violation of this clause at all. This clause targets "wikis of a sexual nature" and All The Tropes is not a wiki of sexual nature, it is a wiki that discusses tropes. Agent Isai  Talk to me! 04:21, 18 September 2022 (UTC)
 * This proposal was made as a response to criticism and concerns we got from many users regarding certain wikis whose main topic is sexual and involves minors, as well as even some that claimed they were going to report us to the authorities even though the content on those wikis was not judged to be illegal per se. This proposal is not intended to affect wikis such as ATT who discuss tropes at all and if you believe it is I would be open to an amendment to clarify that it isn't, as that was always the position and I never even imagined it would affect ATT. About advertising I can assure you that that is definitely not the case and that if it was introduced I would very likely leave the project myself. Finally I know the 502 and 503 issues are very frustrating (and they are for us too). With the Swift migration we hope to put them behind us but the SRE team has also been working hard in the meantime to try to address the issue from other angles as well. Reception123 (talk) ( C ) 07:14, 18 September 2022 (UTC)

Abstain (6)

 * 1) While I'm agree that clearly minor sexual (aka classified as hentai) should be banned, those are very obscure / unclear shouldn't fall into this category Max20091 (talk) 03:13, 14 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)
 * 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)
 * 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)
 * 1) It's worth reiterating that this proposal would go beyond what is currently banned in the UK, which is where the servers are hosted. Sites like Archive of our Own are fully accessable in the UK despite having such content. Besides, we shouldn't be making policy according to what is legal or illegal in "most countries", since (for example) LGBT content still counts under the latter. Luca Trulyworth (talk) 23:19, 13 September 2022 (UTC)
 * Fictional content should not be included here. Rando111 (talk) 01:58, 14 September 2022 (UTC) Vote stricken out as this account was created after this RfC was made, in violation of the Requests for Comment Policy.  Agent Isai  Talk to me! 21:42, 14 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. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">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)
 * 8)  CrazySpruiker2001 (talk) 12:21, 13 September 2022 (UTC)
 * 9) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 10) No objections whatsoever TigerBlazer (talk) 15:15, 13 September 2022 (UTC)
 * 11)  Definitely 100% Universal Omega (talk) 17:19, 13 September 2022 (UTC)
 * 12) per above. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 13)  NutrientEK (talk) 18:18, 13 September 2022 (UTC)
 * 14)  Per my obvious statement (s) above. --DarkMatterMan4500 (talk) (contribs) 19:30, 13 September 2022 (UTC)
 * 15)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:42, 13 September 2022 (UTC)
 * 16)  why not add this to the one above (chantolove still cant make signatures work)
 * 17)  See my reason in section 5.1 Tamagotchifan35 (talk) 22:42, 13 September 2022 (UTC)
 * 18)  This will enable greater action against the sexualization of minors.--SchizoidNightmares (talk) 23:23, 13 September 2022 (UTC)
 * 19) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 20) Agreed with SchizoidNightmares again. Addycakesball (talk) 21:08, 13 September 2022 (EST)
 * 21) Per my vote in Proposal 6. <span style="background:linear-gradient(90deg,crimson,indigo, #ADD8E6); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">Marxo Grouch  (talk) 16:47, 14 September 2022 (UTC)
 * 22) Imamy (talk) 00:35, 15 September 2022 (UTC)
 * 23) --   Joseph  TB  CT  CA   20:58, 15 September 2022 (UTC)
 * 24) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 25) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 26)  Per above. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (6.1)

 * 1) See above. Luca Trulyworth (talk) 19:58, 13 September 2022 (UTC)
 * 2) I find very concerning that written, animated/fictional material is included. This causes no harm to anyone, I can't support it HornyLikeIAmA14YearOldGirl (talk) 23:02, 13 September 2022 (UTC)
 * 3) As per above. --GentlemensDame883 (talk) 05:16, 14 September 2022 (UTC)
 * 4) Per above. GyrineZ (talk) 19:24, 14 September 2022 (UTC)

Comments (6.1)

 * 1)  per above. — Preceding unsigned comment added by Rando111 (User talk:Rando111 • Special:Contributions/Rando111)   Vote moved to comments and striked out as this voter is ineligible to vote per the Requests for Comment Policy.  Agent Isai  Talk to me! 21:45, 14 September 2022 (UTC)
 * 2) I'm not clear what the aim of this section is, and why it is separate from section 6. Is this to specially include not inherently sexual/explicit material that can still be seen as such? If so, it should probably clarify that. Also, I'm strongly against the inclusion of purely fictional material, as stated above. Zap (talk) 07:10, 16 September 2022 (UTC)
 * As I understand, it's because of one notorious case w/ a wiki called "live action shows children feet" (I think that was the full title), which was constant source of reports and questions (there is no way to think that the subject is not concerning, clearly), and therefore being a problem for Mirahezs's reputation. It was hanging there because formally it wasn't violating policies and/or laws, but recently finally got shut down because of reputation/problems for wiki farm rationale. KatozzKita (talk) 07:48, 16 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)
 * [Changed to just "support"] Have to say that DeeM28 has a good point re: third rule. Also wondering about such applications re: Proposal 3 (my comment, question about vague wording). KatozzKita (talk) 11:58, 13 September 2022 (UTC)
 * 1) Bertie (talk) 08:07, 13 September 2022 (UTC)
 * 2) Not on Main page - yes. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 09:25, 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)  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)
 * Regarding your first point, it may be possible users have ended up accidentally on the wiki while surfing the web, I know it's happened to me before on Miraheze and it's been especially embarrassing when I'm in a somewhat public setting. Regarding the second point, we don't want to put too much burden on wiki administrators and I understand it might not always be possible to collapse an image such as perhaps in an inflexible infobox or such so where it's not possible to do so, we don't want to be too demanding and force wiki admins to go through too many hurdles to accomplish enforcement of point 3. Agent Isai  Talk to me! 14:56, 13 September 2022 (UTC)
 * 1)  Same as above…--Executive2 (talk) 10:32, 13 September 2022 (UTC)
 * 2)  Yes. There are many minors browsing this. Am0ngU$ (talk)
 * 3) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 4) ZeusDeeGoose (talk) 13:44, 13 September 2022 (UTC)
 * 5)  Definitely 100% agree. This should be made an official rule. Universal Omega (talk) 17:21, 13 September 2022 (UTC)
 * 6) I agree with the first two points, but number 3 should be removed or at least altered, as it seems redundant and just extra work for everybody. Admins and editors have to do more work to hide explicit images, and viewers who actually want to view them will now have to make another click for each image. I get that someone may accidentally stumble upon it, but the sitenotice and rule against NSFW on the main page should be enough. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 7)  I don't agree with #3. If the viewer has landed on a page containing NSFW content via the main page, there was warning given. Any other method of accessing those pages leaves the viewer at fault. Most search engines have basic NSFW filter options. NutrientEK (talk) 18:26, 13 September 2022 (UTC)
 * 8)  #1 and #2. I am neutral toward #3.Luca Trulyworth (talk) 20:18, 13 September 2022 (UTC)
 * 9)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:47, 13 September 2022 (UTC)
 * 10)  In my honest opinion, as much as I am against NSFW, there should be at least a warining if you want it to be on the wiki. Tamagotchifan35 (talk) 22:42, 13 September 2022 (UTC)
 * 11)  too much sexual material causes problems. Spencers (talk) 23:23, 13 September 2022 (UTC)
 * 12)  A modest requirement for consent.--SchizoidNightmares (talk) 23:51, 13 September 2022 (UTC)
 * 13) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 14) Addycakesball (talk) 21:08, 13 September 2022 (EST)
 * 15) I don't know much about this NSFW.  My first time crossing this terminology.  Personal preference, I do feel that having point 2 (not appropriate for under 18) pop up is helpful.  That alone indicates NSFW.  I don't know where the 2 concepts overlap or diverge (NSFW versus not appropriate for under 18).  I like the idea but don't see it easy to implement the popup/notifications.  As someone who does visit some sites where notifications pop up a lot, pop ups can get on the viewer's nerves. I'm in support however I do hope that a lot of support is offered to those sites that need to make the transition.  Imamy (talk) 01:30, 15 September 2022 (UTC)
 * 16) This is totally necessary. --   Joseph  TB  CT  CA   21:01, 15 September 2022 (UTC)
 * 17) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 18) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 19)  Same as above, Miraheze isn't the place for this type of stuff. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (7)

 * 1)  Disagree with point 3. We should let the admins decide based on their own situations. It shouldn't be mandatory. --Revival (talk) 14:42, 13 September 2022 (UTC)
 * This is already the standard on many wikis, this would just codify such standard. Agent Isai  Talk to me! 14:56, 13 September 2022 (UTC)
 * While point 3 is a good suggestion, it shouldn't be mandatory and make it as a rule. Mandatory means it must be done. Admin discretion is prohibited. --Revival (talk) 15:42, 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. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">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)
 * 7)  Same as with NSFW Wikis in general. Am0ngU$ (talk)
 * 8) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 9) ZeusDeeGoose (talk) 13:45, 13 September 2022 (UTC)
 * 10)  Definitely 100% agree. Universal Omega (talk) 17:21, 13 September 2022 (UTC)
 * 11) Users who don't want to see that stuff shouldn't have to. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 12)  Essentially the same as my feelings on 7. Although, we get to choose our own subdomain, name, language, and category. Couldn't we choose to mark the wiki as NSFW in some way? That way people who are searching from within Miraheze can choose to filter those wikis out, or the other way around. NutrientEK (talk) 18:34, 13 September 2022 (UTC)
 * 13)  Now I don't mind NSFW related content, but that stuff should stay off of Miraheze, and obviously, child pornography is so immorally wrong and illegal. --DarkMatterMan4500 (talk) (contribs) 19:33, 13 September 2022 (UTC)
 * 14)  Fair enough. Luca Trulyworth (talk) 20:12, 13 September 2022 (UTC)
 * 15)  Agreed for sure. <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:49, 13 September 2022 (UTC)
 * 16)  I trust the judgement of Miraheze in determining violations of this.--SchizoidNightmares (talk) 23:52, 13 September 2022 (UTC)
 * 17) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 18)  Strongly agree with Miraheze on this issue right now! Addycakesball (talk) 21:09, 13 September 2022 (EST)
 * 19) This makes sense to me. Rando111 (talk) 02:07, 14 September 2022 (UTC)
 * 20) We don't need sexually explicit sitenames on Miraheze. --Afunhumaninter (talk) 03:03, 14 September 2022 (UTC)
 * 21) site names don't have to be sexually explicit in order for websites to be successful.  Also, when a site name sounds inappropriate, the NSFW indicators would be apparent.  However, the name alone would evade the standards previously mentioned to regulate NSFW.  It makes no sense to monitor NSFW content and then go on to ignore the name.  Imamy (talk) 01:45, 15 September 2022 (UTC)
 * 22) --   Joseph  TB  CT  CA   21:02, 15 September 2022 (UTC)
 * 23) --クールトレイン７７７ (talk) 17:21, 18 September 2022 (UTC)
 * 24) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 25)  Same as above. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (7.1)

 * 1)  Any corporate policy which feels like it needs to mention "sexual fluid" (outside of medicine) is automatically a failure.  Seriously, this is a first impression page to new users, and it leaves the user with the impression that all sorts of sexual content is a rampant problem on Miraheze.   The justification for this change is specifically that it causes difficulties for users of other wikis (via CentralAuth) -- which is already forbidden.  This is an entirely unnecessary policy, and the fact it was written at all shows that this entire policy reform was poorly thought through.  Most of these policy changes are responses to specific problems, but instead of using the wide statutory authority written into the first content policy I wrote for Miraheze, Stewards have chosen to interpret it narrowly which has led to a whole bunch of problems.  This is simply the worst idea of all of them.  Adding more rules will actually restrict Steward authority more; I'm sure someone will argue that breasts are not a sexual organ and because of this rule, you will have to have that debate about a theoretical bighonkintits.miraheze.org.  I am not objecting to the content of this rule, just that it absolutely did not need to be written, and if adopted will reduce the prestige of the wiki farm and the ability to for Stewards to moderate it.  --Labster (talk) 10:36, 14 September 2022 (UTC)
 * Indeed, Stewards do interpret the Content Policy very narrowly. Many people do not like us interpreting it too liberally or even invoking that clause—they're against Steward discretion as a whole in many cases. The "difficult for other wikis" clause has never been invoked other than twice, both in the span of the last 2 months, per what I can see on Special:Log/managewiki. It has become a trend to interpret the Content Policy more and more strictly and to not allow for much flexibility. Agent Isai  Talk to me! 12:30, 14 September 2022 (UTC)
 * It probably doesn't make a huge difference but I would point out that this section wouldn't technically be in the main body of the Content Policy. Otherwise I would fully agree with you that it would have been preferable to leave the section out completely only the issue is that when Stewards attempt to use the 'causes difficulties for users' section we are told that we're being too liberal, that there's no basis in policy and that it's not actually causing serious issues for people. It's regrettable that Stewards (who are elected by the community) aren't trusted more with their discretion but this modified Content Policy is a response to that unfortunate reality. --Reception123 (talk) ( C ) 17:41, 14 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. Hate speech and speech which promotes violence or hatred against protected groups are already prohibited by British law so this clause would only formally prohibit what is already prohibited by law and extend such protection to a few other groups. This clause is enforced in a de facto manner already by Stewards, generally under the Code of Conduct or invoking the law, but this would formally prohibit such content.

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. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">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)
 * 10)  We need it because it will ban racism while not interfering with criticism. Am0ngU$ (talk)
 * 11) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 12)  ZeusDeeGoose (talk) 13:45, 13 September 2022 (UTC)
 * 13)  No objections TigerBlazer (talk) 15:00, 13 September 2022 (UTC)
 * 14)  Universal Omega (talk) 17:22, 13 September 2022 (UTC)
 * 15) This is just common sense. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 16)  NutrientEK (talk) 18:36, 13 September 2022 (UTC)
 * 17)  It's that simple. --DarkMatterMan4500 (talk) (contribs) 19:34, 13 September 2022 (UTC)
 * 18)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:50, 13 September 2022 (UTC)
 * 19)  Why can't we ask for simple peace and no violence? We need to do that. Spencers (talk) 23:10, 13 September 2022 (UTC)
 * 20) Related to my comment in proposal 1. --Hispano76 (talk) 23:38, 13 September 2022 (UTC)
 * 21)  Per all the votes above, no objections from me either. Dragonite (talk) 23:56, 13 September 2022 (UTC)
 * 22)  Regulation of hateful conduct is difficult since definitions of what constitutes hate can vary significantly. I trust that Miraheze can handle enforcing this with respect to diversity of ideas and fiction. I do not see any evidence to the contrary. Ultimately, being a platform for hateful conduct is an unnecessary liability for Miraheze.--SchizoidNightmares (talk) 00:09, 14 September 2022 (UTC)
 * 23) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 24) I'm all for free speech but, when it comes to publishing, it's good to have feedback.  Sometimes, by having this rule allows one to get a more honest and well intentioned feedback.  If the publisher does not mean to post what may appear to others as hateful content that can also potentially escalate into something one never intended, this can only improve the site's content.  There is always more than one way to express something and I think aspiring to better quality of work will ultimately be more rewarding.  Imamy (talk) 01:58, 15 September 2022 (UTC)
 * 25) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 26) Though I am somewhat concerned about possible vagueness in the definition of 'hate speech' --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 27)  I'd support this + global ban for any and all users that actively and intentionally engage in said hateful conduct. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (8)

 * 1) - Too vague and might cause problems in explaining controversial topics. JonahF2014 (talk) 16:33, 13 September 2022 (UTC)
 * Not all. As explained in the proposal itself, "This section does not affect or prohibit criticism or critical commentary." This will only apply to clear cases of hateful content. Agent Isai  Talk to me! 16:55, 13 September 2022 (UTC)
 * As the person in the comment explained, not at all. "Hate speech" is inherently vague & subjective and does not account for irony/satire or any other nuance. Introducing, or rather tightening, such rules is a huge step in the wrong direction and towards censorship in my opinion. JonahF2014 (talk) 21:38, 13 September 2022 (UTC)
 * As with the Content Policy's "Unsubstantiated insult" clause, humor would rather obviously be exempted. Do note that under the Code of Conduct and under applicable British laws, this is already a de facto standard and most types of "hate speech," as defined by law, are already prohibited so this clause not passing would not impact our enforcement of the Code of Conduct and law. Agent Isai  Talk to me! 22:04, 13 September 2022 (UTC)
 * If it's already covered by the status quo as is (aka the "nothing against British law" policy) I don't see the reason for including it separately, and as per above, especially not expanding it. JonahF2014 (talk) 16:15, 14 September 2022 (UTC)
 * 1) - This sounds like it could be abused quite easily.  BeryAb (talk) 16:36, 13 September 2022 (UTC)
 * That is not likely the case. All of Stewards' actions on wiki closures are publicly logged at Special:Log/managewiki. As explained in the proposal, this would apply to clear cases of this, not criticism, or commentary. Agent Isai  Talk to me! 16:55, 13 September 2022 (UTC)
 * 1) Addycakesball (talk) 21:10, 13 September 2022 (EST)
 * 2) - I feel like 'hate speech' is such a slippery slope that can be used to justify banning anything or anyone based on their political views; for instance, people who do not buy into gender fluid ideology are often accused of 'hate speech'. How would the Polcompball community be affected by this, particularly the self-insert section? Can you guarantee that this would only be the types of speech John Stuart Mill thinks should be banned, i.e, defamation and incitement towards violence? Arctofire (talk) 03:10, 14 September 2022 (UTC)
 * This proposal's main focus is indeed the types of hate you listed (i.e. open defamation, incitement to violence). PCB self-inserts wouldn't be affected as long as their opinions are respectful (as is the current standard). If someone doesn't support something like LGBT ideologies, as long as their opinions don't invite violence, they should be fine. Agent Isai  Talk to me! 02:26, 14 September 2022 (UTC)

Comments (8)

 * 1)  humor stories like "How to burn witches at the stake" (wikis like Uncyclopedia have hundreds of these) will technically be against the letter of this rule. This may/will be used by trolls that target humor wikis. Edward Chernenko (talk) 18:09, 13 September 2022 (UTC)
 * Not necessarily. This policy seeks more to combat outright hate which incites potential real life harm rather than humorous stories. As with the Content Policy's 'Unsubstantiated insult' clause, where the content is designed to be humour and not true hate, these wikis wouldn't engage in any policy violations. Agent Isai  Talk to me! 18:14, 13 September 2022 (UTC)
 * (edit conflict) They would not be as it clearly says that it only applies to "promotion of violence, hatred, or harassment" and mentions specific groups. Since witches are fictional it would not apply. In addition, there is always Steward discretion and Stewards would not close a humor wiki for this, we have no interest in doing so. That being said, the opposite is also true where users attempt to hide behind "humor" or "satire" to claim that they aren't violating the Content Policy. Reception123 (talk) ( C ) 18:17, 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. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">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)
 * 9) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 10) ZeusDeeGoose (talk) 13:46, 13 September 2022 (UTC)
 * 11)  Universal Omega (talk) 17:24, 13 September 2022 (UTC)
 * 12) Misinformation is a big problem in today's world, and it needs to be stopped. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 13)  Oh I'd be on their asses if I saw something that doesn't seem right. (Yes, I'm expressing my anger on deceptive wiki requests, given that a locked user has attempted to do this less than a week ago under a new account). --DarkMatterMan4500 (talk) (contribs) 19:43, 13 September 2022 (UTC)
 * 14)  The wording makes it clear it's about purposeful misinformation. Since it's made sure to not be abused it has my support. <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:56, 13 September 2022 (UTC)
 * 15)   antivaxxers have no place here (chantolove still cant make a signature work)
 * 16)  Spencers (talk) 23:14, 13 September 2022 (UTC)
 * 17) No objetions --Hispano76 (talk) 23:39, 13 September 2022 (UTC)
 * 18)  I think other users are misinterpreting the intent of this proposal. I trust that Miraheze will use discretion for the enforcement of this.--SchizoidNightmares (talk) 00:09, 14 September 2022 (UTC)
 * 19) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 20)  We're here for wikis and communities, not garbage.  dross  (t • c • g) 00:51, 14 September 2022 (UTC)
 * It’s hard to determine whether a information is “misleading” or not. Even with citations, it can still be “misleading” depending on stewards’ discretion. This is actually harming local wiki communities’ autonomy. Even if stewards give the community the right to debate whether it is “misleading” or not, in some more complicated cases, it will most certainly fall into a meaningless political argument (which no one is happy to see). -Cheers, Matttest (talk | contribs) 10:52, 14 September 2022 (UTC)
 * Everything you've mentioned here is entirely baseless and displays a misunderstanding of the relationship between community imposed policy and Stewards. It is, in fact, very easy to tell if information is intentionally misleading. That is the entire premise of this policy: intentionality. The line between supporting a statement with citations and presenting such information lacking or outside of context is very clear, and only the latter would be relevant here. Ultimately, every single policy enacted by the community is subject to Steward discretion for application—including interpretation, exceptions, and potential out of scope applications—and to believe otherwise is misunderstanding the degree of community trust placed in our Stewards. Every user should also consider these facts when casting votes for Stewardship. dross  (t • c • g) 23:41, 14 September 2022 (UTC)
 * 1) Agreed with Dross. Addycakesball (talk) 21:10, 13 September 2022 (EST)
 * 2) I agree with Dross. Rando111 (talk) 02:05, 14 September 2022 (UTC)
 * 3) --   Joseph  TB  CT  CA   21:03, 15 September 2022 (UTC)
 * 4) Imamy (talk) 03:43, 18 September 2022 (UTC)
 * 5) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 6)  I mean this is fine in concept but the idea that a wiki is designed to "mislead" is highly tic-tac and is a judgement call. For this I'd propose an individual steward/committee to review since some stewards may have a COI, depending on the situation. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 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)
 * 2)  This is obviously getting into political areas which the Content Policy shouldn’t be covering. For example, when a user criticize COVID-19 vaccines as ineffective and unsafe with citations, would that be “Misleading claims on health”? Defining vague wordings like that are very difficult.  -Cheers, Matttest (talk | contribs) 11:32, 13 September 2022 (UTC)
 * Not exactly. This has more in mind stuff which puts people in immediate harm. Dissent such as regarding vaccinations wouldn't fall into this as it doesn't put people in immediate harm. Agent Isai  Talk to me! 13:24, 13 September 2022 (UTC)
 * 1)  That's dumb doing these rules, this is too political. Am0ngU$ (talk)
 * 2)  This policy is too vague and may lead to abuse. For example, closing a wiki which covers highly controversial topics due to "disinformation". --Revival (talk) 14:44, 13 September 2022 (UTC)
 * As expressed in the proposal, this would only be enforced in clear cut situations. Wikis which engage in dissent of certain viewpoints would not incur in a violation of this policy for simply voicing their opinions. For a violation of this policy to exist, there must be clear intent and purpose to deceive a person. This policy would be strictly interpreted if it were added to the Content Policy. Because wiki closures are publicly logged, users would see when we invoke this section of the Content Policy and may dispute a closure. Additionally, per Proposal 12 and 15, wikis would be given ample time to correct any issues or contest our findings. Generally, Stewards like to first warn a wiki of violations and any wiki found to be in violation of Proposal 9 would be warned first and not outright closed. Even if a wiki were closed (made private) for more severe violations of policy, generally, Stewards grant them a timeframe of at least a month to contest the findings or download their data and so users who believe a wiki has been closed in error are free to contest such closure. I don't believe this clause will lead to abuse, Stewards actions are always public and very rarely can we do an action which isn't logged in the public log or Recent Changes, which includes wiki closures. Agent Isai  Talk to me! 15:07, 13 September 2022 (UTC)
 * 1) - Way too vague, gives a lot of potential for abuse, and might punish unintentional improper research, lack of public information, or conflicting sources; this is something for the wiki mods to decide, not the platform. JonahF2014 (talk) 16:38, 13 September 2022 (UTC)
 * 2) - Like the eighth proposal, a policy as vague as this one could be subject to easy abuse by content moderators, and could also lead to confusion among affected communities.  BeryAb (talk) 16:45, 13 September 2022 (UTC)
 * 3) - Again, just like #8, it can lead to biased judgement and censorship. MedicsChaotics (talk) 16:54, 13 September 2022 (UTC)
 * 4)  Who decides what information is false? What if the information is false now, but true later? Is something false because the viewer doesn't agree? Maybe it's false because the opposite is more kind. No thanks.  Stay far away from this one. Too political. Too vague. NutrientEK (talk) 18:46, 13 September 2022 (UTC)
 * 5) - As a member of the Polcompball Anarchy Wiki, I personally don't support this proposal. It can lead to a slippery slope where Miraheze could just target anything that doesn't agree with a specified political agenda. If people want to think the Earth is flat, let them go ahead. Wikis that discuss controversial issues and alternative facts would be threatened by this proposal. And also who would decide what misinformation is and what it's not? Would the CDC or Mercola decide? These are the questions that would arise if this were put into place. --Afunhumaninter (talk) 02:48, 14 September 2022 (UTC)
 * This wiki targets wikis whose sole purpose is to try and trick others. If a wiki wants to talk about a subject and their members are all people who are in agreement with it then this wouldn't affect them. Now, if the wiki only purpose was to make false claims that target certain people and it has the very clear intent to deceive and defraud a user, then that's where this would kick in. Otherwise, wikis which talk about fringe topics should be fine. The latter clause of misinformation that threatens health would focus on claims that put your life in immediate danger (e.g. wrong info that tells you to mix two medications that could potentially kill you), not things like dissent regarding vaccines and such. Stewards are committed to interpreting this policy strictly and not liberally so as to suppress others viewpoints. As noted above, all actions regarding things like wiki closures and such are publicly logged at Special:Log/managewiki so users would see clearly when we invoke the policy and would have ample opportunity to contest a closure. I don't know if you know but community consensus can often times override Steward decisions so if the entire community believes a closure was incorrect, it may be overturned and a clarification can be issued by the community in a community discussion. Agent Isai  Talk to me! 03:09, 14 September 2022 (UTC)
 * That’s where the problem exists. When a steward issued a closure/deletion for a wiki for this purpose (e.g. if links to complicated political matters), even the one of the users tries to contest the closure, it will turn into a meaningless political argument in the community. I still believe the wordings used is vague and it’s hard to tell whether it is “misinformation” or not. Stewards can be always changed (e.g. if users retire; or new users want to be part of the team), but the policy is not. Once codified, it cannot be changed easily. Different stewards can have different interpretation to this policy - which is the problem here. -Cheers, Matttest (talk | contribs) 10:46, 14 September 2022 (UTC)

Abstain (9)

 * 1) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)

Comments (9)

 * 1) I'm noticing that nearly all of the oppose positions on this proposal have misinterpreted what is being proposed. It should be recognized that the "sole purpose" clause protects participants on Miraheze wiki projects. An entire wiki created for the publication of explicitly and intentionally false information is far different than a wiki being penalized or deplatformed for publishing potentially dubious information as part of its content. Nearly every oppose has characterized the position of this policy to be that any wiki page covering a contentious topic puts the entire wiki at risk when that is simply not true. It's pretty apparent under "sole purpose" that the entire wiki would need to be filled with absolute garbage to be actioned under such a policy.  dross  (t • c • g) 00:50, 14 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, and w/o credits. 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. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:39, 13 September 2022 (UTC)
 * 6) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 7) ZeusDeeGoose (talk) 13:47, 13 September 2022 (UTC)
 * 8) --Revival (talk) 14:45, 13 September 2022 (UTC)
 * 9) TigerBlazer (talk) 15:31, 13 September 2022 (UTC)
 * 10)  Universal Omega (talk) 17:25, 13 September 2022 (UTC)
 * 11) The point of a wiki is to be edited, not to store images that won't be used in any meaningful context. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 12)  NutrientEK (talk) 18:47, 13 September 2022 (UTC)
 * 13)  Pretty obvious here. --DarkMatterMan4500 (talk) (contribs) 20:21, 13 September 2022 (UTC)
 * 14)  Makes perfect sense. <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  20:58, 13 September 2022 (UTC)
 * 15)  Can't hurt to support this. Spencers (talk) 23:22, 13 September 2022 (UTC)
 * 16) Dragonite (talk) 23:56, 13 September 2022 (UTC)
 * 17)  Enforcing this may help reduce bandwidth usage. Files on a wiki should only exist if they are being used on the wiki for an on-wiki purpose.--SchizoidNightmares (talk) 00:11, 14 September 2022 (UTC)
 * 18) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 19)  Limited services means, well, limited services.  dross  (t • c • g) 00:53, 14 September 2022 (UTC)
 * 20)  Addycakesball (talk) 21:10, 13 September 2022 (EST)
 * 21)  per other users' reasonings. Rando111 (talk) 02:02, 14 September 2022 (UTC)
 * 22)  Wikis should have some pages in them and not just files. --Afunhumaninter (talk) 02:51, 14 September 2022 (UTC)
 * 23)  --   Joseph  TB  CT  CA   21:05, 15 September 2022 (UTC)
 * 24)  I don't fully understand file hosting/file sharing as described.  However, if the decision is to investigate and curb extreme practices in order to lessen the impact or toll on resources funded by donations then I am in support of it simply because Miraheze is a free wiki host.  File sharing as I understand it can take a heavy toll on the network when a file is hot.  Imamy (talk) 04:09, 18 September 2022 (UTC)
 * 25) Yes, Miraheze is a wiki farm, not a file server.--クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 26) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 27)  Again, tic-tac and judgement call. But for now this can be supported by me as I trust the current roster of stewards. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (10)

 * 1) All wikis are file sharing services. HTML files are files. As for specific problems with misuse of the File namespace for a web hosting, that's a different problem, and the proposal would need to be changed to clarify what it does and does not cover, and what will and will not be allowed. Naleksuh (talk) 07:10, 15 September 2022 (UTC)
 * I think it's quite clear what this proposal seeks to ban, by files we of course mean things anything that is uploaded to the wiki separately from written content. I don't think it would be possible for anyone to get the impression that this bans wiki. Reception123 (talk) ( C ) 08:35, 15 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. --<span style="background:linear-gradient(90deg,#283cbd,#9030b0);-webkit-background-clip:text!important;-webkit-text-fill-color:transparent;">Soukupmi  (talk) (✔) 10:47, 13 September 2022 (UTC)
 * 9) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 10) ZeusDeeGoose (talk) 13:48, 13 September 2022 (UTC)
 * 11)  Per above. Universal Omega (talk) 17:26, 13 September 2022 (UTC)
 * 12) per above. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 13)  NutrientEK (talk) 19:00, 13 September 2022 (UTC)
 * 14)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  21:01, 13 September 2022 (UTC)
 * 15)  Per above. Spencers (talk) 23:22, 13 September 2022 (UTC)
 * 16) per above. --Hispano76 (talk) 23:44, 13 September 2022 (UTC)
 * 17) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 18) Addycakesball (talk) 21:11, 13 September 2022 (EST)
 * 19)  A necessary policy in case of exceptional circumstances.--SchizoidNightmares (talk) 01:29, 14 September 2022 (UTC)
 * 20)  If a wiki's team is like, really incompetent, then it's okay for global staff to intervene in moderation tasks. --Afunhumaninter (talk) 02:54, 14 September 2022 (UTC)
 * 21)  While I don't have a problem with this, I don't think it should be a "policy" per se. It could just be something any steward/gs or even any trusted/capable volunteer can be involved in. Well explained though, but yeah, that's my take. --   Joseph  TB  CT  CA   21:12, 15 September 2022 (UTC)
 * 22) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 23) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 24)  I'd support this with the amendment that an independent user be selected to act as conservator, instead of a global sysop or steward. Sort of like the concept of a special master, in that the conservator would not be a user affiliated with current global leadership, but instead an everyday user that is competent and trusted to perform the task of content arbitration. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 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. --<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)
 * 7) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 8)  Per above. Universal Omega (talk) 17:26, 13 September 2022 (UTC)
 * 9) per above. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 10)  NutrientEK (talk) 19:02, 13 September 2022 (UTC)
 * 11)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  21:02, 13 September 2022 (UTC)
 * 12) No objetions. --Hispano76 (talk) 23:44, 13 September 2022 (UTC)
 * 13) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 14) Addycakesball (talk) 21:11, 13 September 2022 (EST)
 * 15)  This is a power that stewards should certainly be able to exercise when necessary.--SchizoidNightmares (talk) 01:31, 14 September 2022 (UTC)
 * 16) Of course --Afunhumaninter (talk) 03:04, 14 September 2022 (UTC)
 * 17) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 18) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 19)  This is fine but I'd say this only be decided upon by the conservator, again an everyday user, not a steward. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)
 * 1)  This is fine but I'd say this only be decided upon by the conservator, again an everyday user, not a steward. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 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)
 * 11) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 12) ZeusDeeGoose (talk) 13:50, 13 September 2022 (UTC)
 * 13)  Universal Omega (talk) 17:27, 13 September 2022 (UTC)
 * 14) Now wikis won't be closed for one page that violates the policy. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * I'll just note that as far as I'm aware that has never happened and would be quite absurd. This just seeks to clarify the position, it doesn't change the status quo as this is always how things have operated. Reception123 (talk) ( C ) 18:11, 13 September 2022 (UTC)
 * 1)  It's a good thing to clarify this. <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  21:04, 13 September 2022 (UTC)
 * 2)  Per Tali64³. Spencers (talk) 23:21, 13 September 2022 (UTC)
 * 3) Related to my comment in proposal 1. --Hispano76 (talk) 23:45, 13 September 2022 (UTC)
 * 4) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 5) Addycakesball (talk) 21:12, 13 September 2022 (EST)
 * 6)  Seems a little redundant to have, but if it is felt it is necessary to clarify, then alright.--SchizoidNightmares (talk) 01:38, 14 September 2022 (UTC)
 * 7) I agree with this. For example, a page or two on a wiki would not be counted against the wiki if they are eliminated. If they aren't eliminated, global admins can step in and delete the page, and ensure further violations are not made. In wiki-wide violations where the local admins do not do anything, then global admins should have a say and should be able to intervene at any time.
 * 8)  --   Joseph  TB  CT  CA   21:14, 15 September 2022 (UTC)
 * 9) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 10) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 11)  This seems to be nothing more than a definition, as such I support. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 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)
 * 7) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 8) ZeusDeeGoose (talk) 13:52, 13 September 2022 (UTC)
 * 9) Fair enough, should help prevent problems before they are created. TigerBlazer (talk) 15:32, 13 September 2022 (UTC)
 * 10)  Universal Omega (talk) 17:27, 13 September 2022 (UTC)
 * 11)  NutrientEK (talk) 19:05, 13 September 2022 (UTC)
 * 12)  Just imagine a scenario where one user would request a wiki where they milk someone's death, or a wiki where they poke fun of someone's death. Now that would be a blatant and/or flagrant violation of the Content Policies, and I stand strongly with my strong support vote. --DarkMatterMan4500 (talk) (contribs) 20:38, 13 September 2022 (UTC)
 * 13)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  21:08, 13 September 2022 (UTC)
 * 14)  Spencers (talk) 23:20, 13 September 2022 (UTC)
 * 15) Related to my comment in proposal 1. With an addition. I have fallen into the trap of some "users" who say that the wiki will deal with one topic (example: Soccer) but it turns out that in the end it is another. --Hispano76 (talk) 23:48, 13 September 2022 (UTC)
 * 16) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 17) Addycakesball (talk) 21:12, 13 September 2022 (EST)
 * 18)  This is repeated in the first proposal, albeit with less clarity. May want to merge this into an existing rule in the future. However, since experience has shown that more clarity may be needed, maybe it needs it.--SchizoidNightmares (talk) 01:44, 14 September 2022 (UTC)
 * 19) I see no issue in enforcing this. It will serve to prevent problematic wikis from starting. <span style="background:linear-gradient(90deg,crimson,indigo, #ADD8E6); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">Marxo Grouch  (talk) 16:50, 14 September 2022 (UTC)
 * 20) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 21) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 22)  No issues at all. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 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)
 * 2) per DeeM28. Tali64³ (talk) 17:57, 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)
 * You may be interested in this page. ZeusDeeGoose (talk) 13:53, 13 September 2022 (UTC)
 * Thanks a lot ;)--Executive2 (talk) 14:28, 13 September 2022 (UTC)

Comments (13)

 * 1) What's the rationale behind adding this to the CP itself?  05:30, 17 September 2022 (UTC)
 * As explained, it will not be added to the CP itself, it will be added to Wiki creators. It was just included here as it relates to the CP and it wouldn't make sense to have to have another RfC or discussion for it. Reception123 (talk) ( C ) 09:55, 17 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)
 * 8) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 9) ZeusDeeGoose (talk) 15:07, 13 September 2022 (UTC)
 * 10) No objections TigerBlazer (talk) 15:33, 13 September 2022 (UTC)
 * 11)  Universal Omega (talk) 17:28, 13 September 2022 (UTC)
 * 12) per above. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 13)  NutrientEK (talk) 19:08, 13 September 2022 (UTC)
 * 14)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  21:09, 13 September 2022 (UTC)
 * 15)  Yes, what a straightforward idea. Spencers (talk) 23:15, 13 September 2022 (UTC)
 * 16) Definitely related to my comments on proposals 1 and 13. Experience! --Hispano76 (talk) 23:50, 13 September 2022 (UTC)
 * 17) Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 18) Addycakesball (talk) 21:13, 13 September 2022 (EST)
 * 19)  Sensible (still allows for flexibility) as wiki creation requests approved for some uses would be rejected for others.--SchizoidNightmares (talk) 01:47, 14 September 2022 (UTC)
 * 20) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 21) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 22)  As far as I know this has never been an issue, but codifying it is fine by me. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Comments (14)

 * 1) I'm relatively new here- what does 'scope' refer to? Size, topic, or something else? (chantolove still cant get signatures to work) — Preceding unsigned comment added by Chantolove (User talk:Chantolove • Special:Contributions/Chantolove)
 * A scope describes what the wiki will focus on so yes, the topic basically. Agent Isai  Talk to me! 22:10, 13 September 2022 (UTC)
 * 1) Would this mean that a wiki could not be changed from private to public, or from public to private? --Robkelk (talk) 13:00, 14 September 2022 (UTC)
 * No, this proposal wouldn't stop wikis from being changed from private to public and vice versa as long as the approved scope says the same (i.e. a wiki about personal notes stays being a wiki about notes and doesn't change scope drastically). Agent Isai  Talk to me! 18:20, 18 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.
 * 8) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 9)  Universal Omega (talk) 17:28, 13 September 2022 (UTC)
 * 10)  per above. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 11)  NutrientEK (talk) 19:09, 13 September 2022 (UTC)
 * 12)  <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  21:10, 13 September 2022 (UTC)
 * 13)   related to my comments on proposals 1, 13 and 14. --Hispano76 (talk) 23:52, 13 September 2022 (UTC)
 * 14) in principle w/ wording nitpick below Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 15) Addycakesball (talk) 21:13, 13 September 2022 (EST)
 * 16)  Common sense.--SchizoidNightmares (talk) 02:31, 14 September 2022 (UTC)
 * 17) There are far too many cases of this type of abuse, whether it's the person changing their mind or simply being dishonest in a deliberate attempt to gain the system. Requesting one wiki and then making another is a form of lying. Naleksuh (talk) 07:12, 15 September 2022 (UTC)
 * 18) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 19) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 20)  But didn't wikis have to have their new scope approved by Stewards anyway per (14)? Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Comments (14.1)
wording is somewhat redundant - i'd suggest "If a wiki's scope has been radically and completely changed, Stewards will attempt to remediate the issue first, but may close the wiki if it continues to violate this policy." Gifted9 (talk) 00:42, 14 September 2022 (UTC)

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)
 * While I do agree with this, this should've been specified a bit more. --DarkMatterMan4500 (talk) (contribs) 12:43, 14 September 2022 (UTC)
 * 1) 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)
 * 2) 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)
 * 3) &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 09:42, 13 September 2022 (UTC)
 * 4)  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)
 * 5) Bertie (talk) 10:36, 13 September 2022 (UTC)
 * 6) --Executive2 (talk) 10:48, 13 September 2022 (UTC)
 * 7)  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)
 * 8) — FurryOctopi (talk) 12:59, 13 September 2022 (UTC)
 * 9) So wikis can have time to change. ZeusDeeGoose (talk) 15:13, 13 September 2022 (UTC)
 * 10)  There should be a window allowing wikis to adopt for these changes. Universal Omega (talk) 17:29, 13 September 2022 (UTC)
 * 11) It's just fair to wikis that would violate these new policies. Tali64³ (talk) 17:57, 13 September 2022 (UTC)
 * 12)  Adjusting everything that violates the content policy after it is changed will be very difficult. Especially for large wikis or wikis that are run by very few people. I support this, but as long as it's not done Youtube style. "We found a issue. You have 30 days to fix it, and we aren't going to tell you what it is. Good luck!" NutrientEK (talk) 19:15, 13 September 2022 (UTC)
 * 13)  It only makes sense that existing wikis should have more time to adjust, as they were created and edited with the old policy. <div style="display:inline-block;padding:5px;border-radius:5px;background:#e3ffc9;vertical-align:text-bottom"> Xena   (talk)  21:14, 13 September 2022 (UTC)
 * 14)  We need to allow wikis to use the time to style. Spencers (talk) 23:25, 13 September 2022 (UTC)
 * 15)  Addycakesball (talk) 21:14, 13 September 2022 (EST)
 * 16)   per above. --Hispano76 (talk) 23:52, 13 September 2022 (UTC)
 * 17) in principle - if it's standard operating procedure, wording is fine; if it'll be an actual policy clause, i'd specify exact number of days Gifted9 (talk) 00:42, 14 September 2022 (UTC)
 * 18)  Ideally there would be a transition period before the policy comes into effect for all wikis. If this would be the case if this proposal isn't passed, then I'll change my vote to oppose. Otherwise, I support it as I feel it is more fair than to have a policy come into effect immediately upon passing with little time/notice to adapt.--SchizoidNightmares (talk) 02:41, 14 September 2022 (UTC)
 * 19)  Luca Trulyworth (talk) 16:54, 14 September 2022 (UTC)
 * 20)  --   Joseph  TB  CT  CA   21:15, 15 September 2022 (UTC)
 * 21) --クールトレイン７７７ (talk) 17:09, 18 September 2022 (UTC)
 * 22) --Pmattes (talk) 22:37, 18 September 2022 (UTC)
 * 23)  Though I'd give a period of 90 days to adjust. Thanks - BrandonWM (talk • contribs • global • rights) 01:12, 19 September 2022 (UTC)

Oppose (15)

 * 1)  This sounds more like an "If it's not broke, don't fix it" type of proposal. This could only work if a wiki is actively violating either policy. But other than that, I don't see how this would effectively work. --DarkMatterMan4500 (talk) (contribs) 20:48, 13 September 2022 (UTC)