Requests for Comment/Wiki governance and local elections

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

More than two months have passed since this RfC was initiated. While usually it is highly desirable for an uninvolved Steward to close RfCs in this case it doesn't seem right to leave an RfC unimplemented for months where an uninvolved Steward is unfortunately not available for a close. If there are any complaints or concerns about how this RfC was closed they can be made on Stewards' noticeboard. I will review such complaints and if the user who made them is still not satisfied an uninvolved Steward can review them and make any changes that may be necessary. Due to the exceptional circumstances, I have asked User:Agent Isai to review this close and he agrees with it. The RfC is closed as follows:

• Proposal 1: Successful.
• Proposal 1.2: Successful.
• Proposal 2: Successful, subject to Proposal 2, Amendment 1.
• Proposal 2, Amendment 1: Succesful, subject to Amendment 1 to Proposal 3.1
• Proposal 3.1: Successful.
• Proposal 3.1B: Unsuccessful.
• Amendment 1 to Proposal 3.1: Successful.
• Proposal 3.2: Unsuccessful. With only 55% of users supporting and concerns expressed about vagueness, there is no consensus for this proposal.
• Proposal 3.2, Amendment 1: Moot because Proposal 3.2 fails.
• Proposal 3.3: Successful.
• Proposal 4: Successful.
• Proposal 5: Successful.
• Proposal 6: Successful.
• Proposal 7: Successful.
• Proposal 8: Successful.
• Proposal 9: Successful, subject to Proposal 9, Amendment 2
• Proposal 9, Amendment 1: Unsuccessful.
• Proposal 9, Amendment 2: Successful.
• Proposal 10: Successful, subject to Proposal 10, Amendment 1
• Proposal 10, Amendment 1: Successful.
• Proposal 11: Successful.
• Proposal 12.1: Successful.
• Proposal 12.2: Successful.
• Proposal 13: Successful.

Reception123 (talk) (C) 05:30, 13 April 2023 (UTC)

---

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.

Note: Please read the proposals below as well, this is just the general rule and there are some exceptions provided for.

Support (1)

1.  Support 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.  Support 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.  Support 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.  Support 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.  Support Indeed a good idea, same as others. Collei (talk) 04:17, 8 February 2023 (UTC)
6.  Support per Agent Isai Hb1290 (talk) 05:47, 8 February 2023 (UTC)
7.  Support 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.  Support Codifying status quo and one of the most important principles of the farm - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
9.  Support A welcome codification and clarification. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
10.  Strongest support 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.  Support Nothing to add that hasn't been said, but I wholeheartedly agree! Untropicalisland (talk) 16:36, 9 February 2023 (UTC)
12.  Strongest support This is a principle integral to the organization and operation of All The Tropes and formalizing it for Miraheze as a whole can only benefit us. --Looney Toons (talk) 19:26, 9 February 2023 (UTC)
13.  Support --Átkýv L. (talk) 20:07, 9 February 2023 (UTC)
14.  Support Pppery (talk) 23:27, 9 February 2023 (UTC)
15.  Support ★Commander Xiaochan⚡ (Talk to me for fun) 23:46, 9 February 2023 (UTC)
16.  Support I believe that setting a term for what we agree to - even if it is a big scope "don't go against the wishes of the community" is good enough if we don't even have such consensus codified. Chiiika (talk) 23:50, 9 February 2023 (UTC)
17.  Support Without the community, wikis are useless. A large proportion of the wikis hosted here are community efforts and we should see it as that way. Ilikecomputers (talk) 07:24, 10 February 2023 (UTC)
18.  Support --Vlastari (talk) 13:00, 10 February 2023 (UTC)

     Support [[Special:Contributions/<REDACTED>|<REDACTED>]] 21:36, 12 February 2023 (UTC) Strike vote as it is from an anonymous account. --Blad (talk • contribs • global) 22:02, 12 February 2023 (UTC)

19.  Support Good that it’s staus quo - even better to put it in writing. | Soukupmi (talk) (✔) 13:15, 26 February 2023 (UTC)
20.  Support Fairly explanatory why. Money12123 (contribs | CentralAuth) 01:08, 4 March 2023 (UTC)
21.  Support per Agent Isai. --1108-Kiju/Talk 09:14, 5 March 2023 (UTC)
22.  Support Suits perfectly the nature of a wiki and the software and just makes good sense. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
23.  Support Codification of existing practice/fundamental principles. — Chrs (talk) 22:43, 27 March 2023 (UTC)

Oppose (1)

1.  Weak oppose 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)

2.  Strong oppose My Wiki is about a fantasy world created by me. If I hypothetically had fans, I wouldn't want them to oust me, the literal creator of the franchise. Can we have some kind of exception in this case or something? --Metalhead339 (talk) 17:07, 9 February 2023 (UTC)

   These concerns are covered in the later proposals. For concerns about ousters, see proposals 9, 10, 12.1, and 12.2. You would also in this hypothetical be covered under rules and definitions of personal/private/niche/tightly-knit communities, see proposals 2, 2 Amendment 1, 3.1 and 3.2 --NotAracham (talk • contribs • global) 17:29, 9 February 2023 (UTC)

   I agree with what NotAracham said. See my reply to SchizoidNightmares. Unless there's a very good reason for a bureaucrat to be removed, Stewards probably wouldn't outright oust them and your wiki is likely covered by a clause in the below sections which exempts a wiki from rule by consensus. If this proposal fails then we'll continue to use the system of unwritten, subject to change, Stewardic conventions and discretion. Agent Isai ^{Talk to me!} 18:10, 9 February 2023 (UTC)

   Agree. Some wikis (such as XTEX-VNET Wiki) are maintained and managed by the official, and are used for team administrative affairs, etc. These wikis should not fully follow the wishes of the community, but only partially. Under the premise of not violating the global policy, the administrator should manage most content according to the official wishes, unless the wiki is not managed and related to the official. XtexChooser (talk) 11:09, 10 February 2023 (UTC)

3.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:40, 5 March 2023 (UTC)
4.  Weak oppose Agree with SchizoidNightmares  Anpang📨  03:59, 19 March 2023 (UTC)
5.  Weak oppose per SchizoidNightmares. Redmin Contributions CentralAuth (talk) 16:15, 2 April 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)

Nothing does better with what's deleted around here. Band1301 (talk) 05:54, 10 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.  Support 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.  Support 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.  Support 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.  Support Sadly, as NotAracham stated, this has to be codified. Thanks - BrandonWM (talk • contributions • global • rights)
5.  Support Indeed a good idea, same as others. Collei (talk) 04:17, 8 February 2023 (UTC)
6.  Support per Agent Isai, particularly given our own experience on AVID Wiki. Hb1290 (talk) 05:47, 8 February 2023 (UTC)
7.  Support --Imamy (talk) 06:54, 8 February 2023 (UTC)
8.  Support per BrandonWM - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
9.  Support We should not support wikis being ran as dictatorships. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
10.  Support per Agent Isai, Best Regards Hey Türkiye ^Message? 11:56, 8 February 2023 (UTC)
11.  Support 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. — Preceding unsigned comment added by NeoQwerty (talk • contribs)
12.  Support per above. Having this as policy would prevent any more incidents like the AVID one and another one involving the administration of a reception wiki named Amazing YouTubers Wiki unfairly blocking a user there based on their personal experiences with them. Tali64³ (talk) 18:55, 9 February 2023 (UTC)
13.  Support Per all of the above. --Looney Toons (talk) 19:29, 9 February 2023 (UTC)
14.  Support --Átkýv L. (talk) 20:07, 9 February 2023 (UTC)
15.  Support Pppery (talk) 23:28, 9 February 2023 (UTC)
16.  Weak support I believe that sometimes swift actions are necessary; but emergency is not normal and transparency should be observed. Chiiika (talk) 23:53, 9 February 2023 (UTC)
17.  Strong support--Revival (talk) 05:16, 10 February 2023 (UTC)
18.  Support This way we can have a stronger sense of trust in the community as a whole, knowing that admins must provide a clear justification for what they are doing. Ilikecomputers (talk) 07:22, 10 February 2023 (UTC)
19.  Support --Vlastari (talk) 13:02, 10 February 2023 (UTC)

     Support This should go without saying. [[Special:Contributions/<REDACTED>|<REDACTED>]] 21:37, 12 February 2023 (UTC) Strike vote as it is from an anonymous account. --Blad (talk • contribs • global) 22:03, 12 February 2023 (UTC)

20.  Support Yeah - that’s a no-go. |Soukupmi (talk) (✔) 13:17, 26 February 2023 (UTC)
21.  Support I agree. The use of permissions for unfair reasons is also happening in Japanese wikis. It needs to be clearly regulated in advance to prevent problems. --1108-Kiju/Talk 11:28, 6 March 2023 (UTC)
22.  Support This goes hand in hand with the first proposal as supporting the nature and intent of wikis and wiki software. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
23.  Support Transparency and accountability are critical principles for any project. — Chrs (talk) 23:02, 28 March 2023 (UTC)

Oppose (1.2)

1.  Weak oppose 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)

   Something like w:WP:OPAQUE could be referenced if clarification has to be given on why a genuine action provides little to no context. Collei (talk) 05:47, 12 February 2023 (UTC)

2.  Strong oppose For the same reason I oppose the first proposal. See further there. As long as I abide by the rules of Mirahaze's content policy, it should be "my house, my rules" for wikis that are about something that the wiki's founder has created out of thin air (as opposed to fandoms). --Metalhead339 (talk) 17:08, 9 February 2023 (UTC)

   This proposal doesn't prevent strict local rules and enforcement, it just requires that local leadership be transparent in why they're taking punitive actions against users. Having strict local rules is still perfectly fine, and Proposal 4 clarifies that global policies are a baseline from which you can go further as you see fit. --NotAracham (talk • contribs • global) 17:34, 9 February 2023 (UTC)

3.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:38, 5 March 2023 (UTC)
4.  Oppose Per above. Redmin Contributions CentralAuth (talk) 16:32, 2 April 2023 (UTC)

Abstain (1.2)

1.  Neutral  Anpang📨  03:59, 19 March 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.  Support In these cases it doesn't make sense to rule by consensus. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support 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.  Support 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.  Support Current status quo, just codifying it. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
5.  Support Indeed a good idea, same as others. Collei (talk) 04:16, 8 February 2023 (UTC)
6.  Support 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.  Support 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  Support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 11:59, 8 February 2023 (UTC)
10.  Strongest support These exceptions, especially if generously applied in practice, may save these otherwise (respectfully) excessive interventionist proposals. --SchizoidNightmares (talk) 18:33, 8 February 2023 (UTC)
11.  Support --Looney Toons (talk) 19:31, 9 February 2023 (UTC)
12.  Support --Átkýv L. (talk) 20:07, 9 February 2023 (UTC)
13.  Support Pppery (talk) 23:28, 9 February 2023 (UTC)
14.  Support; given we have Proposal 1. Nonenum it will be better tho. Chiiika (talk) 23:55, 9 February 2023 (UTC)
15.  Support I agree with this. Danniel (talk) 05:09, 10 February 2023 (UTC)
16.  Support--Revival (talk) 05:12, 10 February 2023 (UTC)
17.  Support --Vlastari (talk) 13:02, 10 February 2023 (UTC)
18.  Support Personal wikis are the exception- agree. | Soukupmi (talk) (✔) 13:19, 26 February 2023 (UTC)
19.  Support Again, makes good sense. A personal wiki is for that person and should be governed by them. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
20.  Support Makes sense  Anpang📨  03:59, 19 March 2023 (UTC)
21.  Support In these cases, the user is the editing community. — Chrs (talk) 23:04, 28 March 2023 (UTC)
22.  Support Common sense. Redmin Contributions CentralAuth (talk) 09:51, 3 April 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

Add language following the example list of personal wikis

"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."

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

--NotAracham (talk • contribs • global) 18:04, 8 February 2023 (UTC)

Support (2A1)

1.  Support adding support as proposer --NotAracham (talk • contribs • global) 18:04, 8 February 2023 (UTC)
2.  Support 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.  Support Let's not be too rigid! Agent Isai ^{Talk to me!} 19:09, 8 February 2023 (UTC)
4.  Support per Reception123 - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
5.  Support 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.  Support I support this Amendment --Imamy (talk) 23:27, 8 February 2023 (UTC)
7.  Support This makes sense. Thanks - BrandonWM (talk • contributions • global • rights) 04:54, 9 February 2023 (UTC)
8.  Support --Looney Toons (talk) 19:32, 9 February 2023 (UTC)
9.  Support --Átkýv L. (talk) 20:07, 9 February 2023 (UTC)
10.  Support Pppery (talk) 23:28, 9 February 2023 (UTC)
11.  Strong support; fixing the above. Chiiika (talk) 23:56, 9 February 2023 (UTC)
12.  Support--Revival (talk) 05:16, 10 February 2023 (UTC)
13.  Support XtexChooser (talk) 11:16, 10 February 2023 (UTC)
14.  Support --Vlastari (talk) 13:03, 10 February 2023 (UTC)
15.  Support -- Soukupmi (talk) (✔) 13:20, 26 February 2023 (UTC)
16.  Support This should help allay concerns and build in some common sense flexibility. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
17.  Support  Anpang📨  04:00, 19 March 2023 (UTC)
18.  Support This has the same general effect as the last bullet point in Proposal 2, but this provides additional clarity. — Chrs (talk) 23:07, 28 March 2023 (UTC)
19.  Support Redmin Contributions CentralAuth (talk) 09:53, 3 April 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.  Support 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.  Strong support 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.  Support 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.  Weak support 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.  Support 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.  Weak support 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.  Weak support 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 genuinely 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Weak support 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)
10.  Support We have had several instances of users joining All The Tropes solely to demand we change something, anywhere from page names to site rules, that they didn't like. In all cases these users showed absolutely no interest in contributing to the wiki in any other way, to the point of even refusing to follow the procedure we have in place for effecting the kind of changes they wanted. They simply camped a chosen talk page and complained. I very much like the idea of rewarding our dedicated users and making it clear to the single-issue wonks that their influence is limited by them focusing only on their one subject of interest. --Looney Toons (talk) 19:39, 9 February 2023 (UTC)
11.  Weak support Like CabraComunista, I agree with the rationale of the proposal. I just think "weighed less" is somewhat poorly defined here. Does there exist some formula or index to determine how less a vote is to be weighed, or is it up to qualitative interpretation? Supposing it's the latter, how would one justify the weight a vote is given? --Átkýv L. (talk) 20:07, 9 February 2023 (UTC)
12.  Support Would prefer wording this as "may be weighed less than other votes", but this will do and it's not worth creating a new proposal over. Pppery (talk) 23:30, 9 February 2023 (UTC)
13.  Support --Vlastari (talk) 13:06, 10 February 2023 (UTC)

     Weak support I disagree with the idea that we should give less value to someone's opinion simply because they are new. If the issue is a lack of experience resulting in the user making an uninformed comment, it can be pointed out in the discussion. If there is obvious meatpuppetry/off-wiki canvassing, it can be dealt with, but unless that happens, a good argument is still a good argument, and a bad argument is still a bad argument. [[Special:Contributions/<REDACTED>|<REDACTED>]] 21:42, 12 February 2023 (UTC) Strike vote as it is from an anonymous account. --Blad (talk • contribs • global) 22:03, 12 February 2023 (UTC)

14.  Support Totally reasonable -- Soukupmi (talk) (✔) 13:22, 26 February 2023 (UTC)
15.  Support Makes good sense and seems fair. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
16.  Weak support given that this is to be interpreted narrowly, though I would prefer wording that makes it more clearly a purely anti-abuse measure. — Chrs (talk) 23:14, 28 March 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)

   if 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)

2.  Strong oppose This could give rise to a probable "As this user is not familiar w/ whatever we do; they should be weighted less". Apart from what "weighted less" means; I believe that good arguments should have precedence than their wiki activity. Chiiika (talk) 00:03, 10 February 2023 (UTC)

   Even if someone can't vote, they're still allowed to comment (e.g. even people who don't have a Miraheze account can comment on this RfC). Brand new users can still give their arguments.- CabraComunista (talk) 00:17, 10 February 2023 (UTC)

3.  Strong oppose There are several issues:
   1. Vague and ambiguous. It could be open to abuse, e.g. as an excuse to discard/undermine votes that the admins/elite do not like.
   2. One size doesn't fit all. The input from users (not much or recently connected to a wiki's community) may be more valuable in some cases. For example, they bring outside-of-the-box perspectives and point out the blind spots missed by others. It is a pity their votes *must* be discarded or weighed less due to a rigid global rule.
   3. We don't really need a global rule for this. Let the local community of each wiki decide based on their own circumstances.--Revival (talk) 08:26, 10 February 2023 (UTC)
4. Not all communities have members who happen to know how to code or where to go for help.

   By weighing a vote, a community that started with members who are less familiar with Miraheze, or just figuring out how to post messages, it's hardly fair to say that only veteran contributors who were not part of the original community but who happen to have more experience has a say that is equal. Even if it's not stated in the original request, it is a given that many wiki requesters are in some way new. Put in another way, the true local community might not even know how to code. Could be only 1 actual representative for every 5 invisible community members. For example in niche communities, the majority of the community won't even be on Miraheze. They'll only visit their site as an IP address therefore their presence is not documented. --Imamy (talk) 16:42, 10 February 2023 (UTC)

5.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:51, 5 March 2023 (UTC)
6.  Strongest oppose I agree with the rationale and do not think that it is impossible to "weigh" someone's votes less. What I do find impossible, however, is for Stewards to be able to correctly make the distinction between a "connected" and an "unconnected" user. Many wikis are created to serve as supplements to communities that already exist elsewhere, and as such, they may only be edited by a handful of members of those communities; others who generally do not edit or have never edited at all may want to join the conversation on-wiki and it may well be the case that they never even had an account before! These users do not deserve to be discriminated against; their voice matters as much as that of any other user. Redmin Contributions CentralAuth (talk) 11:04, 3 April 2023 (UTC)

Abstain (3.1)

1.  Neutral 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)
2.  Neutral At some point, there may be some votes on the wiki that have nothing to do with the administration and content of the wiki itself. At this time, whether to adjust the weight should be decided by the community or sysop. XtexChooser (talk) 11:19, 10 February 2023 (UTC)

Proposal 3.1B: Weighting of votes (Alternative to Proposal 3.1)

The local community may set a threshold of the eligibility to vote.

A vote by a user is counted if it meets the threshold set by the local community.

Rationale:

• Wikis work on the belief that people act in good faith. Anyone, even first-time visitors, are welcome to contribute in wikis. It is what makes wikis successful.
• We believe in fewer rigid (global) rules and more trust.
• For wikis which are not popular and/or controversial, there is a very low risk of vote manipulation. A threshold may not even be required.
• One size doesn't fit all. Simply let the local community decide whether a threshold is required, and if "genuinely connected" should be a part of the threshold.

— Preceding unsigned comment added by Revival (talk • contribs)

Support (3.1B)

1.  Strong support--Revival (talk) 09:27, 10 February 2023 (UTC)
2.  Support --Átkýv L. (talk) 13:10, 10 February 2023 (UTC)

Oppose (3.1B)

1.  Strongest oppose This is, essentially speaking, Proposal 3.2 without an explicit "Stewards may undo this at any time" clause. I find it hard to imagine a world where this doesn't get abused to set-up vote weighing rules that entirely block any and all new contributors from overruling the opinion of a wiki's original "in-group". I simply don't see how this isn't too broad if we're working from the stance that 3.1 is too vague. — Preceding unsigned comment added by CabraComunista (talk • contribs)
2.  Strong oppose While written with good intent, this gives several opportunities for those with bad intentions to manipulate as Cabra points out. Cannot support. --NotAracham (talk • contribs • global) 16:58, 11 February 2023 (UTC)
3.  Oppose If the wiki leadership is dormant, then how does one know which community is local?

   What is seen on the site is often a work in progress, not a final product or an abandoned project. If the current and present local community only wishes to continue the project, that makes sense, but abuse usually results from a lack of awareness that this is a work in progress. Only the founder knows what was intended for the site. Just because another contributor can make the site look better or more popular, those improvements may actually obliterate the original aim and design for the site. It's one thing for the original content that is left behind by the founder to remain untouched or preserved in some recoverable way. It is quite another when that content is replaced by what the community has deemed to be a more appealing and a much needed improvement. I'd like to see some provisions in place to ensure that the elected officials are fully aware that they have been elected to govern the site, not to alter or replace the wiki's current agenda. --Imamy (talk) 05:13, 12 February 2023 (UTC)

4.  Strong oppose Yeah, I'm sorry, I know you had good intentions in writing this, but as others have explained, this won't work. Collei (talk) 05:50, 12 February 2023 (UTC)
5.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:52, 5 March 2023 (UTC)

Comments (3.1B)

• Ping users who may be interested in this proposal: @Collei:, @Chiiika:, @Naleksuh:, @Átkýv L.:, @Untropicalisland:, @DeeM28:, @CabraComunista:, @BrandonWM:.

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. — Preceding unsigned comment added by DeeM28 (talk • contribs)

Support (A1 3.1)

1.  Support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
3.  Weak support While there's probably a better way to get the intended outcome, this is acceptable. @DeeM28: 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.  Weak support Support with alternate language provided by NotAracham. Reception123 (talk) (C) 19:02, 8 February 2023 (UTC)
5.  Support conditional on alternate language suggested by NotAracham be used - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
   1.  Support 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)
6.  Support I support this amendment. --Imamy (talk) 00:16, 9 February 2023 (UTC)
7.  Support This is a good idea. Thanks - BrandonWM (talk • contributions • global • rights) 05:00, 9 February 2023 (UTC)
8.  Support --Looney Toons (talk) 19:42, 9 February 2023 (UTC)
9.  Support Clarifying a bit. -- Soukupmi (talk) (✔) 13:27, 26 February 2023 (UTC)
10.  Support Yes, the definition was too loose otherwise. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
11.  Weak support The phrasing "last few hours" could create room for some rules-lawyering, but otherwise this is more specifically targeted towards being an anti-abuse measure. — Chrs (talk) 23:17, 28 March 2023 (UTC)

Oppose (A1 3.1)

1.  Strong oppose "the last few hours" assumes that votes and polls are conducted in less than a day, when large wikis (I'm a bureaucrat at two large Miraheze wikis) routinely run for a week if not longer. This would create a loophole where outsiders join up on the first day of a vote and cannot be ignored on the final day of the vote. --Robkelk (talk) 18:14, 9 February 2023 (UTC)

   The above amendment should be purely read as giving an example of the sort of behavior that might be considered, not setting enforcement standards or establishing loopholes. Enforcement remains at steward discretion and folks joining at the start of an election (regardless of election length) purely to sway its outcome without being legitimate community members would still be covered under 3.1 whether or not this amendment passes. ---NotAracham (talk • contribs • global) 18:46, 9 February 2023 (UTC)

2.  Weak oppose I don't think an example is needed here; people are capable of judging when such a situation has occurred from the proposal itself. Pppery (talk) 23:31, 9 February 2023 (UTC)
3.  Strong oppose bad trees yield bad fruit. Chiiika (talk) 00:05, 10 February 2023 (UTC)
4.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:54, 5 March 2023 (UTC)

Abstain (A1 3.1)

1.  Abstain I suppose I do understand the application, but I still can't help but feel that the borders are a bit fuzzy. --Átkýv L. (talk) 20:07, 9 February 2023 (UTC)
2.  Abstain Although this amendment alone is fine, it could not save the whole tree (proposal). The root is already rotten and should be scrapped.--Revival (talk) 05:16, 10 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

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.

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.

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.  Support 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.  Support 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.  Support 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.  Support 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.  Support 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.  Support --Imamy (talk) 08:03, 8 February 2023 (UTC)
7.  Weak support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Strong support Absolutely. A wiki where 3 people do all the work shouldn’t have its direction changed by 50 almost-read-only members, just because they escaped the above clauses.-- Soukupmi (talk) (✔) 13:32, 26 February 2023 (UTC)
10.  Support I could see this scenario played out on a large number of wikis, this offers some protection for those communities that have niche topics where tight coordination and adherence to standards is needed, indeed. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Oppose (3.2)

1.  Weak oppose 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.  Weak oppose 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)
3.  Weak oppose I don't believe that this would solve the problem. The circumstances that the proposal covers are too specific, and this would just lead to a bigger possibility of abuse by the "original community" themselves. It would seem as if new members were simply lackies of the original ones.

   "Oh, you want change to the place? Well too bad! You're 'new', so your votes don't count; and I'm original, so my votes are bigger."

   I know that such ill intent is rare in most cases, but it's not a solution that touches the root. --Átkýv L. (talk) 20:07, 9 February 2023 (UTC)

4.  Oppose per Átkýv L. Pppery (talk) 23:32, 9 February 2023 (UTC)
5.  Strongest oppose Proposal 3 is in itself a bad tree and 3.2 is a bad fruit. Apart from issues that is illustrated above that this give rise to status quoing; this is a worse fruit than 3.1. Chiiika (talk) 00:07, 10 February 2023 (UTC)

   Many of your concerns with Proposal 3 were responded to. Please don't !vote based on something that was already argued against without giving a counterargument. Collei (talk) 05:52, 12 February 2023 (UTC)

6.  Strong oppose Proposal 3 itself is problematic. This amendment complicates it. You can't save a tree if its root is already rotten. The whole proposal should be just scrapped.--Revival (talk) 05:16, 10 February 2023 (UTC)
7.  Strong oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:58, 5 March 2023 (UTC)
8.  Weak oppose While I certainly see the need for a broader anti-infiltration/hijacking provision than in 3.1, this could be interpreted as creating a broader exception than I'm comfortable with. I'd certainly be open to supporting a clause that gave more specific criteria. — Chrs (talk) 23:27, 28 March 2023 (UTC)

Abstain (3.2)

•  Abstain This one I'm not entirely sure about. I'm holding my vote until I see more and think more about it. --Looney Toons (talk) 19:44, 9 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

This change avoids outside hijacking of wikis created by members of an organization to document that organization.

--NotAracham (talk • contribs • global) 18:33, 8 February 2023 (UTC)

Support (3.2 A1)

1.  Support as proposer --NotAracham (talk • contribs • global) 18:33, 8 February 2023 (UTC)
2.  Support It's necessary to incorporate companies/organisations as well. Reception123 (talk) (C) 19:03, 8 February 2023 (UTC)
3.  Support Straightforward. Agent Isai ^{Talk to me!} 19:10, 8 February 2023 (UTC)
4.  Support 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.  Support 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.  Support --Imamy (talk) 01:24, 9 February 2023 (UTC)
7.  Support Yes. Thanks - BrandonWM (talk • contributions • global • rights) 05:01, 9 February 2023 (UTC)
8.  Support Pppery (talk) 23:33, 9 February 2023 (UTC)
9.  Strong support Very good rationale is already provided. In addition to this, Miraheze has a competitive edge over hell because we allow corporations and non-profits to create wikis to document their things and run it through their normal channels. We don't want to lose that edge by creating confusing, bureaucratic procedures that make Miraheze unusable for some of the people it now works well for. Collei (talk) 05:55, 12 February 2023 (UTC)
10.  Support Some wikis migrate to Miraheze with this structure already in place it seems important to have some mechanism to continue to support that. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
11.  Support Should 3.2 pass, this is very reasonable. — Chrs (talk) 23:31, 28 March 2023 (UTC)
12.  Strong support per proposal. Redmin Contributions CentralAuth (talk) 11:30, 3 April 2023 (UTC)

Oppose (3.2 A1)

1.  Weak oppose although this is from Proposal 3; I do run such a wiki and in vacuum it works. Yet I think it should not be a amendment. Chiiika (talk) 00:09, 10 February 2023 (UTC)
2.  Oppose Proposal 3 and Proposal 3.2 are problematic. You can't save a tree if its root is already rotten. The whole proposal should be just scrapped.--Revival (talk) 05:16, 10 February 2023 (UTC)
3.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:59, 5 March 2023 (UTC)

Abstain (3.2 A1)

1.  Abstain --Átkýv L. (talk) 20:10, 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.  Support This is quite obviously something we don't want to have. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support 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.  Support Obviously. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Support Yes. Converts an already-observed (and necessary) best practice into official policy. --NotAracham (talk • contribs • global) 03:00, 8 February 2023 (UTC)
5.  Support Indeed a good idea, same as others. Collei (talk) 04:19, 8 February 2023 (UTC)
6.  Support --Imamy (talk) 08:28, 8 February 2023 (UTC)
7.  Support per Agent Isai - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
8.  Support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
10.  Support --Looney Toons (talk) 19:45, 9 February 2023 (UTC)
11.  Support --Átkýv L. (talk) 20:12, 9 February 2023 (UTC)
12.  Support Pppery (talk) 23:33, 9 February 2023 (UTC)
13.  Strong support puppetry? why does we want them to exist? /s but the tone is the same - we don't want them to exist. Chiiika (talk) 00:11, 10 February 2023 (UTC)
14.  Support--Revival (talk) 05:16, 10 February 2023 (UTC)
15.  Support But it should only apply when there is evidence of canvassing and voters give no reason for his support or oppose. XtexChooser (talk) 11:25, 10 February 2023 (UTC)

    Of course, I am under the impression that is how it is proposed to work. Collei (talk) 05:56, 12 February 2023 (UTC)

16.  Support -- Soukupmi (talk) (✔) 13:35, 26 February 2023 (UTC)
17.  Support. This should seem obvious but often the obvious needs to be explicitly stated to prevent abuse, so this is a good addition. | -- FrozenPlum (Talk / Email) 04:51, 19 March 2023 (UTC)
18.  Support — Chrs (talk) 23:31, 28 March 2023 (UTC)
19.  Support Redmin Contributions CentralAuth (talk) 11:51, 3 April 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.  Support Codifies the status quo. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support Status quo already so no harm in codifying it. Agent Isai ^{Talk to me!} 14:38, 7 February 2023 (UTC)
3.  Support Codifying status quo. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Support 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.  Support Indeed a good idea, same as others. Collei (talk) 04:20, 8 February 2023 (UTC)
6.  Support per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
7.  Support A useful codification. --DeeM28 (talk) 10:27, 8 February 2023 (UTC)
8.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Support --Imamy (talk) 01:40, 9 February 2023 (UTC)
10.  Support --Looney Toons (talk) 19:46, 9 February 2023 (UTC)
11.  Support --Átkýv L. (talk) 20:14, 9 February 2023 (UTC)
12.  Support Pppery (talk) 23:33, 9 February 2023 (UTC)
13.  Support. Chiiika (talk) 00:11, 10 February 2023 (UTC)
14.  Support XtexChooser (talk) 11:26, 10 February 2023 (UTC)
15.  Support -- Soukupmi (talk) (✔) 13:36, 26 February 2023 (UTC)
16.  Support per Fandom's WRBP --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:42, 5 March 2023 (UTC)
17.  Support necessary, frankly. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)
18.  Support — Chrs (talk) 23:32, 28 March 2023 (UTC)
19.  Support Redmin Contributions CentralAuth (talk) 12:57, 3 April 2023 (UTC)

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.  Support 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.  Support Reasonable definition of what an election is. Agent Isai ^{Talk to me!} 14:38, 7 February 2023 (UTC)
3.  Support Local elections are always a strong idea. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Support 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.  Support Indeed a good idea, same as others. Collei (talk) 04:21, 8 February 2023 (UTC)
6.  Support per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
7.  Support Useful to codify. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
8.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Support --Imamy (talk) 16:57, 9 February 2023 (UTC)
10.  Support Yes. Defining our terms will help prevent future end runs around how an individual wiki may do things. --Looney Toons (talk) 19:48, 9 February 2023 (UTC)
11.  Support --Átkýv L. (talk) 20:16, 9 February 2023 (UTC)
12.  Support Pppery (talk) 23:33, 9 February 2023 (UTC)
13.  Support. Chiiika (talk) 00:19, 10 February 2023 (UTC)
14.  Weak support With Agent Isai’s comment on the oppose below I can add my support here. -- Soukupmi (talk) (✔) 13:39, 26 February 2023 (UTC)

Oppose (5)

1.  Weak oppose For wikis directly maintained by official staff, I think admin privileges should be able to be granted to other official staff without election (if the wiki was created and maintained by official staff in the first place). XtexChooser (talk) 11:36, 10 February 2023 (UTC)

   Proposal 3.2 (and it's amendment) cover how we deal with these sorts of wikis where we'd allow for direct appointments versus elections. This only establishes the procedure for wikis not covered by any exemption clauses. Agent Isai ^{Talk to me!} 15:01, 10 February 2023 (UTC)

2.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:13, 5 March 2023 (UTC)

Comments (5)

As this is near 1:1 with existing definition page for m:Local elections, an update on what's changed:

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)

--NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)

1. What happens when elections take place off-wiki? For example- one of my wikis, Snap! Wiki has always elected its admins on an external forum where all members of the community are active. How would this affect it? Redmin Contributions CentralAuth (talk) 12:51, 3 April 2023 (UTC)

Proposal 6: Elections on wikis with inactive bureaucrats

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 following conditions apply to such elections (private wikis are dealt with separately):

• 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.  Support Per the current local election guidelines. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support Already the status quo. Agent Isai ^{Talk to me!} 14:38, 7 February 2023 (UTC)
3.  Support 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.  Support overall minor edits + incorporation of other key proposals, this has my support. --NotAracham (talk • contribs • global) 03:20, 8 February 2023 (UTC)
5.  Support Indeed a good idea, same as others. Collei (talk) 04:21, 8 February 2023 (UTC) I don't think that wikis should be required to start an election, just encouraged to. Changing to oppose. Collei (talk) 23:49, 9 February 2023 (UTC)
6.  Support 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.  Support per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
8.  Support This is a sound procedure. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
9.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
10.  Support --Imamy (talk) 17:01, 9 February 2023 (UTC)
11.  Support --Átkýv L. (talk) 20:17, 9 February 2023 (UTC)
12.  Support --Looney Toons (talk) 21:32, 9 February 2023 (UTC)
13.  Support -- Soukupmi (talk) (✔) 13:41, 26 February 2023 (UTC)
14.  Support | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Oppose (6)

1.  Oppose the community must set up a local election - so what will happen if they don't? If the community is not bothered by the lack of leaders then why should they be forced to choose some? Pppery (talk) 23:35, 9 February 2023 (UTC)

   Actually, that's a good point. Collei (talk) 23:48, 9 February 2023 (UTC)

   so what will happen if they don't? Considering Proposal 7 is so far passing with unanimous support, it can be assumed that someone will be appointed by a Steward in a temporary capacity. why should they be forced to choose some? So that Steward invervention isn't required every single time there's a global policy violation. - CabraComunista (talk) 00:17, 10 February 2023 (UTC)

   Proposal 7 only applies If there is no existing community or an extremely small one. The fact that a community lacks a leader does not necessarily imply it is nonexistent or extremely small. Pppery (talk) 00:39, 10 February 2023 (UTC)

   Wikis without leadership fall afoul of content policy 4 (no operating under anarchy rules), the intent is to avoid wikis without any leadership to enforce content policy and maintain normal operations. --NotAracham (talk • contribs • global) 01:06, 10 February 2023 (UTC)

   I agree with statement that a community does not have to set up a local election. Unless there are signs that require leadership to address certain issues, it is not a good idea that someone just step in without knowing how to meet this need. Not everyone understands the other person. Also, when one is not ready to lead, it can be quite lonely. May as well promote several active members simultaneously so they can learn from each other how to address the issues (as well as utilize managewiki tools). That they can be a team. But to thrust someone into governing the site, it can backfire. As a contributor, they may be active, but they may disappear if they find little time is left to do what they enjoy most.

   I still support the proposal because an election is a good way to usher in new leadership.--Imamy (talk) 03:58, 10 February 2023 (UTC)

2.  Oppose I don't think that wikis should be required to start an election, just encouraged to. Collei (talk) 23:49, 9 February 2023 (UTC)
3.  Strong oppose It's MUST, not Should! Chiiika (talk) 00:21, 10 February 2023 (UTC)
4.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:12, 5 March 2023 (UTC)

Comments (6)

As this is near 1:1 with existing definition page for m:Local elections, an update on what's changed:

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.

--NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)

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.  Support 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.  Strong support 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.  Support It would be stupid to do anything but. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Support 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.  Strong support 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.  Support 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.  Support 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.  Support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
10.  Support --Imamy (talk) 17:06, 9 February 2023 (UTC)
11.  Support --Átkýv L. (talk) 20:18, 9 February 2023 (UTC)
12.  Support --Looney Toons (talk) 21:32, 9 February 2023 (UTC)
13.  Support Pppery (talk) 23:35, 9 February 2023 (UTC)
14.  Support--Revival (talk) 05:31, 10 February 2023 (UTC)
15.  Strong support Decisions should be in sysops when nobody is voting XtexChooser (talk) 11:28, 10 February 2023 (UTC)
16.  Support -- Soukupmi (talk) (✔) 13:42, 26 February 2023 (UTC)
17.  Support Seems necessary in a lot of cases of small wikis. | -- FrozenPlum (Talk / Email) 19:24, 18 March 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.  Support Elections should be transparent and everyone in the community should know about them. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support 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.  Support 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.  Support 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.  Support Good idea Collei (talk) 04:22, 8 February 2023 (UTC)
6.  Support per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
7.  Support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Support --Imamy (talk) 17:09, 9 February 2023 (UTC)
10.  Support --Átkýv L. (talk) 20:20, 9 February 2023 (UTC)
11.  Support Per DeeM28. --Looney Toons (talk) 21:34, 9 February 2023 (UTC)
12.  Support Per Above (and my prev vote) 《Commetian_Empire》 (talk) 21:59, 9 February 2023 (UTC)
13.  Support Pppery (talk) 23:35, 9 February 2023 (UTC)
14.  Support -- Soukupmi (talk) (✔) 13:43, 26 February 2023 (UTC)
15.  Support Seems common sense. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Comments (8)

As this is near 1:1 with existing definition page for m:Local elections, an update on what's changed:

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

--NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)

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.  Support There should be enough time for the community to express itself. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support 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.  Support Status quo, codifying. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Support Simplified language + adding local closure rules gets my support --NotAracham (talk • contribs • global) 03:34, 8 February 2023 (UTC)
5.  Support 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.  Support per NotAracham - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
7.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
8.  Support --Átkýv L. (talk) 20:21, 9 February 2023 (UTC)
9.  Support Per Above (all) and I have done elections quite a few times, and I believe that the community (if there is one) should know about it. 《Commetian_Empire》 (talk) 21:59, 9 February 2023 (UTC)
10.  Support --Imamy (talk) 06:02, 10 February 2023 (UTC)
11.  Support -- Soukupmi (talk) (✔) 13:44, 26 February 2023 (UTC)
12.  Support A minimum seems needed. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Oppose (9)

1.  Oppose 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)

2.  Oppose 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)

   I don't see the need for immediate promotion by shortening an election. If a temporary appointment will allow one to make the necessary emergency changes, then an election should remain as it stands - at 5 days minimum.

   Say if a new bureaucrat is voted in, and if 5 days is the current minimum, then to lower it will not be kind for those users who know about and expect the 5 day minimum.

   I am assuming that bureaucrats have the power to delete pages as well as make other sweeping changes. I don't think it would be fair to active users who could otherwise be on holiday or addressing family emergencies to take part in an election that could affect their personal projects within the community. If 5 days was the minimum, then they ought to have time to come out and express their concerns. I'm sure they'll still vote the guy in, however, with the 5 days, they at least will also have an opportunity to consider as well as to voice any concerns. If it is important to speed up filling out the role, then the election should just be scheduled sooner so that the election can end sooner. --Imamy (talk) 17:56, 9 February 2023 (UTC)

3.  Oppose For reasons that I have explained earlier, Proposal 9, Amendment 2 is better. Collei (talk) 16:15, 9 February 2023 (UTC)
4.  Oppose One size doesn't fit all. Let the community decide the minimum period of a local election. A hard fixed global requirement should be placed only if there is no local consensus on that.--Revival (talk) 05:31, 10 February 2023 (UTC)
5.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:11, 5 March 2023 (UTC)

Abstain (9)

1.  Neutral Shifting vote to abstain, opposition raises good points and I have proposed Amendment 2 which overwrites this language.
2.  Abstain --Looney Toons (talk) 21:37, 9 February 2023 (UTC)

Comments (9)

Changes vs m:Local elections:

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.

--NotAracham (talk • contribs • global) 03:40, 8 February 2023 (UTC)

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.  Support 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.  Support No issue with it if Proposal 9 is unsuccessful. Agent Isai ^{Talk to me!} 19:19, 8 February 2023 (UTC)
3.  Support 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.  Support As the above I support this in case the other fails, even though I don’t see the point in reducing it to 2 days. The rest makes sense. -- Soukupmi (talk) (✔) 13:48, 26 February 2023 (UTC)

Oppose (9 A1)

1.  Weak oppose 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)

2.  Weak oppose 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)
3.  Oppose For reasons that I have explained earlier, Proposal 9, Amendment 2 is better. Collei (talk) 16:16, 9 February 2023 (UTC)
4.  Weak oppose per DeeM28. --Átkýv L. (talk) 20:23, 9 February 2023 (UTC)
5.  Weak oppose Changed vote after reviewing 9A2. --Looney Toons (talk) 21:40, 9 February 2023 (UTC)
6.  Strong oppose One size doesn't fit all. This admendment even complicates the matter.--Revival (talk) 05:31, 10 February 2023 (UTC)
7.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:10, 5 March 2023 (UTC)

Abstain (9 A1)

1.  Abstain I am not opposed and also not supportive. Mainly because if I understand the election process correctly, if the wiki were to define it's own election process, then that should take precedence, right? I hope I got that part right. So if the wiki were to desire quick elections, or if they require longer ones, or if they want something where several contributors could be voted into office together then I have no objections. But I still don't like the idea of a case by case situation where the election that started out with a 5 day minimum can suddenly close early without warning. I don't fully understand the election process and cutting an election short just feels like the election is more strategy based than will of the people. --Imamy (talk) 04:29, 10 February 2023 (UTC)

Proposal 9, Amendment 2

Given challenges with original proposal 9 and 9 A1, suggesting the following language as superceding both proposals if approved

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.

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:

• 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

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.

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.

--NotAracham (talk • contribs • global) 22:18, 8 February 2023 (UTC)

Support (9 A2)

1.  Support As proposer --NotAracham (talk • contribs • global) 22:18, 8 February 2023 (UTC)
2.  Support A sensible middle ground - CabraComunista (talk) 00:02, 9 February 2023 (UTC)
3.  Support Thanks - BrandonWM (talk • contributions • global • rights) 05:04, 9 February 2023 (UTC)
4.  Support 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.  Support 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)
6.  Support per CabraComunista --Átkýv L. (talk) 20:24, 9 February 2023 (UTC)
7.  Support --Looney Toons (talk) 21:41, 9 February 2023 (UTC)
8.  Support Pppery (talk) 23:37, 9 February 2023 (UTC)
9.  Support--Revival (talk) 05:31, 10 February 2023 (UTC)
10.  Support Yeah this also makes sense. -- Soukupmi (talk) (✔) 13:53, 26 February 2023 (UTC)
11.  Support Seems like a balanced compromise. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Abstain (9 A2)

1.  Abstain a clear and urgent need for the role to be filled...

   An absent leadership automatically creates a void. How bad is a situation where one particular election has to end quickly? Can people freely discuss after the election is over or will talk be discouraged? I really don't like the idea of exceptions unless there's clear awareness. Because one of the reasons one may not wish to run for office is that they don't want to wait the 5 days. Then we lose out on this one candidate when someone else does find a way to go into office sooner. There is not much fairness in terms of opportunity. --Imamy (talk) 05:22, 10 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.  Support Makes sense. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support 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.  Support It would make 0 sense otherwise. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Weak support 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)

5.  Support Collei (talk) 04:23, 8 February 2023 (UTC)
6.  Weak support 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)
7.  Weak support I also agree with the principle but echo comments in Proposal 3.2. --DeeM28 (talk) 10:36, 8 February 2023 (UTC)
8.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Support --Looney Toons (talk) 21:42, 9 February 2023 (UTC)
10.  Support Pppery (talk) 23:37, 9 February 2023 (UTC)
11.  Support --Imamy (talk) 05:22, 10 February 2023 (UTC)
12.  Support Should be obvious. -- Soukupmi (talk) (✔) 13:55, 26 February 2023 (UTC)
13.  Support Per the comments above, this should be the obvious case.| -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Oppose (10)

1.  Weak oppose 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)
2.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:08, 5 March 2023 (UTC)

Abstain (10)

1.  Abstain per Collei. --Átkýv L. (talk) 20:26, 9 February 2023 (UTC)

Comments (10)

Changes from m:Local_elections:

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.

--NotAracham (talk • contribs • global) 03:39, 8 February 2023 (UTC)

Proposal 10, Amendment 1

Adds the following clause to Proposal 10

"In lieu of a local election, an active wiki community falling 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.

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.

--NotAracham (talk • contribs • global) 18:41, 8 February 2023 (UTC)

Support (10 A1)

1.  Support as proposer --NotAracham (talk • contribs • global) 18:41, 8 February 2023 (UTC)
2.  Support 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.  Support per Reception123 - CabraComunista (talk) 19:44, 8 February 2023 (UTC)
4.  Support 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.  Support Thanks - BrandonWM (talk • contributions • global • rights) 05:04, 9 February 2023 (UTC)
6.  Strong support Same as others. We shouldn't require wikis to become bureaucracies. Collei (talk) 16:18, 9 February 2023 (UTC)
7.  Support --Átkýv L. (talk) 20:27, 9 February 2023 (UTC)
8.  Support --Looney Toons (talk) 21:43, 9 February 2023 (UTC)
9.  Support Pppery (talk) 23:38, 9 February 2023 (UTC)
10.  Support Most definitely support because in a small tight knit community, they generally designate every member of their party to handle one specific role. It would not be unusual where they have already determined which member of their party will succeed the dormant bureaucrat. This person is usually their best representative to fill out that role. --Imamy (talk) 05:29, 10 February 2023 (UTC)
11.  Support As Imamy already said. -- Soukupmi (talk) (✔) 13:58, 26 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.  Support Once again, it wouldn't make sense to demand elections in an underdeveloped community. Reception123 (talk) (C) 12:06, 7 February 2023 (UTC)
2.  Support 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#Other access) 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.  Weak support 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.  Support This is already policy in m: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)

6.  Support for the same reason as Proposal 7 - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
7.  Support 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)
8.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Support --Átkýv L. (talk) 20:28, 9 February 2023 (UTC)
10.  Support --Looney Toons (talk) 21:43, 9 February 2023 (UTC)
11.  Support Pppery (talk) 23:38, 9 February 2023 (UTC)
12.  Support--Revival (talk) 05:31, 10 February 2023 (UTC)
13.  Support --Imamy (talk) 05:32, 10 February 2023 (UTC)
14.  Support -- Soukupmi (talk) (✔) 13:59, 26 February 2023 (UTC)
15.  Support Seems fine. | -- FrozenPlum (Talk / Email) 19:24, 18 March 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.  Support 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.  Support Per Reception123. Agent Isai ^{Talk to me!} 14:38, 7 February 2023 (UTC)
3.  Support Per Reception123. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Support 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.  Support Good idea Collei (talk) 04:26, 8 February 2023 (UTC)
6.  Support per Reception123 - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
7.  Support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Support --Átkýv L. (talk) 20:29, 9 February 2023 (UTC)
10.  Support --Looney Toons (talk) 21:44, 9 February 2023 (UTC)
11.  Support Pppery (talk) 23:38, 9 February 2023 (UTC)
12.  Support I guess it's only fair that if one can be voted into office, then one can be voted out of office --Imamy (talk) 05:34, 10 February 2023 (UTC)
13.  Support -- Soukupmi (talk) (✔) 14:06, 26 February 2023 (UTC)
14.  Support This seems like a good way to help maintain and ensure fairness and a sober second thought when issues arise in community. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Comments (12.1)

Changes from m:Local_elections

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

--NotAracham (talk • contribs • global) 03:49, 8 February 2023 (UTC) What counts as a "very compelling" reason? Can it be a violation of the specific wiki's posted policies, does it have to be a violation of Miraheze's Terms of Use, or is even that not sufficiently compelling? --Robkelk (talk) 19:07, 9 February 2023 (UTC)

Very compelling in an emergency situation would be like they're blocking users/abusing their rights egregiously, harassing others/sending threats, sabotaging the wiki, vandalizing, etc. If the bureaucrat engaged in some conduct which violates local wiki policy or is unbecoming of them and if they're not actively a disruption or issue, the vote should take its course first and they should be demoted by a Steward in order to prevent any challenges to the legitimacy of an action/have it be contested. Agent Isai ^{Talk to me!} 19:13, 9 February 2023 (UTC)

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.  Support 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.  Support Per Reception123. Agent Isai ^{Talk to me!} 14:38, 7 February 2023 (UTC)
3.  Support 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.  Support 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)

6.  Support 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)
7.  Weak support 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)
8.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Weak support per DeeM28. --Átkýv L. (talk) 20:30, 9 February 2023 (UTC)
10.  Weak support--Revival (talk) 05:31, 10 February 2023 (UTC)
11.  Support I'll support. Sounds like this has more to do with trying to keep control of wiki in the hands of the community. Sometimes, leadership is blind. I would not want to be voted out but sometimes this could be the only wake up call. It's not like I can't reform myself to get back into the good graces of the community. Sometimes people become better leaders after making a few mistakes. — Preceding unsigned comment added by Imamy (talk • contribs)
12.  Support -- Soukupmi (talk) (✔) 14:07, 26 February 2023 (UTC)
13.  Support This is another very good step in the preservation of fairness on a wiki. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Oppose (12.2)

1.  Oppose This creates an obvious double standard; if the community comes to sufficient consensus as defined by the previous proposals to strip such a person of their rights, I don't see why they should be stopped from doing so. Pppery (talk) 23:39, 9 February 2023 (UTC)

   they may only be removed as administrator or bureaucrat if there is a very good and genuine reason for doing so - I'd assume that a consensus is a very good and genuine reason. Collei (talk) 06:02, 12 February 2023 (UTC)

2.  Oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:06, 5 March 2023 (UTC)

Abstain (12.2)

1.  Abstain --Looney Toons (talk) 21:47, 9 February 2023 (UTC)

Comments (12.2)

Same question as under 12.1 - what counts as "compelling"? --Robkelk (talk) 19:10, 9 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.  Support Has happened in the past, best to have it clarified. Reception123 (talk) (C) 12:08, 7 February 2023 (UTC)
2.  Support 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.  Support Status quo. Thanks - BrandonWM (talk • contributions • global • rights) 01:33, 8 February 2023 (UTC)
4.  Support 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.  Support Collei (talk) 04:29, 8 February 2023 (UTC)
6.  Support per Agent Isai - CabraComunista (talk) 10:03, 8 February 2023 (UTC)
7.  Support 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.  Support I support by joining the community. Best Regards, Hey Türkiye ^Message? 12:07, 8 February 2023 (UTC)
9.  Support --Átkýv L. (talk) 20:32, 9 February 2023 (UTC)
10.  Support --Looney Toons (talk) 21:48, 9 February 2023 (UTC)
11.  Support Pppery (talk) 23:40, 9 February 2023 (UTC)
12.  Support --Imamy (talk) 05:55, 10 February 2023 (UTC)
13.  Support Wow. Wouldn’t have thought this necessary but it makes total sense come to think about it. Good to have it spelled out. -- Soukupmi (talk) (✔) 14:17, 26 February 2023 (UTC)
14.  Support This also seems wise, I could imagine this occurring, sadly, but separation in this case would make perfect sense. | -- FrozenPlum (Talk / Email) 19:24, 18 March 2023 (UTC)

Comments (13)

1. How do you define "equally represented"? Redmin Contributions CentralAuth (talk) 17:42, 19 March 2023 (UTC)

---

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