Requests for Comment/Wiki governance and local elections

It should be well known that Miraheze functions based on the principle of community consensus and that if such consensus and good arguments exist for implementing policy changes, these will be implemented. After various experiences with some wikis but also sometimes in global votes, it has become clear that some additional rules and guidelines are needed to ensure that wiki governance and local elections are fairly conducted and that the principle of community consensus is adhered to all over the farm.

For local elections, this will be achieved by largely codifying (and therefore gaining community approval for) the already existing Local elections guidelines/recommendations which have generally been well received. If approved, the first proposals will be included in a new Wiki governance and voting policy page and the ones related to Local elections will modify the current Local elections guideline and make it into a policy as updating it with some of the changes here. Thanks to Agent, Raidarr, NotAracham and BrandonWM for helping with this RfC.

Notes regarding this RfC: None of the original proposals in this RfC are mutually exclusive. If you think it is absolutely necessary to add an alternative or new proposal even after voting has commenced (which is generally not encouraged) please add it as "Proposal X Alternative X". Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)

Wiki governance and voting

Proposal 1: Wiki governance

 * Wikis are governed (or managed) by bureaucrats, administrators or any other designated group with similar functions. Wikis on Miraheze generally function by the principle of community consensus. Miraheze holds the attitude that wikis are not owned by any user, but by their community.

Bureaucrats and administrators are accountable to their community and may not take actions which are inconsistent with the community's will (for example, they must abide by written policies voted by the community). No user with advanced rights should consider themselves the sole arbiter in all things or the 'leader' of the wiki.

If bureaucrats or sysops do not respect the will of the community, Stewards may intervene and give effect to the community's wishes. Please see Stewards for more details.

Support (1)

 * 1)  This is already the status quo and our farm purpose isn't to allow single users to control a wiki which is a collaborative project. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Absolutely. It is crucial that we finally, once and for all, define this instead of relying on the status quo which is the 'undefined system of conventions and standards which varies by steward' system which is certainly counterintuitive to our users who may not know about our conventions. This is already the status quo, as Reception123 states, so this proposal is perfect as it finally codifies what is already practice which will make it easier for users and admins to know how we view wikis as it happens often on big wikis (AVID Wiki as a recent example) where bureaucrats view themselves as dictators and unilaterally defy their communities wishes. I do strongly wish that this pass so that Stewards no longer rely on just a series of conventions developed over 7 years which is certainly not something a growing project like Miraheze wants to retain moving forward.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Not only does this codify an existing standard, it also brings governance language in line with other language/practice included in our recent code of conduct and content policy overhauls.  An easy support. --NotAracham (talk • contribs • global) 00:24, 8 February 2023 (UTC)
 * 4)  This is the current status quo and this would only serve to codify practice. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:17, 8 February 2023 (UTC)
 * 6)  per Agent Isai Hb1290 (talk) 05:47, 8 February 2023 (UTC)
 * 7)  I totally support.  More fun when community comes first and a unified vocabulary will really help.  Looking forward to reading Wiki_governance_and_voting_policy  --Imamy (talk) 06:04, 8 February 2023 (UTC)
 * 8)  Codifying status quo and one of the most important principles of the farm - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 9)  A welcome codification and clarification. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
 * 10)  I have read the text and it is a very correct proposal, I support it. Best regards,  Hey Türkiye  Message? 11:54, 8 February 2023 (UTC)
 * 11)  Nothing to add that hasn't been said, but I wholeheartedly agree! Untropicalisland (talk) 16:36, 9 February 2023 (UTC)

Oppose (1)

 * 1)  While understanding that wikis hosted by Miraheze are not "owned" by individual users, it is necessary and can be highly desirable in many instances to have an autocrat rule a wiki with an iron but fair fist — fair in the sense they follow the terms of use of Miraheze and English law. I believe community consensus, unless dictated otherwise by local wiki policy, is best left non-binding. The Internet is far too vulnerable to mob rule to demand sociocracy. Even Wikipedia is only loosely determined by "consensus" and uses many obscure means of ignoring or suppressing it. --SchizoidNightmares (talk) 18:23, 8 February 2023 (UTC)
 * Ruling with an iron (but fair) fist is perfectly fine, I do so on my small wikis :P - This proposal seeks to prevent abusive bureaucrats/sysops from clearly acting against their community's wishes as has happened oh so many times in the past and even in the past year, which is already the status quo (and has been a practice for all of the farm's existence thus this passing or not passing won't really have any visible effect apart from formally documenting this). Consensus does not equal only voting though. Thoughtful arguments have to be given during discussions for and against proposals. Many internet mobs give nonsensical or weak arguments in favor or against an action. If that's the case then those arguments hold no weight and there should be no real danger to the bureaucrat. Consensus isn't a rigid procedure, it's one that allows closers for discretion in how to implement it/if to even implement depending on the circumstances. We've always allowed and will continue allowing bureaucrats discretion in some regards when consensus is nonsensical and harmful to the project. If a bureaucrat believes that consensus on something is abusive, nonsensical, or dangerous to the project, Stewards would, in accordance with our mandate to resolve local disputes, interfere to determine what is best, in accordance with global standards which have been developed over time. We obviously won't boot off a bureaucrat for a simple action that the local community doesn't like if it's the result of a literal witch hunt/a coordinated campaign by a group of users to kick them off just because (that'd be a violation of the Global Conduct Policy if anything and would BOOMERANG on the users in charge of such a campaign) Agent Isai  Talk to me! 18:55, 8 February 2023 (UTC)
 * I agree with Agent's comments here. I would also add that the various provisions in this RfC make it so that this provision is not as 'rigid' as it may seem. Reception123 (talk) ( C ) 19:06, 8 February 2023 (UTC)
 * Your comment (including the one on my other opposing comment) User:Agent Isai lessens my concerns. I have downgraded my oppositions to a lesser degree in response. --SchizoidNightmares (talk) 19:19, 8 February 2023 (UTC)

Comments (1)
Does this policy also apply to wikis that one has founded? For instance I requested and founded DKpedia and own the custom domain for it. Bawitdaba (talk) 15:40, 9 February 2023 (UTC)
 * Founders don't hold and have never held any special status on their wiki (you'll notice that there's no 'founder' permission on wikis and the highest you can go is bureaucrat by default). This proposal seeks to formally codify what has been practice for the past 7 years so that users can easily see how Stewards operate versus the current system where they only find out how things work by observing/reading what others have written about our system. If passed, there'd really be no change on most wikis as this only codifies the status quo and makes it so that we formally document it and have one unified standard that's not subject to change based on the interpretation of different Stewards. Should this fail, Stewards will retain the status quo system of unwritten conventions subject to interpretation. Is there anything in particular which you're curious about? Agent Isai  Talk to me! 15:56, 9 February 2023 (UTC)
 * No, just asking for like if someone has their own wiki brand (although that would fall under personal wikis, I'm assuming), whereas I run wikis for the Miraheze community. Bawitdaba (talk) 16:22, 9 February 2023 (UTC)
 * I'm still unsure what you're asking, but if you're concerned about losing control over the wiki you founded and own the domain for, as long as you are following basic principles (respecting consensus, not blocking users you disagree with, etc.) you are unlikely to experience any negative effects due to this proposal. Collei (talk) 16:24, 9 February 2023 (UTC)

Proposal 1.2: Actions

 * Bureaucrats, administrators or any other designated group with similar functions must not take actions that are clearly arbitrary, unfair and for which no reason is given.

Rationale: In some cases it has been observed that admins take actions against users and don't even attempt to explain why they took such action. In order to be accountable, actions taken must be explained in a transparent way.

Support (1.2)

 * 1)  This is very related to Proposal 1 but sometimes we see that administrators take actions against users and don't even provide any sort of actual justification. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Very reasonable. As stated in my support for proposal 1, it has occured before that bureaucrats take unilateral, sweeping actions against users without any real reason (i.e. on avidwiki, the bureaucrat demoted and blocked editors for nonsensical reasons/no reason).  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  One of those things you hope doesn't have to be said, but as above, there have been enough examples this needs to be codified as baseline. --NotAracham (talk • contribs • global) 00:27, 8 February 2023 (UTC)
 * 4)  Sadly, as NotAracham stated, this has to be codified. Thanks - BrandonWM (talk • contributions • global • rights)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:17, 8 February 2023 (UTC)
 * 6)  per Agent Isai, particularly given our own experience on AVID Wiki. Hb1290 (talk) 05:47, 8 February 2023 (UTC)
 * 7)  --Imamy (talk) 06:54, 8 February 2023 (UTC)
 * 8)  per BrandonWM - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 9)  We should not support wikis being ran as dictatorships. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
 * 10)  per Agent Isai, Best Regards  Hey Türkiye  Message? 11:56, 8 February 2023 (UTC)
 * 11)  Transparency's incredibly important for moderators/admins in community projects in general. This also benefits the community standards with regards to wikis' staff rotation and the inevitable departures and new arrivals by making prior precedent a lot easier to check.

Oppose (1.2)

 * 1)  Sometimes it is necessary to make what may appear as arbitrary or unexplained decisions. In the case of dealing with malicious or otherwise undesirable users, it is best to feed them as little attention as possible. Attention is almost always the motivation for that kind of activity — be it originating from boredom or poor socialization. Mandating broad transparency in action is not appropriate for all wikis. --SchizoidNightmares (talk) 18:31, 8 February 2023 (UTC)
 * I think common sense needs to be applied in the interpretation of this proposal. It (obviously I hope) doesn't refer to combating vandalism. It refers to situations where good faith users make changes and an administrator reverts them and doesn't even attempt to justify their decision, it's just because they personally didn't like that edit. Reception123 (talk) ( C ) 19:08, 8 February 2023 (UTC)

Proposal 2: Personal wikis

 * In the following situations, the principle of community consensus is not applicable and the user who requested the wiki is solely responsible for governing their wiki:
 * private personal wikis wholly or substantially about the user who filed the original request
 * public personal e-portfolio
 * curriculum vitae (résumé)
 * blog
 * other narrowly-construed wikis with a similar purpose

Support (2)

 * 1)  In these cases it doesn't make sense to rule by consensus. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Reasonable. It wouldn't make sense to have a personal wiki being run by consensus and the bureaucrat potentially being ousted somehow from a wiki about themselves.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Further RfC points touch further on edge cases to the personal wiki scenario, but this also needs to be spelled out for similar reasons to 1.2 --NotAracham (talk • contribs • global) 00:30, 8 February 2023 (UTC)
 * 4)  Current status quo, just codifying it. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:16, 8 February 2023 (UTC)
 * 6)  I agree with this list.  Also it's so easy to request a new wiki, contribute the same content to the new wiki, that if a group has enough members, it should be easier to make the new site work than try and redefine an existing one that was started by someone else.  --Imamy (talk) 06:34, 8 February 2023 (UTC)
 * 7)  Proposal 1 and these wikis co-existing would be, at least de jure, unsustainable without this proposal - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 8) Conditional  as long as the language proposed by NotAracham is added as I belive that it is more suitable than the current provision. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
 * 9)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 11:59, 8 February 2023 (UTC)
 * 10)  These exceptions, especially if generously applied in practice, may save these otherwise (respectfully) excessive interventionist proposals. --SchizoidNightmares (talk) 18:33, 8 February 2023 (UTC)

Comments (2)

 * 1) I'd also consider adding language to the effect of "The above list is a representative but non-exhaustive of things which might be considered 'personal wikis'.  Steward discretion shall be used in cases not covered by the above." --NotAracham (talk • contribs • global) 00:31, 8 February 2023 (UTC)

Proposal 2, Amendment 1
"The above list is representative but not exhaustive of all things which might be considered 'personal wikis'. Steward discretion shall be used in assessing wikis that do not fit into the stated examples." --NotAracham (talk • contribs • global) 18:04, 8 February 2023 (UTC)
 * Add language following the example list of personal wikis:
 * Intent is to clarify that we are not narrowly-defining what can be a personal wiki and leave final determination on edge cases to stewards

Support (2A1)

 * 1)  adding support as proposer --NotAracham (talk • contribs • global) 18:04, 8 February 2023 (UTC)
 * 2)  It makes sense to include this as there might be other categories that we haven't thought of. Reception123 (talk) ( C ) 19:01, 8 February 2023 (UTC)
 * 3)  Let's not be too rigid!  Agent Isai  Talk to me! 19:09, 8 February 2023 (UTC)
 * 4)  per Reception123 - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
 * 5)  Even if I cannot think of any examples that would exceed the ones here I think it is fair to be pragmatic. --DeeM28 (talk) 19:47, 8 February 2023 (UTC)
 * 6)  I support this Amendment --Imamy (talk) 23:27, 8 February 2023 (UTC)
 * 7)  This makes sense. Thanks - BrandonWM (talk • contributions • global • rights) 04:54, 9 February 2023 (UTC)

Proposal 3.1: Weighing of outside votes

 * A vote by a user who is clearly not genuinely connected to the wiki's community is to be weighed less than other votes.

This is to be interpreted narrowly. The presumption is that a user is connected to a wiki's community.

Examples of a user who is clearly not genuinely connected include but are not limited to: a user who has a very small amount of meaningful edits on the wiki, a user who very recently attached their account on a wiki, a user whose edits are clearly made in order to escape this provision.

This does not apply to Requests for Comment or global permission requests on Meta.

Rationale: If this were not the case, a large group of users from one wiki could create accounts on another and arbitrarily demote an existing bureaucrat or enact other changes even though they have nothing to do with the wiki. This proposal doesn't target "new users", it only aims to prevent users who have nothing to do with a community from being able to seriously influence its policies or which users get promoted.

Support (3.1)

 * 1)  It happens that sometimes users from one community invite users from other wikis to come vote. It doesn't seem fair that users who have no relation to the community have the same say as users who do. For a real world example, countries don't allow non-citizens to vote. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Absolutely necessary. It wouldn't make sense if an outside user can interject in a discussion just because.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Having seen outside canvassing efforts (also covered in later points) for exactly this scenario of overwhelming local consensus, I agree that clarifying language is needed to deter that kind of action. --NotAracham (talk • contribs • global) 00:34, 8 February 2023 (UTC)
 * 4)  This could be manipulated in a variety of ways, but the wording is strong enough that I can support. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 5)  I appreciate this point being made.  I feel touched and blessed to see that the quality and effort made by a contributor matters in an election.  --Imamy (talk) 07:26, 8 February 2023 (UTC)
 * 6)  per BrandonWM. I think the wording could be better, but I agree on principle. If nothing else I believe we'll be forced to change it sooner or later once a would-be canvasser stirs up enough outrage inside their community based on the vague wording. - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  The principle behind this proposal is something I agree with and think it is perfectly normal to not give the same weight to users who have no connection with the community as users who have been there and work on the wiki. No it is not creating 'inferior people' because as Reception123 pointed out usefully it is customary for all countries around the world to only allow people who are genuinkly connected to those countries (i.e. by citizenship) to take part in elections or referendums. If this were not the case it is easy to imagine people inviting foreign citizens to come and vote. A full ban in this case is not possible as there is no clear dividing line between people connected to a wiki and people not connected. I understand that it is hard to have a clear figure but I am a little concerned about the wording and vagueness of the proposal and would be open to supporting an amendment that is more clear. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
 * 8)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)
 * 9)  The wiki I edit has this built into our policy with formal time since joining/edit quantities requirements, so I support this in principle, but I do think this is a case-by-case situation. I also have left a wiki on a different hosting platform because admins were particularly harsh on new users (among other things); recent arrivals can have valid concerns. Untropicalisland (talk) 16:41, 9 February 2023 (UTC)

Oppose (3.1)

 * 1) This makes no sense and is also impossible. Firstly, what does it mean to be "weighed" less? If this is some sort of poll, what is the multiplier for these "inferior people"? But if polling is not a substitute for discussion, then all of the strength is inherently from the content, and there's no way that the person who wrote it could be "weighed less". Naleksuh (talk) 04:54, 8 February 2023 (UTC)
 * You started an RfC recently on the usage of Wikipedia policies, please keep in mind that polling not being a substitute for discussion isn't necessarily a Miraheze-wide rule right now. Collei (talk) 05:02, 8 February 2023 (UTC)
 * Could you highly where exactly I said it's a Miraheze-wide rule? It seems like I clearly wrote "if", and that it was nothing more than a thought. Naleksuh (talk) 05:04, 8 February 2023 (UTC)
 * The idea is, as explained, that it wouldn't be fair for users who have nothing to do with a community to significantly influence a vote, as someone who fits in this category would be highly unlikely to even understand the community well enough. Without this proposal, what would stop someone from getting 20 friends to create accounts and take over another wiki by ousting the administrators and bureaucrats? As for the weight, it would basically mean that when closing, if most votes come from users in this category, the proposal could not be considered successful. Wikis are free to develop more specific criteria if they wish. Reception123 (talk) ( C ) 06:17, 8 February 2023 (UTC)
 * has more than one meaning, I may have interpreted your use incorrectly: https://simple.wiktionary.org/wiki/if. Collei (talk) 16:28, 8 February 2023 (UTC)

Abstain (3.1)

 * 1)  As BrandonWM has said, this might be too vague or open to abuse. I'm unsure how to go about "correctly" codifying this in a way that won't open up the possibility for abuse. Collei (talk) 04:18, 8 February 2023 (UTC)

Amendment 1 to Proposal 3.1
The following is added to Proposal 3.1: An example of what 'weighed less' is a situation where a permission request or a proposal passing depends on the votes of users who are clearly not genuinely connected to the wiki's community. In that case the proposal would not pass because it depends on those votes and without those votes there would not be a majority. An example where 'weighed less' would apply is a permission request or a proposal in which the supporting majority are overwhelmingly user accounts which joined in the last few hours, while long-time community members are uniformly opposed. Despite majority support, the proposal/permission request would be unsuccessful because the majority clearly does not represent the established community.

Support (A1 3.1)

 * 1)  I do not claim that this amendment is the best possible option but I think it is necessary to provide clarity to users regarding what 3.1 means. --DeeM28 (talk) 10:40, 8 February 2023 (UTC)
 * 2)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)
 * 3)  While there's probably a better way to get the intended outcome, this is acceptable.  alternate language with minor edits for clarity supplied in comments, feel free to take or leave. --NotAracham (talk • contribs • global) 18:15, 8 February 2023 (UTC)
 * 4)  Support with alternate language provided by NotAracham. Reception123 (talk) ( C ) 19:02, 8 February 2023 (UTC)
 * 5)  conditional on alternate language suggested by NotAracham be used - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
 * 6)  As the original proposer I find the modifications made by NotAracham reasonable and accept them as the new version. I acknowledge that I have modified the amendment without Hey Türkiye's formal approval but given the fact that their vote has been a blanket support accross this RfC and the fact that everyone else in the proposal supports the version proposed by NotAracham I think this should be exceptionally permissible. --DeeM28 (talk) 19:50, 8 February 2023 (UTC)       (added indent because otherwise there will be 2 votes from Dee for A1 3.1) --Imamy (talk) 07:05, 9 February 2023 (UTC)
 * 7)  I support this amendment. --Imamy (talk) 00:16, 9 February 2023 (UTC)
 * 8)  This is a good idea. Thanks - BrandonWM (talk • contributions • global • rights) 05:00, 9 February 2023 (UTC)

Comments (A1 3.1)

 * 1) Proposed alternate language: An example where 'weighed less' would apply is a permission request or a proposal in which the supporting majority are overwhelmingly user accounts which joined in the last few hours, while long-time community members are uniformly opposed. Despite majority support, the proposal/permission request would be unsuccessful because the majority clearly does not represent the established community.

Proposal 3.2: Tight-knit communities
Whether a wiki falls under this category will be determined by a Steward by reference to its purpose or description and all the circumstances. A wiki which was initially part of this category may evolve and no longer be considered a "tight-knit" community at a later time.
 * If a wiki focuses on a niche topic, has a small number of active users and can be characterized as a 'tight-knit community', votes by users part of the group may be weighed more than others.

Rationale: This is similar to 3.1 but only would also cover cases when there's a small community but then new users join (and contribute enough to not be caught by 3.1) and attempt to change the wiki's direction. In such cases, it would be fair to allow the original community to govern themselves.

Support (3.2)

 * 1)  Similarly to 3.1, it doesn't seem fair from outside users to come and disrupt the functioning of a smaller community with its own rules and conventions. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Reasonable. Wouldn't make sense to allow outsiders to take over a wiki.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Similar to Proposal 2, and I support because tight-knit communities shouldn't have their wiki governance ability stripped from them. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Common sense, codifies the discretion Stewards already have at their disposal to prevent 'raids' on other wikis. --NotAracham (talk • contribs • global) 02:58, 8 February 2023 (UTC)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:18, 8 February 2023 (UTC) see my comments in the oppose section, temporarily weak oppose until some issues are worked out. Collei (talk) 16:30, 8 February 2023 (UTC)
 * 6)   --Imamy (talk) 08:03, 8 February 2023 (UTC)
 * 7)  Support the principle with concerns about vagueness and likely confusion it could cause to some users. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
 * 8)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Oppose (3.2)

 * 1)  per CaptainOfTheTidesBreath comment. While we might personally know the intent of the policy, I think the layman reading of it is very different and is doomed to cause legitimate arguments born out of confusion down the line. If changes are made to make it obvious that this is intended to protect inherently niche topics (like those noted in Agent Isai's comment) rather than e.g. publically-available media that just so happened to be unpopular at the time of wiki creation, I would support this proposal. - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 2)  until these mentioned issues are worked out. We need a very clear specification of what we plan to implement until implementing it can be ready to be voted on (or maybe !voted upon, depending on what standard you wish to follow). Collei (talk) 16:29, 8 February 2023 (UTC)

Comments (3.2)

 * Is it possible to better define what sorts of "niche topics" would fall under this? I've had previous experience (on other platforms) with poorly managed wikis per their reputation in the wider communities with small editing communities run by tight knit groups, and it felt constantly like an unspoken version of this was wielded to prevent any amount of meaningful change for the betterment of the wiki as proposed by newer editors. I would not have personally considered those wikis as for niche topics, but my experience compels me to ask for at least some clarification on how a Steward would make this determination. —CaptainOfTheTidesBreath (aye, captain!) 06:10, 8 February 2023 (UTC)
 * This clause has in mind wikis with topics such as private DnD campaign wikis, small wikis documenting a Discord server for example, etc. The wiki you describe would likely not be shielded by this clause on Miraheze as this clause mainly intends to shield small wikis where it doesn't make sense to have users rule by consensus (i.e. wikis about a small gaming group and such). Agent Isai  Talk to me! 06:23, 8 February 2023 (UTC)
 * https://www.grammarly.com/blog/know-your-latin-i-e-vs-e-g/ Collei (talk) 16:32, 8 February 2023 (UTC)
 * I think it is important to recognize and honor "niche topics".
 * These niche users took the time and put in the effort to request a wiki that they can develop to meet their community's needs. If a new group were to come in, then they basically have dodged the whole process of having their request vetted by the the wiki host.  Since they have not submitted their own request or it has been denied for incompleteness, by usurping an established group's wiki is basically finding a way to get a site without wiki host approval.  Rather than working on submitting a legitimate request, they find it easier to take someone else's. --Imamy (talk) 00:56, 9 February 2023 (UTC)

Proposal 3.2, Amendment 1

 * Add the following clause to cover corporations/other organized entities using our service:

Corporations or Organizations with clear structures and membership outside of the wiki community documenting that organization shall be construed as falling into 'tight-knit/niche' community status regardless of userbase size. All other behavioral standards of leadership apply and this special status may be revoked at steward discretion

--NotAracham (talk • contribs • global) 18:33, 8 February 2023 (UTC)
 * This change avoids outside hijacking of wikis created by members of an organization to document that organization.

Support (3.2 A1)

 * 1)  as proposer --NotAracham (talk • contribs • global) 18:33, 8 February 2023 (UTC)
 * 2)  It's necessary to incorporate companies/organisations as well. Reception123 (talk) ( C ) 19:03, 8 February 2023 (UTC)
 * 3)  Straightforward.  Agent Isai  Talk to me! 19:10, 8 February 2023 (UTC)
 * 4)  as this will help solve some of the gaps in the definition of tight-knight community - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
 * 5)  While this may not be ideal it is simply a reality that companies and/or other associations will use Miraheze and we cannot expect them to be subject to users not affiliated with their project to control them. --DeeM28 (talk) 19:52, 8 February 2023 (UTC)
 * 6)  --Imamy (talk) 01:24, 9 February 2023 (UTC)
 * 7)  Yes. Thanks - BrandonWM (talk • contributions • global • rights) 05:01, 9 February 2023 (UTC)

Proposal 3.3: Canvassing or solicitation of votes

 * Privately asking multiple users to support a permissions request is not allowed. [1]
 * Asking a large number of users who are not affiliated or genuinely connected to the wiki's community to vote in any request is not allowed.
 * Promising an advantage or preferential treatment in exchange for a support vote is not allowed.

[1] Generally asking users to vote in a neutral manner is not covered, but should ideally be done publicly (i.e. not via private message)

Support (3.3)

 * 1)  This is quite obviously something we don't want to have. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Very reasonable. A canvassing guideline is definitely needed. We already, by convention, prohibit canvassing but formalizing this prohibition on the practice is very important to have a policy standing to do so.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Obviously. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Yes.  Converts an already-observed (and necessary) best practice into official policy. --NotAracham (talk • contribs • global) 03:00, 8 February 2023 (UTC)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:19, 8 February 2023 (UTC)
 * 6)   --Imamy (talk) 08:28, 8 February 2023 (UTC)
 * 7)  per Agent Isai - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 8)  Even though in real life "canvassing" is certainly possible in elections there are other rules that govern transparency and the dynamics are very different to a on-wiki project. Therefore I am willing to support this as it is easy to ask users who are less familiar with Miraheze or who are more suspcebtile to help one "win" an election. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
 * 9)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Proposal 4: Policies

 * All wikis are governed by Global policies and any local policies or practices that violate global policies are not allowed. This includes local policies that adopt lower standards than ones contained in global policies.


 * In most cases, local administrators and bureaucrats are responsible for ensuring that global policies are being respected on their wikis. Stewards and, in some cases other global groups, are also responsible to ensure that global policies are being respected across Miraheze.


 * This policy imposes certain minimum standards but wikis are encouraged to develop their own policies and may provide higher standards than those contained in this policy.

Rationale: This doesn't change the status quo it just codifies it.

Support (4)

 * 1)  Codifies the status quo. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Status quo already so no harm in codifying it.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Codifying status quo. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Global governance policy has always been treated as and should be a baseline to build upon, not optional and to be ignored as wanted. This codifies that understanding. --NotAracham (talk • contribs • global) 03:04, 8 February 2023 (UTC)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:20, 8 February 2023 (UTC)
 * 6)  per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  A useful codification. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
 * 8)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)
 * 9)  --Imamy (talk) 01:40, 9 February 2023 (UTC)

Comments (4)
Local elections

Proposal 5: Definition and scope
A local election is a process on a wiki where a user self-nominates or is nominated to hold specific permissions, such as administrator and/or bureaucrat. They are governed by local policies (if they exist) and typically overseen by local bureaucrats. If neither applies, a Steward may be brought in to oversee the election and assess its results based on global policies, conventions, best practices and case-by-case discretion.

Wikis are recommended to develop their own election process and related policies, and have them ratified by the community by way of vote.

Restricted local groups such as CheckUser, local Interwiki administrators and Oversight require filling specific requirements set globally, outlined on their respective pages.

This policy only applies to the election of users in specific roles (i.e. it does not apply to voting on policies).

Support (5)

 * 1)  Makes sense to have a default for local elections if local policies don't exist. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Reasonable definition of what an election is.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Local elections are always a strong idea. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Minor definitional and scope changes (see comments) that mesh well with the rest of these policy points. --NotAracham (talk • contribs • global) 03:12, 8 February 2023 (UTC)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:21, 8 February 2023 (UTC)
 * 6)  per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  Useful to codify. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 8)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)
 * 9)  --Imamy (talk) 16:57, 9 February 2023 (UTC)

Comments (5)
As this is near 1:1 with existing definition page for Local elections, an update on what's changed: --NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)
 * 1) Minor formatting cleanups
 * 2) Clarifying that local election process/policy should be ratified with a community vote
 * 3) Clarifying that local checkuser/IW Admin/oversight permissions require candidate to meet globally-set minimum requirements
 * 4) Clarifying that the policy document for local elections should not be construed as applying to votes on local policy (e.g. Local RfCs)

Proposal 6: Elections on wikis with inactive bureaucrats
The following conditions apply to such elections (private wikis are dealt with separately):
 * If a wiki's bureaucrats have been absent for some time and there is nobody to assess local decisions, provide direction, use ManageWiki or enforce global policies (such as the Content Policy and the Code of Conduct and no policies are developed locally to cover this scenario, the community must set up a local election. The following sections assume there is no local governance to supervise and that the election will be 'called' by a Steward.
 * The nominee should be an existing contributor, locally active or at least have an edit history, even if it is built after the election starts.
 * The nominee should have a clear and specific idea of what they wish to do with the rights. A general or vague will to 'improve the wiki' will not suffice.
 * If present, the existing community should be supportive. [IF PROPOSAL 3.1 passes: In accordance with the weighing of outside votes rule, votes by users who are not genuinely connected to the wiki's community will be weighed less]. Third parties (such as an existing linked discord server) may also be considered, but on-wiki accounts with edit history will be given more weight
 * The proceedings should be as transparent as possible - further details are in the process section.

Support (6)

 * 1)  Per the current local election guidelines. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Already the status quo.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  I believe this is the current status quo, and serves to codify. As a result, support. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  overall minor edits + incorporation of other key proposals, this has my support. --NotAracham (talk • contribs • global) 03:20, 8 February 2023 (UTC)
 * 5)  Indeed a good idea, same as others. Collei (talk) 04:21, 8 February 2023 (UTC)
 * 6)  This was a major issue for us prior to our leadership change on AVID. It's good to see a proper proceedure for this codified at last. Hb1290 (talk) 05:47, 8 February 2023 (UTC)
 * 7)  per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 8)  This is a sound procedure. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 9)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)
 * 10)  --Imamy (talk) 17:01, 9 February 2023 (UTC)

Comments (6)
As this is near 1:1 with existing definition page for Local elections, an update on what's changed: --NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)
 * 1) Minor formatting cleanups
 * 2) Added clause with supporting language that global policy is minimum and must be enforced with local elections
 * 3) Added clause clarifying that the community MUST host a local election in the case of absent leadership
 * 4) Updated clause clarifying that the following conditions MUST be applied, and moved disclaimer about private wiki handling to same line
 * 5) Clarified that nominee should have both clear AND specific goals on how they will guide the wiki if approved
 * 6) Added clarifying language that incorporates policy 3.1 rules (if approved) on outside voters not genuinely connected to the wiki
 * 7) Clarified that wiki-specific third-party communities (e.g. discord servers) are valid as additional consideration for elections.

Proposal 7: Appointment on wikis with no community
If there is no existing community or an extremely small one, a user may be temporarily appointed by a Steward to a position provided that they demonstrate a need and clearly indicate their intentions. An 'appointment' is not to be equivalent to an 'election'.

Support (7)

 * 1)  It's quite absurd to hold 'elections' when there's no one to vote in them, so it makes sense to have this temporarily until a community exists. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  I've been wanting to implement something like this for a while now. It makes no sense to have users 'win' an election by acclamation on wikis with no users. Holding an election on a wiki with no users is a bit too much bureaucracy as you go the extra mile just for no one to vote and for you to win by acclamation. A temporary appointment makes more sense as they can be renewed on a need basis from the bureaucrat and once the wiki is large enough, a community can actually fully promote a bureaucrat/sysop.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  It would be stupid to do anything but. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Considering that this exact scenario has come up three times in the last week, current policy mandating elections on wikis with zero active users is a waste of steward time.  While this approach would normally give me pause, as those community members have recourse should a dead community revive itself, I don't have a problem with temporary appointments instead of holding an election with no voters. --NotAracham (talk • contribs • global) 03:23, 8 February 2023 (UTC)
 * 5)  Yeah, honestly, we're requiring people to run "elections" when we all know that the result will be nobody voting. It's just pointless bureaucracy. Collei (talk) 04:22, 8 February 2023 (UTC)
 * 6)  since holding elections with the expectation that nobody will vote and a victory by default will be granted is honestly disrespectful to both the time of Stewards and users requesting rights alike - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  Elections by acclamation do not make sense and are a ineffectual formality and bureaucracy that should not be needed. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 8)  per above. In fact, I'd also support permanently giving users bureaucrat and administrator status on wikis if they're the only active user, have a certain number of constructive contributions (100-250, maybe up to 500), and have been active for some time on the wiki. Tali64³ (talk) 11:42, 8 February 2023 (UTC)
 * 9)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Proposal 8: Election process
Elections should take place on a very prominent page. This could be the wiki's community portal, a designated place, or if nothing like this exists, on the talk page of the main page or a page specifically made for the job. It cannot be 'hidden' on an obscure or unknown page. If this criteria is not met, an election may be deemed to be invalid.

The nominee should at the minimum present themselves, what rights they want and their intentions. There should be at least a discussion section below that where people can ask questions and leave their input. The conventional model consists of sections for support, oppose, neutral and comments.

The community should be informed of the process (for example, if deemed appropriate, with a sitenotice or a message on the Main Page). A Steward may be contacted if no one has access to the above.

Active contributors and existing bureaucrats active on the wiki must be made aware of the election, if there are any.

Support (8)

 * 1)  Elections should be transparent and everyone in the community should know about them. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  This is already the status quo and has been a practice since before I was a Steward so there's no harm in formally codifying this process so that wiki requesters can easily see how we formally want an election to look like. It makes sense to have an election advertised on a prominent page in order to allow for maximum visibility.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Community portal or an RfP page would be good for visibility, and obviously the candidate should give a statement as to why they should serve in the role, or the nominator should. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  much cleaner language, added clause about requirements for considering an election valid is a good clarifying point. --NotAracham (talk • contribs • global) 03:29, 8 February 2023 (UTC)
 * 5)  Good idea Collei (talk) 04:22, 8 February 2023 (UTC)
 * 6)  per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  I support this as long as some leeway is given to local wikis as to how to run the election and where to advertise it. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 8)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Comments (8)
As this is near 1:1 with existing definition page for Local elections, an update on what's changed: --NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)
 * 1) Minor formatting cleanups
 * 2) General language simplification w/o changing intent
 * 3) Adds clause clarifying that an election which is not clearly held on a prominent page will be considered invalid

Proposal 9: Election duration and closure

 * All local elections involving advanced permissions (administrator, bureaucrat, etc.) must stay open for at least 5 days (but 7 days is recommended).

In case there is no local bureaucrat to effectuate the election, the result should be taken back to the Stewards' noticeboard - in the original section if it's been brought up before, or a new one if it has not.

Support (9)

 * 1)  There should be enough time for the community to express itself. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  This is already the status quo (we advise all requesters to wait for a minimum of 5-7 days before asking us to close an election) so this would only codify the status quo.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Status quo, codifying. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Simplified language + adding local closure rules gets my support --NotAracham (talk • contribs • global) 03:34, 8 February 2023 (UTC)
 * 5)  Sure. Collei (talk) 04:23, 8 February 2023 (UTC) Actually, I'm going with Proposal 9, Amendment 2. Less vague and contains all the good ideas from both Proposal 9 and Proposal 9 Amendment 1. Collei (talk) 16:10, 9 February 2023 (UTC)
 * 6)  per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Oppose (9)

 * 1)  I support a recommendation but do not support a mandatory 5 day period. This is for two reasons. The first is that many times there will not even be an election and administrators will just be appointed by bureaucrats so it is an odd occurance to mandate minimums for elections but for this to be bypassed on a wiki with a small community where elections do not even take place. The second is that it is hard to enforce and that it is not clear whether an election closed earlier could be deemed invalid if the limit is not respected. Therefore I support this only insofar as it is only a recommendation. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * The first issue raised here can be resolved through Proposal 7. The second is simple, it is clear: an election that runs for less than 5 days is invalid. Collei (talk) 16:37, 8 February 2023 (UTC)
 * 1)  This proposal defining a fixed time for local elections is problematic. For example, what about elections with a very high support ratio (at least 80%)? If this proposal passes (which it likely will), then even if every single active contributor supported a user becoming a bureaucrat, it still couldn't be closed before 5 days have passed. The opposite is true; if an election had a very low support ratio (at most 20%), then it still couldn't be closed before 5 days despite the election clearly failing. WP:SNOW should still apply here. Tali64³ (talk) 19:02, 8 February 2023 (UTC)
 * Ah, consideration for WP:SNOW could be given. Collei (talk) 16:06, 9 February 2023 (UTC)
 * 1)  For reasons that I have explained earlier, Proposal 9, Amendment 2 is better. Collei (talk) 16:15, 9 February 2023 (UTC)

Comments (9)
Changes vs Local elections:

--NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)
 * 1) Simplifies cumbersome multi-sentence language down to a single, clear sentence that outlines minimums
 * 2) Adds clause allowing local bureaucrats to close out an election provided that minimums are met.

Proposal 9, Amendment 1
Since the above proposal has good intentions, but may ultimately cause problems in edge cases, I propose to add the following to it:

'''If the nominee of a local election has received at least 80% support from the community of the wiki the election is occurring in (defined as users who have been contributors for at least one month and have made at least 5 contributions in the past 30 days) and a majority of the wiki's community (at least 2/3, or 67%) has voted, then the election may be closed as successful as soon as 2 days has passed. Vice versa, if the nominee has received at most 20% support from the wiki's community, the election may be closed as unsuccessful as soon as the same period of time has passed.'''

Tali64³ (talk) 19:12, 8 February 2023 (UTC)

Support (9 A1)

 * 1)  as proposer. This should solve the problems I mentioned in my oppose for Proposal 9 above. Tali64³ (talk) 19:12, 8 February 2023 (UTC)
 * 2)  No issue with it if Proposal 9 is unsuccessful.  Agent Isai  Talk to me! 19:19, 8 February 2023 (UTC)
 * 3)  Per the proposal, this is a good idea should Proposal 9 fail. Thanks - BrandonWM (talk • contributions • global • rights) 05:02, 9 February 2023 (UTC)
 * 4)  adding this to Proposal 9, and passing both. Something similar to WP:SNOW would be good here. Collei (talk) 16:08, 9 February 2023 (UTC) Actually, I'm going with Proposal 9, Amendment 2. Less vague and contains all the good ideas from both Proposal 9 and Proposal 9 Amendment 1. Collei (talk) 16:11, 9 February 2023 (UTC)

Oppose (9 A1)

 * 1)  as imo two days is simply too short of a timespan to close down an election especially in smaller wikis where "80% of 50+%" is less likely to accurately represent the overall opinion of the community. Consider the following hypothetical: 2 days in, 8 out of 15 of active editors have voted on a local election, 7 on them in favour and 1 against. After 5 days have passed, all 15 active editors have voted, 7 in favour and 8 against. Said hypothetical could occur by random chance or be facilitated by someone violating item 1 of Proposal 3.3 and privately contacting all active editors that agree with them to make absolutely sure they vote. Personally I see this amendment as making it too easy for someone to legitimize a coup or other controversial decision the community is highly divided over via a snap election. With the clarification that this would require a two thirds majority rather than 50%+1, this is much harder to abuse to perform a coup and so I've reduced my level of opposition to weak, as I still believe that a fast track option is not really necessary, with five days already being a rather short timeframe in the grand scheme of things, and if nothing else people should be given sufficient time to change their mind, voice counterarguments, etc. - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
 * The majority as defined in this proposal would be 2/3 (67%) if it were to pass. This ratio is sufficient for determining early consensus. Tali64³ (talk) 20:35, 8 February 2023 (UTC)
 * 1)  I believe that this proposal introduces an unnecessary level of bureaucracy in an already complicated to understand policy. I reiterate my view that I believe it is unnecessary to regulate this particular aspect and that a recommendation made to wikis would be sufficient in my view. --DeeM28 (talk) 19:53, 8 February 2023 (UTC)
 * 2)  For reasons that I have explained earlier, Proposal 9, Amendment 2 is better. Collei (talk) 16:16, 9 February 2023 (UTC)

Proposal 9, Amendment 2
It is recommended that local elections for advanced permissions (administrator, bureaucrat, etc.) stay open for at least 5-7 days to avoid appeal of results as an improper/premature closure.
 * Given challenges with original proposal 9 and 9 A1, suggesting the following language as superceding both proposals if approved:

When there is no local bureaucrat to officiate the election, the result should be taken back to the Stewards' noticeboard - in the original section if it's been brought up before, or a new one if it has not.

A discussion may be closed at steward discretion prior to the recommended 5-7 days in cases where there is: However, early closure of elections for advanced roles should only be undertaken by stewards sparingly, with all criteria above strictly-followed. Local leadership is encouraged to follow the above steward criteria for early closures to avoid disputed outcomes.
 * overwhelming support/opposition from established members of the community
 * no possibility of reversal if the election were to be left open
 * a clear and urgent need for the role to be filled

--NotAracham (talk • contribs • global) 22:18, 8 February 2023 (UTC)
 * This amendment language changes the 'must' to a recommendation with clear rationale as to why it should be followed, adds the possibility of early closure by stewards without prescribing exact day counts, and removes strict percentile limits in favor of descriptive criteria. It also makes clear that early closure by stewards specifically is an extraordinary action, and a note that local leadership should follow suit.

Support (9 A2)

 * 1)  As proposer --NotAracham (talk • contribs • global) 22:18, 8 February 2023 (UTC)
 * 2)  A sensible middle ground - CabraComunista (talk) 00:02, 9 February 2023 (UTC)
 * 3)  Thanks - BrandonWM (talk • contributions • global • rights) 05:04, 9 February 2023 (UTC)
 * 4)  This amendment fixes the issue I had with Proposal 9 by wording it in such a way that it doesn't require another process for closure for elections with very high/low support ratios, which I proposed in Proposal 9, Amendment 1. Tali64³ (talk) 15:04, 9 February 2023 (UTC)
 * 5)  Less vague and contains all the good ideas from both Proposal 9 and Proposal 9 Amendment 1. Collei (talk) 16:12, 9 February 2023 (UTC)

Proposal 10: Private and personal wikis

 * Only users who can have view permissions on a private wiki may run for a position on that wiki. External users who cannot view the wiki cannot run for any position within the wiki.


 * No users may run for a positions on wikis [that are listed in Proposal 2].


 * If a wikis focuses on a niche topic, can be characterized as a 'tight-knit community', and has a small number of active users only a user who is part of the group of users may be nominated for a position. It should be clarified that users may become part of the group at any time; it is not limited to users who were originally part of it.

Support (10)

 * 1)  Makes sense. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Perfectly reasonable. It wouldn't make sense to allow any user who can't even view the wiki/isn't part of the wiki community to run for any position.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  It would make 0 sense otherwise. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Generally supported in principle, I'd like to also see clarifying language regarding local bureaucrats changing wiki status to private in order to fend off local election eligibility. --NotAracham (talk • contribs • global) 03:43, 8 February 2023 (UTC)
 * Steward discretion would be in order as such an action violates the principle of operating by consensus by attempting to suppress it. Agent Isai  Talk to me! 03:58, 8 February 2023 (UTC)
 * 1)  Collei (talk) 04:23, 8 February 2023 (UTC)
 * 2)  Agree in principle but echoing my worries with the loose layman interpretation of what encompasses a "tight-knit community" as with Proposal 3.2 - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 3)  I also agree with the principle but echo comments in Proposal 3.2. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 4)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Oppose (10)

 * 1) We need stronger language and clarification on niche, tight-knit, and personal communities, so that we don't alarm the average layman, as CabraComunista and others have pointed out. Collei (talk) 16:39, 8 February 2023 (UTC)

Comments (10)
Changes from Local_elections: --NotAracham (talk • contribs • global) 03:39, 8 February 2023 (UTC)
 * 1) Minor language cleanup / consistency
 * 2) Add clauses covering proposal 2 "personal" wikis in greater detail
 * 3) Added updated language on niche/closely-knit communities
 * 4) Clarifies that users can become part of that closely-knit community over time -- just because they're currently ineligible to hold roles doesn't mean they can't become eligible at a later date.

Proposal 10, Amendment 1

 * Adds the following clause to Proposal 10

"In lieu of a local election, an active wiki community following under the auspices of personal/private/niche/tightly-knit community status may opt for local leadership to appoint individuals to advanced roles, following the same procedure as Steward appointment of roles on inactive wikis. Roles gained by appointment are understood to be less-durable and assume a weaker standard for removal by community vote.

--NotAracham (talk • contribs • global) 18:41, 8 February 2023 (UTC)
 * This provides the option for communities with special status to bypass election requirements and also clarifies that appointments done in this way are less-durable than gaining a role by election.

Support (10 A1)

 * 1)  as proposer --NotAracham (talk • contribs • global) 18:41, 8 February 2023 (UTC)
 * 2)  This was how Meta operated in the very early days and it makes sense to be more lenient with such wikis and not require formal elections for everything, especially at the beginning. Reception123 (talk) ( C ) 19:04, 8 February 2023 (UTC)
 * 3)  per Reception123 - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
 * 4)  I welcome this proposal as another realisation that policies must adapt to reality. The reality here is that it is unrealistic to ask small projects to hold "elections" and that sometimes discretionary appointments will happen when the project is still developing. Flexibility is important. --DeeM28 (talk) 19:55, 8 February 2023 (UTC)
 * 5)  Thanks - BrandonWM (talk • contributions • global • rights) 05:04, 9 February 2023 (UTC)
 * 6)  Same as others. We shouldn't require wikis to become bureaucracies. Collei (talk) 16:18, 9 February 2023 (UTC)

Proposal 11: Minor local rights

 * On wikis with inactive bureaucrats, Stewards may grant small local rights to users upon request and proper need without a local election. This includes and is not limited to: Autopatrolled, Confirmed, and Rollbacker. They can be requested on Stewards' noticeboard while stating the reason for why the rights are needed.

Support (11)

 * 1)  Once again, it wouldn't make sense to demand elections in an underdeveloped community. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  This has been the status quo since forever ago (so much so that it has its own section on the Stewards' noticeboard, see Stewards' noticeboard) so it'd make perfect sense to codify this in as Stewards act like local bureaucrats on wikis without any active one.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  In terms of granting rights, no issue. Granting rollbacker gives me pause, but it's fine in the long run. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  This is already policy in Local_elections, there's only minor language cleanup here.  No reason to oppose. --NotAracham (talk • contribs • global) 03:45, 8 February 2023 (UTC)
 * 5) Conditional support Some Fandom wikis and such decide to repurpose the rollback group into a lower-level or "trial" moderator role, due to Fandom's reluctance to make custom user groups. I think this should only apply to wikis where they haven't turned small groups like autopatrolled and rollback into significant groups, because I can see many people (especially those who migrated from Fandom or are regular Fandom contributors) doing this. Collei (talk) 04:25, 8 February 2023 (UTC)
 * So far I haven't encountered any such wikis but quite true. I'll definitely note this as that's quite true that some small groups are sometimes retooled. Agent Isai  Talk to me! 04:35, 8 February 2023 (UTC)
 * 1)  for the same reason as Proposal 7 - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 2)  Even if I am not sure how necessary it is due to the minor nature of these rights I do not see any problem with this. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 3)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Proposal 12.1: Removing bureaucrats

 * Miraheze wikis are configured by default to only permit Stewards to remove bureaucrats. The same rules as described above apply for removal of bureaucrats.


 * In order for a bureaucrat to be removed at least 50% of users must support the removal and a valid reason must exist for the removal (for example, a bureaucrat may be removed if they are acting against the community's interests).


 * Removing a bureaucrat without community consensus or very compelling/emergency reasons is highly frowned upon. If this happens, Stewards may intervene if necessary.

Support (12.1)

 * 1)  It doesn't seem fair to remove a bureaucrat if the majority of users disagree with this removal, per the principle of community consensus. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Per Reception123.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Per Reception123. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  As above rules for determining 'support' have been applied via changes to referencing how elections are run, this seems to avoid the normal pitfalls that a 50% threshold may have.  Also... stewards can always apply their judgement in edge cases. --NotAracham (talk • contribs • global) 03:50, 8 February 2023 (UTC)
 * 5)  Good idea Collei (talk) 04:26, 8 February 2023 (UTC)
 * 6)  per Reception123 - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  Bureaucrats are important to a wiki's community and they should not be able to be removed by a rogue "coup d'état" or by a minority of users. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 8)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Comments (12.1)
Changes from Local_elections --NotAracham (talk • contribs • global) 03:49, 8 February 2023 (UTC)
 * 1) Minor language cleanup
 * 2) Removes bureaucrat-specific language on existing page and replaced with reference to above procedure for running elections for consistency.
 * 3) Adds a minimum threshold of 50% support for removal

Proposal 12.2: Removing major contributor

 * If a user has contributed to the vast majority of content on a wiki, they may only be removed as administrator or bureaucrat if there is a very good and genuine reason for doing so. A major contributor may not be removed from advanced permissions simply because they have different views or ideas about the wiki's direction. A major contributor may only be removed following a vote, unless there are compelling/emergency reasons.

Support (12.2)

 * 1)  It makes sense that someone who has contributed to the "vast majority" (a high bar) of content and therefore has put a lot of time and effort into it shouldn't be able to be removed as administrator or bureaucrat just because others disagree with their ideas. If the major contributor isn't doing a good job as an administrator, that's a different issue and wouldn't be covered. Reception123 (talk) ( C ) 12:06, 7 February 2023 (UTC)
 * 2)  Per Reception123.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  This makes sense, helped draft this proposal so I'm all for it. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  This is a net-new section and in-line with other changes, no reason to oppose. --NotAracham (talk • contribs • global) 03:52, 8 February 2023 (UTC)
 * 5) Conditional support Depends how you define "disagreeing" and "major contributor". Some people have huge egos and think their harassment and horrible behavior is just "disagreeing". I would want the policy to have a specific definition of what a disagreement is, what high-quality contributions are, etc. Collei (talk) 04:28, 8 February 2023 (UTC)
 * Using a percentage or number was considered but I thought it would be an incentive for someone to inflate their contributions in order to become 'protected' here, which is why this would be determined by an objective look at their contributions to the wiki. But if you really want a percentage, I'd say that less than 70-80% of contributions to the wiki's content wouldn't do. As for disagreement, administrators/bureaucrats are there to manage the wiki and aren't obliged to agree with other users when it comes to ideas or its direction. Reception123 (talk) ( C ) 06:19, 8 February 2023 (UTC)
 * 1)  since it provides wikis that are pseudo-solo projects (but don't have the correct scope to be considered personal wikis as per Proposal 2) some form of protection against unjustified coups - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 2)  I support the idea behind this as someone who has worked hard and spent their time working on a project should not be able to be kicked out at the behest of some new users who want to go their own ways. This does not erode the concept of consensus too much either as it remains possible to remove a major contributor as long as there are good reasons for doing so. If this provision did not exist there might be a chilling effect on users working hard to build a wiki from scratch if they knew that a group of users could come later on and remove them from all their positions and even eventually block them. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 3)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)

Proposal 13: Wikis with conflicting groups/management

 * In a situation where there are two equally represented conflicting groups with different visions or ideas for the wiki who are unable to reach an agreement among themselves, they may contact Stewards who will mediate.


 * In extreme circumstances where there is clearly no prospect of agreement or reconciliation between the two groups, Stewards may, in accordance with the Content Policy, allow for a fork of the wiki to be created and the two groups to separate. Otherwise, the wiki should be closed.

Support (13)

 * 1)  Has happened in the past, best to have it clarified. Reception123 (talk) ( C ) 12:08, 7 February 2023 (UTC)
 * 2)  It is already the status quo to reach out to Stewards in case of a dispute, as per the Stewards policy. The latter portion could be helpful in many cases and in fact, I have a few historical cases I can think of where this provision could've helped a lot.  Agent Isai  Talk to me! 14:38, 7 February 2023 (UTC)
 * 3)  Status quo. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
 * 4)  Another net new section that further clarifies what was recently established with the Content Policy overhaul regarding wiki fork creations. --NotAracham (talk • contribs • global) 03:53, 8 February 2023 (UTC)
 * 5)  Collei (talk) 04:29, 8 February 2023 (UTC)
 * 6)  per Agent Isai - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
 * 7)  This seems quite obvious but if it is felt that it is necessary to be codified I do not have any issues. I strongly recommend moving this to the governance page and not the local elections page as this has nothing to do with elections. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
 * 8)  I support by joining the community. Best Regards,  Hey Türkiye  Message? 12:07, 8 February 2023 (UTC)