Requests for Comment/Minor Content Policy amendments


 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * This RfC is closed as follows:
 * Proposal 1: Successful.
 * Proposal 2: Successful.
 * Proposal 3: Successful.
 * Proposal 4: Successful.
 * Proposal 5: Successful.
 * John (talk) 23:25, 28 December 2022 (UTC)

While unusual to open an RfC so soon after one has closed, given the importance and size of the original Content Policy reform RfC and the comments made there, there are a few minor tweaks that we would like to apply. These don't actually change the intention of the main reform but just seek to either clarify things or make it sound more professional.

Proposal initiated by: Reception123 (talk) 15:40, 14 November 2022 (UTC)

Proposal co-initiated by: Agent Isai  Talk to me! 15:46, 14 November 2022 (UTC)

Proposal 1 (Amend 7.1)
The phrase used in Clause 7.1 is changed to:
 * Wikis may not feature subdomains or sitenames which make explicit mention of content deemed 'not safe for work', lewd, and/or obscene.

Rationale: It was pointed out that explicitly mentioning things like "sexual organs, sexual fluid, sexual acts" wasn't very appropriate for a Content Policy and just calling it "NSFW" as we do for the NSFW rules should really be enough.

Support

 * 1)  Per proposal, seems unprofessional to have that mentioned so explicitly.  Agent Isai  Talk to me! 15:46, 14 November 2022 (UTC)
 * 2)  Per Labster's initial suggestion, it's unnecessary to be so specific and it looks unprofessional and even childish. Reception123 (talk) ( C ) 16:50, 14 November 2022 (UTC)
 * 3)  Per above, no need to enumerate every possible example when a general statement has the same clarity and better coverage. --NotAracham (talk • contribs • global) 23:08, 14 November 2022 (UTC)
 * 4)  I agree with the statements above that it is not appropriate go into such unnecessary detail in this instance. --DeeM28 (talk) 06:40, 15 November 2022 (UTC)
 * 5)  Per above, simply saying NSFW is enough. --Blad  (talk • contribs • global) 14:52, 20 November 2022 (UTC)
 * 6)  No problems with this proposed change, mentioning specific things related to NSFW is unnecessary and just mentioning NSFW is enough. TF3RDL (talk &#124; contribs &#124; FANDOM &#124; Wikipedia) 17:41, 25 November 2022 (UTC)
 * 7)  Imamy (talk) 07:03, 29 November 2022 (UTC)

Oppose

 * 1) What would new people deem as NSFW? NSFW can be seen differently on a case-to-case basis and should really have definition to what is seen as NSFW to staff. What seems to be NSFW on a site that a user uses actively can (and most definitely) differs from what staff deems as NSFW, so why make it more vague? --  Bukkit  [ cetacean needed ] 23:42, 27 November 2022 (UTC)
 * We elect Stewards (not 'staff', which would be SRE and who can't enforce this policy) on the assumption that they possess good judgement and will interpret policy in a way that reflects common sense. For that reason, Stewards are elected once they have an 80% support ratio out of 20 votes. If the vote threshold to elect Stewards was of 5 votes then I'd want to document every nook and cranny of what 'NSFW' could mean as anyone could be elected Steward but that's not the case. Policy gives Stewards plenty of cases where their discretion can be exercised. Rather obviously, NSFW would be anything lewd, obscene, and the standard definition of 'not safe for work' which would be basically anything involving sexual things. You can't stretch the definition of NSFW to encompass unrelated things. Agent Isai  Talk to me! 00:20, 28 November 2022 (UTC)
 * You make a good point, it is more vague, yet it isn't. When I look at it, I feel that we are finding a better way to express the concept in a less NSFW way.  The new phrasing demonstrates a more appropriate tone.  To be honest, I have no issues with the current 7.1.  However, I do remember at the time when I was voting on the proposal that it bothered me that 7.1 proposal looked a little NSFW.  We may have trouble agreeing on what belongs in the realm of NSFW, but I like the idea of a Content Policy that doesn't sound NSFW ish only because our Miraheze population is so demographically diverse.  I may be hopeful, but in my opinion, by promoting a more compliant phrasing, we are demonstrating that we are serious about constructing an environment that SFW and NSFW can share without prejudice.  Imamy (talk) 07:46, 29 November 2022 (UTC)

Proposal 2 (Amend 6)
Clause #6 of the Content Policy is appended to read:
 * Where a wiki's scope as a whole is not of a sexual nature which involves minors, references and discussions about outside content are permitted as long as they are legal under United Kingdom law.

Rationale: A concern raised on the original RfC regarding Content Policy amendments was that the proposed clause made it seem like even passing references on an encyclopedic project about certain literature which may feature that element are prohibited. That was not the intent of this clause so this amendment reflects that.

Support

 * 1)  Per proposal.  Agent Isai  Talk to me! 15:46, 14 November 2022 (UTC)
 * 2)  per above. Reception123 (talk) ( C ) 16:50, 14 November 2022 (UTC)
 * 3)  good clarification, I support this. --NotAracham (talk • contribs • global) 23:09, 14 November 2022 (UTC)
 * 4)  Reasonable clarification. --DeeM28 (talk) 06:40, 15 November 2022 (UTC)
 * 5)  per above. --Blad  (talk • contribs • global) 14:53, 20 November 2022 (UTC)
 * 6)  per above. --  Bukkit  [ cetacean needed ] 23:44, 27 November 2022 (UTC)
 * 7)  Much needed clarification. Firestar464 (talk) 07:23, 28 November 2022 (UTC)
 * 8)  Imamy (talk) 07:53, 29 November 2022 (UTC)

Proposal 3 (Amend 11)
Added after the section on direct forks (11)
 * Wikis with the same or a substantially similar topic to another existing Miraheze wiki are prohibited.

Wikis which share the same topic or have a very similar topic to another Miraheze wiki are prohibited. If a wiki is found to be sharing the same topic, it may be closed. If you have a valid reason to make a wiki of a similar or of the same topic, contact a Steward who will evaluate your case and grant an exemption if needed. Note that this not affect wikis which focus specifically on subtopics of a bigger topic.

If a wiki in violation of this clause is slated to be closed, Stewards will provide ample notice before closing the project and will provide an XML dump of the wiki. Stewards will evaluate each wiki on a case-by-case basis and may grant exemptions where the projects both have enough substantive content to make closing impractical and unwise, along with other grounds per Steward discretion.

Rationale: It doesn't make sense to not allow direct forks but to not also prohibit wikis that are on the exact same topic. This proposal doesn't mean that wiki creators have to be aware of all wikis on Miraheze, but if they do then they obviously shouldn't create one, and additionally this new addition can be used if such an issue is discovered later. Duplicate wikis often hurt each other as they both compete on Google and everywhere else and sometimes the user base is split. We've had plenty of users complain that a similar wiki is an issue for theirs in SEO and such and so we'd like to avoid that. Creating wikis of a similar topic is actually already de facto prohibited as one of RequestWiki's canned rejection responses is one stating that a wiki was declined because it was a duplicate of another and many wiki creators thought it was already banned in the Content Policy's no forks provision.

Support

 * 1)  Duplicate wikis are already prohibited per wiki creator convention. Users often complain about duplicates anyhow so we'd like to address that. We won't be closing projects which have similar or the same topic but both have lots of substantive content but this does seek to formally prohibit the new creations of these sorts of wikis and close inactive stubs which hurt other wikis.  Agent Isai  Talk to me! 15:46, 14 November 2022 (UTC)
 * 2)  As long as wiki creators aren't forced to be aware of all wikis and exceptions are granted if necessary by Stewards this makes sense. Reception123 (talk) ( C ) 16:52, 14 November 2022 (UTC)
 * 3)  I'd like to see conditional approvals of duplicative wikis more defined in future amendments to policy.  There's enough nebulous-ness here that setting up 'reasonable guidelines' seems prudent. --NotAracham (talk • contribs • global) 23:13, 14 November 2022 (UTC)
 * 4)  I agree with NotAracham and do not appreciate that there is no clear criteria for whether wikis with the same topic are allowed as there is for forks. I support the principle but not the implementation which lacks clarity. Otherwise I share the views expressed above that wiki creators are not to be expected to know what all wikis are and also that if circumstances arise Stewards should be willing to grant exemptions as needed. --DeeM28 (talk) 06:40, 15 November 2022 (UTC)
 * 5)  Imamy (talk) 07:58, 29 November 2022 (UTC)

Oppose

 * 1) What if the user builds a wiki and are unaware that there is another wiki that has the same topic? The sheer number of wikis make it impossible for users to know if there is already another wiki similar to that, and to delete their hard work on a wiki they built on the basis that "One of our 4281 wikis have the same topic" is absolutely frustrating and disappointing. --  Bukkit  [ cetacean needed ] 23:47, 27 November 2022 (UTC)
 * "Stewards will evaluate each wiki on a case-by-case basis and may grant exemptions where the projects both have enough substantive content" - why would we close a wiki where work has been put in? Agent Isai  Talk to me! 00:05, 28 November 2022 (UTC)

Comments
DeeM28 raises a good point I had not considered. While the intent is there, this is incredibly difficult for Wiki Creators to factually police. See following: Not asking for a proposed solution as part of this RfC, but a point worth raising nonetheless. --NotAracham (talk • contribs • global) 15:27, 15 November 2022 (UTC)
 * Miraheze is now the host of nearly 5.6k wikis -- while WikiDiscover exists, the sheer volume of wikis (and lack of descriptions for most) make it challenging to use for this purpose
 * Gazetteer exists, but is opt-in and has only a handful of wikis listed compared to the global set
 * Attempts to google search are often unhelpful in finding existing wikis thanks to the SEO of reception wikis blotting out most anything in the gaming or media space.

Proposal 4 (Amend 11a)
The follow line is removed from 11a (provision prohibiting new Wikimedia forks):


 * Existing wikis which are in violation of this clause are exempted from this policy.

This means currently existing Wikimedia forks are now also prohibited and will be shutdown. Stewards will grant plenty of leeway where possible for valid use projects such as those archiving closed language editions of Wikipedia.

Rationale: This was discussed during our previous Miraheze Meeting. After an initial evaluation, most blatant Wikimedia forks which currently exist are deeply inactive, unmoderated, broken (templates are half imported and error out), unread, and some are vandalised with no one to revert that or monitor it. A few forks were also listed there and most agreed that there was no real reason to keep these sorts of forks around. As stated in the proposal, Stewards will grant exemptions to this for valid use projects such as archives of closed language editions of Wikimedia projects, things like Incubator Plus which is hosted here, and other valid use wikis.

Support

 * 1)  Per proposal. This was discussed a lot during our last Miraheze Meeting and we could not find any real reason to leave these forks open if they don't really contribute much and are just a headache overall to navigate and moderate.  Agent Isai  Talk to me! 15:46, 14 November 2022 (UTC)
 * 2)  Per rationale provided. Reception123 (talk) ( C ) 16:53, 14 November 2022 (UTC)
 * 3)  As much as some of these fork projects are loved by their contributors, this change would bring consistency in application of the various CPs.  It's odd to have a unique legacy carve-out for just MW forks, this resolves that dissonance.--NotAracham (talk • contribs • global) 23:07, 14 November 2022 (UTC)
 * 4)  The rationale is satisfactory. --DeeM28 (talk) 06:40, 15 November 2022 (UTC)

Proposal 5 (Amend 3)
Clause 3 of the Content Policy is amended to say:


 * 3. Miraheze does not host wikis which spread unsubstantiated insult, hate or rumours against a person or group of people.

Rationale: This is a minor change which replaces "Miraheze does not host wikis with the sole purpose" to "Miraheze does not host wikis which." I can't think of a single occasion where we would allow wikis to insult people, spread hate and spread rumors only if it wasn't their main focus. It's rather silly to limit ourselves to only enforcing the clause if it's the wiki's sole purpose and in practice, we enforce it even if it isn't their sole purpose because of its nature.

Support

 * 1)  Minor wording changes, no issues there.  Agent Isai  Talk to me! 15:46, 14 November 2022 (UTC)
 * 2)  Never made sense in the way its written. We don't want unsubstantiated rumours or insults on any wiki, not just ones with that primary scope. Reception123 (talk) ( C ) 16:54, 14 November 2022 (UTC)
 * 3)  While I appreciate the need to ensure that clear Satire/Parody topics are not blocked by this change, the intent of the change is clear and non-controversial in my view. --NotAracham (talk • contribs • global) 23:15, 14 November 2022 (UTC)
 * 4)  As far as I have seen this part of the Content Policy has already been interpreted in such a way and I agree that it does not make sense to keep the "sole purpose". --DeeM28 (talk) 06:40, 15 November 2022 (UTC)
 * 5)  Much needed, nuff said. Firestar464 (talk) 07:26, 28 November 2022 (UTC)

Comments

 * Note: This RfC is what added the clause. I suggest voters see the guidelines and discussion there. As the original co-drafter of this rule, I don't think the proposed change would obstruct review sites or satire. The only effective change is that any review must be placed on a true event. Satire is not unsubstantiated and the full Content Policy clearly discusses that. ~ RhinosF1 - (chat)· acc· c -  22:00, 14 November 2022 (UTC)


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