Requests for Comment/Requests for Comment

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

This RfC is interesting in that one theme to come from this is that it either reflects existing status quo, as defined by various policies, or, in some cases, codifies what has already been user convention or generally accepted best practices. Accordingly, it is closed as follows:

• Proposal 1: Passes in the sense that it states what was already the reality
• Proposal 1.1: Passes as codification of what has been a generally accepted best practice or convention by Meta users and, in particular, by many Meta administrators and patrollers. The community resoundingly endorses drafting RfCs, typically as subpages of one's user space and then discussing on the companion talk page, before moving them to Requests for Comment space, and effectively codifies a generally accepted best practice by many Meta patrollers and administrators to move such proposals that are either malformed, conflicts in some way with existing policies, or is otherwise overly vague, to such location, then request deletion of the trailing redirect.
• Proposal 2: Though the yeas appear to have the stronger arguments, given the number of participants to the discussion, there is no consensus, as of yet, for its passage. There is no consensus against this proposal, either. This is one of the reasons why drafting RfCs is strongly recommended and now resoundingly endorsed by the community.
• Proposal 2.1: Though there appears to be a weak consensus in favour here, and though it could have been a proposal independent of Proposal 2, it's, nonetheless, unclear on whether the proponents intended it to be a standalone proposal or not. Thus, it's not implemented, with no prejudice against potentially proposing it, perhaps as a standalone proposal, down the road.
• Proposal 2.2: Does not pass, as no consensus and an emerging weak consensus against the proposal, with dross appearing to have the strongest argument in the discussion
• Proposal 3: With 10 users supporting or conditionally supporting and 10 users opposing this proposal, the yeas appear to have made the stronger arguments here. While there is no consensus against this proposal, there is also no consensus in favour of it, either, largely per the reason for Proposal 2 (i.e., low number of participants).
• Proposal 3.1: Firstly, I believe DeeM28 made a typo in their oppose argument. Given their support for Proposal 3, I believe they meant to say they conditionally supported Proposal 3.1 if Proposal 3 was unsuccessful, not if it was successful. There may be a weak consensus in favour of Proposal 3.1; however, given that Proposal 3 has not passed, I have then interpreted this as a conditional support argument, whether by intention or otherwise, all Proposal 3 and Proposal 3.1 is rendered moot and cannot pass because of the wording of Proposal 4 (and 4.1, to be honest) which further codify what has already been codified in Meta and global permissions requests, which is that IP editors may not participate in such user permission requests requiring a vote. As Proposal 4 very clearly states one must hold an account in order to participate in an RfC, IP editors are effectively precluded from participating in RfCs on Meta Wiki (whether global or local RfC) as IPs are not accounts, they, therefore, cannot participate. This, however, does not mean they cannot either (a) create an account or (b) login and either edit the logged out signature and replace it with a logged in signature or re-add the same comment (if it had already been removed by a patrolling user), provided they have not already !voted on that particular proposal of said RfC. In this way, this reflects a codification of what had already been a generally accepted best practice or convention by many Meta patrollers and administrators with respect to participation by IP editors in RfCs.
• Proposal 4: Passes. Participants in RfCs must hold a user account, in accordance with this RfC and user accounts policy, a global suprapolicy, in order to express a view in an RfC. As per my closing comments in regards to Proposal 3.1, this does not preclude a logged out or otherwise unregistered user from logging in or creating an account, in accordance with user accounts policy of course, and either editing the signature of the IP to replace it with the signature of the logged in user account or re-adding the same comment but logged in.
• Proposal 4.1: Passes, albeit with a bit weak consensus.
• Proposal 5: Passes unanimously, as largely a codification of the status quo. If undiscussed or non-drafted RfCs are in any way unclear, vague, or malformed, rather than immediately !voting, users, and especially Meta patrollers and administrators, should either (a) tag it for deletion or, where possible, (b) move it to a subpage of the initiating user's own userspace for drafting, ideally with an accompanying note on the user's user talk page.
• Proposal 5.1: Does not pass, as a counter-proposal to Proposal 5. See closing comments above.
• Proposal 6: Passes, with an administrative note that, given the community has resoundingly endorsed drafting RfCs, if !voting has already begun, users should, ideally, initiate a discussion on the companion talk page of the RfC to see if there is consensus to add an additional proposal. While not mandatory, procedurally, they must notify previous participants of the late stage added proposal, as many previous participants treat their participation as a "one and done" and do not expect that new proposals, especially counter-proposals, would be added at a later stage. A {{ping}} is generally regarded as insufficient notification for this purpose.
• Proposal 6.1: Does not pass, as a counter-proposal to Proposal 6.
• Proposal 7: Passes, with a note to Arcversin's comment that, since this proposal is a bit vague, the list of exemptions for early closure is therefore interpreted as non-exhaustive and there may be other reasons for early closure, including, but not limited to, Steward or Meta bureaucrat discretion, as applicable, or the results of related proposals above.
• Proposal 7.1: This could have been an independent proposal, potentially, and there would appear to be a weaker consensus in its favour; however, it is not implemented for two reasons. For one thing, it was specifically stated that it is contingent on Proposal 2's passage. With Proposal 2 not passing, it is, therefore, not passed. For another thing, much of its stated aims have been implemented by related proposals above and below.
• Proposal 7.2: No consensus for or against this proposal, with a note that dross's comment below was perhaps the strongest argument and the stated aims of this proposal have been implemented by proposal closing comments further up.
• Proposal 7.3: Passes and largely implements the stated aims of Proposal 2 and Proposals 7-7.2 (inclusive), which did not pass, by codifying my closing comments in the proposals above. I would just administratively add that this is not limited to Stewards moving or deleting vague, unclear, or malformed good-faith proposals. Any Meta administrator or experienced user with a good understanding of both the Miraheze global and Meta Wiki local policies and how they mesh together may either (a) tag for deletion or (b) userfy such RfCs. There's no need to limit this to Stewards; however, if absolutely unsure, they should either defer to a Steward or Meta bureaucrat, as applicable, or at least confer with the same, prior to initating that move, though in such cases, rather than tagging for deletion, the patrolling user might perhaps want to add {{admin help}} at the top of the unclear or vague RfC, with a comment immediately below that makes it known to users not to !vote in the RfC and that clarification from a Meta administrator or Steward has been requested.
• Proposal 8: Passes, as essentially codification of what had largely been a status quo convention, and notwithstanding similar proposals (including Proposal 7.3) that provide for such RfCs to userfied or deleted.
• Proposal 9: Passes as a statement of the obvious and reiteration of what was already the case.
• Proposal 10: Passes, though probably should have been a separate Meta Wiki RfC, but no one has stated an opposing view this, given that an existing Meta bureaucrat has co-proposed this proposal and agrees there is consensus here, and that the proposal itself provides for limited circumstances in which Stewards may close Meta Wiki RfCs (which Reception123 articulated in reply to Magogre), it seems a bit bureaucratic to have to request separate closure of Proposal 10 Meta:Administrators' noticeboard. No prejudice against a Meta bureaucrat affirming this closure by way of an added note.

-- Dmehus (talk) 02:28, 7 February 2022 (UTC)

---

Since the Miraheze community was created, Requests for Comment have never had any particular set rules and are currently based on convention and discretion solely. Following a discussion in a Miraheze Meeting where several users expressed support for some of my ideas (and proposed ideas of their own) it seems right not only to codify some existing conventions (which can be unclear) but also to add some new rules. This is to ensure that RfCs are created appropriately and to avoid situations where RfCs are out-of-scope, created rashly without much thought given, too vague, etc. which usually end up being opposed. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)

Co-initiator signature: Agent Isai ^{Talk to me!} 06:55, 2 February 2022 (UTC)

Note: Due to the amount of proposals, in order to avoid potential edit conflicts, please consider voting for each section separately

Proposal 1 (Definition)

Requests for Comment (RfCs) are the mechanism by which the Miraheze community can discuss and vote on global policy proposals as well as other general matters pertaining to the Miraheze community.

Support (1)

1.  Support as proposer. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support as co-initator. Agent Isai ^{Talk to me!} 15:55, 2 February 2022 (UTC)

   @Agent Isai: I'm not sure if you're really a "co-initiator", as I've only seen one user talking about the idea. Still put the signature. --YellowFrogger (talk) (✔) 16:01, 2 February 2022 (UTC)

3.  Support --YellowFrogger (talk) (✔) 15:57, 2 February 2022 (UTC)
4.  Strongest support I couldn't agree more. --DarkMatterMan4500 (talk) (contribs) 16:05, 2 February 2022 (UTC)
5.  Support Appears to be an appropriate definition of what an Request for Comment is. --DeeM28 (talk) 18:08, 2 February 2022 (UTC)
6.  Support We need rules to simplify things. Tali64³ (talk) 19:42, 2 February 2022 (UTC)
7.  Support - Agreed, makes sense and feels appropriate. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
8.  Strongest support RFCs are the easiest way to organize the community for voting so I agree heavily here TigerBlazer (talk) 20:17, 2 February 2022 (UTC)
9.  Support, though I feel a touch redundant given the unanimous nature of support so far. --Raidarr (talk) 21:46, 2 February 2022 (UTC)
10.  Support — Arcversin (talk) 22:29, 2 February 2022 (UTC)
11.  Support Definition makes sense to me Soukupmi (talk) 00:16, 3 February 2022 (UTC)
12.  Strong support It makes sense and it is a more proper definition King Dice (talk) 01:34, 3 February 2022 (UTC)
13.  Support --Magogre (talk) 02:36, 3 February 2022 (UTC)
14.  Support RFCs will make senses in the future. --TriNguyen12348 (talk) 04:42, 3 Febuary 2022 (UTC)
15.  Support  Anpang📨  06:33, 3 February 2022 (UTC)
16.  Support Because this is the only method to achieve broad agreement on a proposal, and because this definition is well-written. --  Joseph  TB  CT  CA  08:13, 3 February 2022 (UTC)
17.  Strongest support Couldn't have said it better. --Firestar464 (talk) 09:59, 3 February 2022 (UTC)
18.  Support This seems an appropriate definition. 77topaz (talk) 17:06, 3 February 2022 (UTC)
19.  Support Completely agree! Markymark (talk) 17:08, 3 February 2022 (UTC)
20.  Support I like this definition. HydraTriangle (talk) 01:17, 4 February 2022 (UTC)
21.  Support Absolutely. MoxieOnline (talk) 14:54, 5 February 2022 (UTC)
22.  Support all has already been said above
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:07, 5 February 2022 (UTC) ］ |

Proposal 1.1 (Definition)

If the Miraheze community wishes to express a general recommendation, that may be done via a Feedback Requests (FRs) that will take place on the Community noticeboard, these are non-binding expressions of current opinion or interpretations of policy. An example of non-binding opinion/recommendation would be to recommend a certain action to be taken by SRE. Feedback Requests may also be used for single-issue policy amendments or clarifications.

Support (1.1)

1.  Support as proposer. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support as co-initiator Agent Isai ^{Talk to me!} 15:56, 2 February 2022 (UTC)
3.  Support He was responsible for the Purge and WikiSeo extension. --YellowFrogger (talk) (✔) 15:59, 2 February 2022 (UTC)
4.  Support Makes sense. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
5.  Support as a useful concept. I feel the wording is a touch clunky, but not unserviceable and more importantly, not problematic. --Raidarr (talk) 21:48, 2 February 2022 (UTC)
6.  Support — Arcversin (talk) 22:29, 2 February 2022 (UTC)
7.  Support Good to differ those 2. Soukupmi (talk) 00:17, 3 February 2022 (UTC)
8.  Support  Anpang📨  06:33, 3 February 2022 (UTC)
9.  Strongest support Oh absolutely. --DarkMatterMan4500 (talk) (contribs) 17:43, 3 February 2022 (UTC)
10.  Strongest supportThis is the most reasonable thing to do. TigerBlazer (talk) 22:22, 3 February 2022 (UTC)
11.  Support +1 agreement. --Raidarr (talk) 20:31, 4 February 2022 (UTC)
12.  Support -- MoxieOnline (talk) 14:56, 5 February 2022 (UTC)
13.  Support
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:08, 5 February 2022 (UTC) ］ |

Proposal 2 (Initiation)

In order to initiate a Request for Comment, the user proposing the Request for Comment must have at least one other user who is willing to co-initiate the Request for Comment. When the Request for Comment is published, the co-initiating user should be mentioned after the introductory statement and should sign themselves before voting begins (signing as co-initiator can also be done during the drafting process).

(Rationale: The rationale behind the co-initiator rule is to allow at least one other user to review the RfC in order to ensure that it's appropriate, written properly, etc. and to avoid situations when a user creates an RfC with little thought behind it. As with main initiators, a co-initiator does not have to support all (or any of) the proposals, they are just there to ensure that the RfC is adequately presented)

Support (2)

1.  Support While this rule does impose a small restriction on initiating RfCs, I think it's necessary in order to allow someone else to review an RfC and make sure that thought has been put into it and that what is being proposed is clear. Of course, it's always possible for two users to also open an inadequately worded RfC, but the risk is less. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support 100% per Reception123. Agent Isai ^{Talk to me!} 16:00, 2 February 2022 (UTC)
3.  Weak support While this is clearly a tough burden on users who do not have many connections at Miraheze I nonetheless weakly support it. In order to keep Requests for Comment serious and to not have the page flooded with requests which are not appropriate I agree that it is necessary to have an extra requirement in order to make sure that newcomers do not too quickly create RfCs without understanding the mechanism. A more flexible approach could have been sought however this current solution seems appropriate nonetheless as statistically speaking I am not aware of a successful RfC that has come from a new user with no connections so far and I think that is the case for obvious reasons. --DeeM28 (talk) 18:12, 2 February 2022 (UTC)
4.  Strongest support Absolutely. This should be encouraged. --DarkMatterMan4500 (talk) (contribs) 19:07, 2 February 2022 (UTC)
5.  Weak support - seems appropriate for helping to encourage appropriate proposals.| -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support as the codification of a proven rule for successful RfCs, and a useful mechanism to bring gravity to the process while reducing time spent on proposals that are obliged a level ofattention from voters and a reviewing Steward that was not given to them before they were posted. An unconfident, unconnected user who is ultimately unable to get direct support (which by definition here, is not a high bar and doesn't necessarily need to come from a renowned user/native of Meta) can still bring up the idea informally, and if it stands a fair shot it will likely be picked up one way or another. A serious proposal should muster this very minimal degree of support given the process's consequences, power on Miraheze/Meta and attention involved. --Raidarr (talk) 21:54, 2 February 2022 (UTC)
7.  Weak support Hard for those with few connections but I see the point into this. Soukupmi (talk) 00:20, 3 February 2022 (UTC)
8. Frankly, raidarr expresses my thoughts about as well as I possibly could. Even off-wiki, real world applications allowing lone initiators are rare. Users have several avenues to establish rapport for their proposal(s), and there is plenty of opportunity to attract collaborators or co-initiators. Lack of interest in co-initiation should not indicate a broken system, but instead should prove the need to either refine a proposal to gain community interest, or attempt to collaborate from the start without maintaining a stranglehold on the original idea. dross (t • c • g) 02:03, 5 February 2022 (UTC)
9.  Support same opinion as darkmatterman.--アンジェロ先輩 (talk) 10:40, 5 February 2022 (UTC)
10.  Support this would achieve having higher quality RfCs, and prevent to many invalid scope ones.
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:09, 5 February 2022 (UTC) ］ |

Oppose (2)

1.  Oppose I think this should be encouraged but not obligated. Jakeukalane (talk) 18:59, 2 February 2022 (UTC)
2.  Oppose While we should encourage this, I am reluctant to formally require it. — Arcversin (talk) 22:31, 2 February 2022 (UTC)
3. No. An RFC created by multiple people is never something I was comfortable with in the first place, and it is surely a terrible idea to require it. Snowball RFCs can be solved with other better ways, like not requiring Stewards to close snowball RFC. But not this. It's a terrible idea and prevents people from starting RFCs, requiring something that arguably shouldn't even exist. Naleksuh (talk) 00:35, 3 February 2022 (UTC)

   How is an RfC created by multiple people a bad thing? By drafting an RfC in advance and allowing other users to make edits and add their proposals, an RfCs quality is improved and I don't really see what 'cons' exist to having an RfC worked on by multiple people. Reception123 (talk) (C) 06:13, 3 February 2022 (UTC)

4.  Oppose per Jakeukalane. I don't think this should be made necessary to initiate an RfC. Magogre (talk) 02:47, 3 February 2022 (UTC)
5.  Oppose After Reception said that if I vote support for this one, I would have to vote support for 7.1. Less bureaucracy. I remembered to move now. Weak support Maybe avoid snowballing, but this one is more personal and feels more like a recommendation than a rule. --YellowFrogger (talk) (✔) 16:03, 2 February 2022 (UTC)

   It being a recommendation would arguably defeat its rationale which is to encourage discussion with someone else prior to opening an RfC. Reception123 (talk) (C) 16:05, 2 February 2022 (UTC)

6.  Oppose What's the need anyways...  Anpang📨  06:33, 3 February 2022 (UTC)

   The need (or at least why I am proposing this) has been explained above. It is to avoid people opening RfCs with little thought or that are too vague or badly written which never end up getting anywhere and waste time. Reception123 (talk) (C) 06:35, 3 February 2022 (UTC)

7.  Oppose This is a valid proposal, but it should be a suggestion rather than an obligatory need for an RfC. --  Joseph  TB  CT  CA  08:19, 3 February 2022 (UTC)
8.  Oppose I concur with the above objections TheDungeonMaster (talk) 13:13, 3 February 2022 (UTC)
9.  Oppose I think this should be encouraged but not mandated, given that some users may have few connections as Soukupmi mentions. 77topaz (talk) 17:02, 3 February 2022 (UTC)
10.  Oppose: Can be recommended but not required, as stated by many others. Firestar464 (talk) 03:28, 4 February 2022 (UTC)
11.  Oppose This may be a decent recommendation (and I would like others to help with this draft on dormancy and closure), but requiring it is ridiculous. It would be unfriendly to people who want to make a change to this wikifarm, as it's better for it to be simple to participate and not bureaucratic. K599 (talk) 00:24, 5 February 2022 (UTC)
12.  Oppose - Can be recommended but not required, as stated by many others. Kourouklides (talk) 00:47, 5 February 2022 (UTC)

Proposal 2.1 (Initiation)

If a user is unable to find a co-initiator, they can instead request that a Steward or local Meta administrator reviews their drafted Request for Comment and signs-off on it.

(Rationale: The rationale behind this is in case a new user is not able to find a co-initiator and they should not be prevented from creating a Requests for Comment and should have an alternative path to RfCs)

Support (2.1)

1.  Weak support While I see no problem with this idea, wouldn't asking a Steward or Meta administrator to 'sign-off' be the same as asking any user to co-initiate? The reason why I'd weakly support this is merely to make it clear to new users that they can ask Stewards or Meta sysops if they can't find anyone else. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support I agree with Reception123 that this should not be seen as anything special, just as an aid for newer users to know that they can ask a Steward/sysop to co-initiate an RfC. Since co-initiation != support, really anyone can co-initiate an RfC even if they don't support it's contents just as a gesture to affirm that they've verified that the user has not submitted a frivolous RfC. Agent Isai ^{Talk to me!} 16:05, 2 February 2022 (UTC)
3.  Support In order to alleviate the toughness imposed by Proposal 2.0 this proposal will allow new users who wish to present a well-formed RfC to be able to by having a Steward review their 'work' prior to publication. --DeeM28 (talk) 18:13, 2 February 2022 (UTC)
4.  Support - This makes perfect sense in combination with proposal 2.0 to make it feasible/accessible for users who don't have co-supporters, which appears to be its intent. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
5.  Support Yep, now the eremits also have a chance. Soukupmi (talk) 00:22, 3 February 2022 (UTC)
6.  Support - This makes perfect sense in case Proposal 2.0 is eventually successful. Kourouklides (talk) 00:51, 5 February 2022 (UTC)

Oppose (2.1)

1. I am placing an  Oppose because I think the process as initially outlined is more than flexible enough to work without giving an out of finding a different kind of co-initiator. Frankly, I don't think it's tough. It is as tough as it should be. An idea that cannot drum up support from parties per above is an idea that probably has issues and should be raised in spitball through another medium such as CN, where if it has merit a co-initiator may be found. Leaving an out that involves an admin or steward in my mind adds a bureaucratic edge for little gain. If it's encouragement for newer users, we should encourage them to collaborate on an idea that other users would be happy to give a chance, sysop, Steward, regular user or otherwise. --Raidarr (talk) 21:59, 2 February 2022 (UTC)
2.  Oppose This just suggests that the best solution is not to require a co-initiator in the first place. TheDungeonMaster (talk) 13:14, 3 February 2022 (UTC)
3.  Oppose To paraphrase Raidarr, this gives the bureaucratic vibes. Firestar464 (talk) 03:30, 4 February 2022 (UTC)
4.  Oppose for the sake of avoiding the breeding of additional bureaucracy on Miraheze. We should not be adding systems which add more bureaucracy while in the course of revising currently bureaucratic systems and standards. dross (t • c • g) 02:07, 5 February 2022 (UTC)

Abstain (2.1)

1.  Abstain --DarkMatterMan4500 (talk) (contribs) 15:38, 3 February 2022 (UTC)
2.  Abstain--アンジェロ先輩 (talk) 10:40, 5 February 2022 (UTC)
3.  Abstain What's the difference between this and the above proposal (2.0). A Steward is a user, so regardless this is part of that in my opinion.
   —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:12, 5 February 2022 (UTC) ］ |

Comments (2.1)

• Similar to above as mentioned by user. This is worse because we only have 3 stewards, they will hardly respond. --YellowFrogger (talk) (✔) 16:07, 2 February 2022 (UTC)

  The proposal indicates that "If a user is unable to find a co-initiator", so this does not require them to find a Steward, it is only an option they could use in the event that they are unable to find another regular user. Reception123 (talk) (C) 16:16, 2 February 2022 (UTC)

Proposal 2.2 (Autopatrolled RfC creation)

As an alternative to Proposal 2, Autopatrolled (trusted) users may create RfCs without a co-initiator, but a co-initiator is still recommended.

Support (2.2)

1.  Strong support as proposer  Anpang📨  12:15, 3 February 2022 (UTC)
2.  Support This seems like a better alternative to Proposal 2. 77topaz (talk) 17:03, 3 February 2022 (UTC)
3.  Support This is what this community has been lacking for quite some time now. --DarkMatterMan4500 (talk) (contribs) 17:44, 3 February 2022 (UTC) Struck my vote and will move it to oppose instead. --DarkMatterMan4500 (talk) (contribs) 12:29, 5 February 2022 (UTC)

Oppose (2.2)

1. No, anyone can create them without a co-initiator. Also, attaching privileges to autopatrolled is not okay. Autopatrolled users are autopatrolled and that's it. Naleksuh (talk) 23:23, 3 February 2022 (UTC)

   @Naleksuh: Users with autopatrolled are said to be the ones who know the policy, even with the large amount of auto-patrollers we have. It's not that difficult to become an autopatrolled, that's why this proposal. It's good that she would avoid proposals from users like Octahedron, and it would be more affordable than all users not being able to do that. --YellowFrogger (talk) (✔) 23:29, 3 February 2022 (UTC)

2. Anyone should be able to create an RFC without co-initiator or autopatrolled rights. Magogre (talk) 03:20, 4 February 2022 (UTC)
3.  Oppose Per Magogre. Firestar464 (talk) 03:33, 4 February 2022 (UTC)
4.  Oppose for similar grounds as Naleksuh; I think the principle if applied should be applied to all, and if anything the minimal expectation should be even easier for someone 'autopatrolled' (re, considered established) to fulfill the requirement, which is suggested for a qualitative reason that autopatrolled status does not make disappear. --Raidarr (talk) 10:18, 4 February 2022 (UTC)
5.  Oppose For the same reasons I expressed in proposal 2, as this alternative appears to still require a "co-initiator" for people without this role, and that's still unfriendly and bureaucratic to people for the same reasons. K599 (talk) 00:24, 5 February 2022 (UTC)
6.  Oppose - for similar grounds as stated by the aforementioned users. Kourouklides (talk) 00:56, 5 February 2022 (UTC)
7. Permissions ≠ rights. Wiki permissions should not grant rights. Rights are determined by community trust, and should not depend on access level. dross (t • c • g) 02:11, 5 February 2022 (UTC)
8.  Oppose I struck my above vote for support and moved my vote to oppose instead because literally any registered user can make an RfC as long as it's not disruptive or utter nonsense. --DarkMatterMan4500 (talk) (contribs) 12:30, 5 February 2022 (UTC)

Comments (2.2)

• You will find that many of the oppose not-votes for (2) express implicit support for this (2.2). The lack of feedback is probably because it was not made clear that a choice between 2 and 2.2 was offered. TheDungeonMaster (talk) 13:15, 3 February 2022 (UTC)

  I don't see what you are saying in the opposition votes (the trend there is 'recommend, don't require' while this introduces classism to a requirement), and it is also worth noting that 2.2 was suggested after the proposal was begun. --Raidarr (talk) 10:19, 4 February 2022 (UTC)

Proposal 3 (Voting)

Only registered users may initiate or vote in Requests for Comment. Unregistered users (IP editors) may not participate (i.e. comment) or vote in Requests for Comment.

Support (3)

1.  Support if Proposal 3.1 doesn't pass. Agent Isai ^{Talk to me!} 16:08, 2 February 2022 (UTC)
2.  Support I do not see a reason for why allowances to users who are not registered must be made. On most websites that exist anonymous participation is not possible and user registration is required. In my view if an unregistered editor wants to participate in a Request for Comment they should create an account. Since creating an account does not even require an email there is no reason for why it should be difficult for someone to do so. Even if Proposal 3.1 allows comments only these comments can still very well influence other users and this influence may be undo if the IP/unregistered user is actually someone who is abusing multiple accounts. --DeeM28 (talk) 18:16, 2 February 2022 (UTC)

   In my view if an unregistered editor wants to participate in a Request for Comment they should create an account. There's a proposal right here that doesn't allow new accounts to vote after creating an account after the RfC. --YellowFrogger (talk) (✔) 18:20, 2 February 2022 (UTC)

3.  Support also if Proposal 3.1 doesn't pass. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
4.  Support as a somewhat heavy alternative to 3.1 that I believe isstill better than leaving a loop for unregistered votes to count and the potential issues that arise from such votes. Those invested enough to vote I believe should have no reason not to partake with an identity that an account provides, though registration status does not matter to me if comments are valid. --Raidarr (talk) 22:04, 2 February 2022 (UTC)
5.  Support Prefer the 3.1 But it's okay. Soukupmi (talk) 00:25, 3 February 2022 (UTC)
6.  Strongest support I don't know why I even opposed without even double-checking, but IPs are NEVER to vote, or make RfCs, not even in a million years. Allow IPs to vote or make RfCs? Not on my life, and we won't allow it, at all. --DarkMatterMan4500 (talk) (contribs) 16:46, 4 February 2022 (UTC)

   I don't support that IPs can vote, I support that at most they should comment and report (especially about such a candidate). --YellowFrogger (talk) (✔) 17:50, 4 February 2022 (UTC)

7.  Strongest support is this a joke, if a user uses proxies he can vote x times--アンジェロ先輩 (talk) 10:42, 5 February 2022 (UTC)

   @アンジェロ先輩: Of course not. The proxies we discover, while actually we support that just an IP only comments. If it was a joke, there wouldn't be so many opposes, and if we see a typically Proxy IP voting several times it's very easy to find out. --YellowFrogger (talk) (✔) 18:26, 5 February 2022 (UTC)

8.  Strongest support only if Proposal 3.1 is unsuccessful.
   —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:17, 5 February 2022 (UTC) ］ |

Oppose (3)

1.  Strongest oppose. Unregistered editors should at most comment. Before I could. See: W:WP:IPHUMAN --YellowFrogger (talk) (✔) 16:08, 2 February 2022 (UTC)
2.  Oppose. Unregistered editors are also valuable.Jakeukalane (talk) 17:53, 2 February 2022 (UTC)
3.  Oppose IPs shouldn't have their comments discredited. — Arcversin (talk) 22:32, 2 February 2022 (UTC)
4.  Oppose Prefer 3.1  Anpang📨  06:33, 3 February 2022 (UTC)
5.  Oppose why would you do this? what is gained by creating two classes of Miraheze citizens? The proposal does not even try to justify the proposal, so how about we simply say "no" without bothering to justify our answer? A better more direct and openly honest path forward (for the initiator) would be to simply suggest disabling write access for IP visitors, to make Miraheze another wiki where IP editing is disabled outright. In short: either we welcome IP editors or we don't. Nothing is gained by creating a class of users without "voting" rights. (Had it been about counting votes then of course it would have been necessary to restrict IP voting. But it isn't) TheDungeonMaster (talk) 13:20, 3 February 2022 (UTC)
6.  Oppose Proposal 3.1 seems fairer. 77topaz (talk) 16:58, 3 February 2022 (UTC)
7.  Weak oppose --DarkMatterMan4500 (talk) (contribs) 17:46, 3 February 2022 (UTC) Struck my opposing vote, and will move it to {{support}} instead. --DarkMatterMan4500 (talk) (contribs) 16:43, 4 February 2022 (UTC)
8.  Strongest oppose See w:WP:IPHUMAN. Firestar464 (talk) 03:35, 4 February 2022 (UTC)
9. Remember the human. What is the difference between the person(s) behind an anonymous user and the person(s) behind a registered user beyond technicality? dross (t • c • g) 02:22, 5 February 2022 (UTC)
10.  Oppose They should at least be able to comment. MoxieOnline (talk) 15:11, 5 February 2022 (UTC)

Comments (3)

1. I conditionally  Support this proposal if Proposal 3.1 is not successful. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2. I conditionally  Support this proposal if Proposal 3.1 is not successful. Otherwise, if Proposal 3.1 is successful, then I  Oppose. Kourouklides (talk) 01:01, 5 February 2022 (UTC)

Proposal 3.1 (Voting)

Only registered users may initiate or vote in Requests for Comment. Unregistered users may participate in Requests for Comment by way of comments, but these will not ultimately be taken into account when deciding consensus and will not count as 'votes'.

NOTE: This proposal is an alternative to Proposal 3, with Proposal 3.1 allowing unregistered users to comment in RfCs.

Support (3.1)

1.  Support I think it is fair to allow IP editors to express their views as long as their votes are not ultimately counted, mostly due to User accounts policy concerns. It's really easy to create an account so this shouldn't be imposing much of a restriction on anyone who wishes to vote. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)

   Then again it isn't votes and it is not about majority rule, so IP votes aren't counted anyway. (Hint: It's request for Comments, not Request for Votes) TheDungeonMaster (talk) 13:24, 3 February 2022 (UTC)

2.  Strong support Nothing good has ever come out from an RfC created by IP users. Without a user account, it is very easy for anyone to use their home IP, work IP, school IP, coffeeshop IP, etc. to cast multiple votes. I could see a potential use case in which unregistered users may want to comment but allowing them to start/vote on RfCs, I would say no due to their long history of unhelpfulness and due to potential abuse. Agent Isai ^{Talk to me!} 16:42, 2 February 2022 (UTC)

   Cast as many phony "votes" you like, it won't help your RfCs. Sockpuppeteering is already prohibited. TheDungeonMaster (talk) 13:24, 3 February 2022 (UTC)

   It's unacceptable to rig votes by resorting to sockpuppetry. PERIOD. --DarkMatterMan4500 (talk) (contribs) 23:26, 3 February 2022 (UTC)

3.  Support I remember voting here before, my vote was lost due to editing conflict before I think. Finally, IPs can express opinions about the case (especially with the candidate). --YellowFrogger (talk) (✔) 17:29, 2 February 2022 (UTC)

   Yeah, had voted before, accidentally removed? : Special:Diff/233572 --YellowFrogger (talk) (✔) 17:33, 2 February 2022 (UTC)

4.  Support IPs are people, too. Tali64³ (talk) 19:44, 2 February 2022 (UTC)

   that is why you would comment "decline". Supporting this measure means IP are *not* people. TheDungeonMaster (talk) 13:24, 3 February 2022 (UTC)

   Not really, because opposing this measure would bar IPs from commenting on RFCs, which would restrict their rights. Also, didn't you accuse Agent Isai of sockpuppetry? Tali64³ (talk) 17:33, 4 February 2022 (UTC)

5.  Strong support - This makes perfect sense to having trustworthy voting and preventing abuse as others have mentioned.| -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support; so long as the comment is constructive I have zero issue permitting unregistered users (for whatever reason that they are unregistered at that point) to comment. --Raidarr (talk) 22:01, 2 February 2022 (UTC)
7.  Support Yes, let them comment but not vote. Soukupmi (talk) 00:26, 3 February 2022 (UTC)
8.  Strong support  Anpang📨  06:33, 3 February 2022 (UTC)
9.  Support IPs may, at the very least, be able to constructively remark on RfC, as the proposal states. --  Joseph  TB  CT  CA  08:27, 3 February 2022 (UTC)
10.  Support This seems like a good balance, allowing unregistered users to comment but not sway voting counts with potential sockpuppeting. 77topaz (talk) 16:59, 3 February 2022 (UTC)
11.  Strongest support This makes sense, as this version of the proposal does allow us to see an outsider's perspective on how Miraheze works. TigerBlazer (talk) 15:11, 4 February 2022 (UTC)
12.  Strongest support I would never let any IP editors even vote on any of the wikis I operate. Using an IP to create or vote (and make several accounts in order to rig it) will only get their vote(s) struck down. I 100% support this, no matter what. --DarkMatterMan4500 (talk) (contribs) 16:49, 4 February 2022 (UTC)
13.  Support - for similar grounds as stated by the aforementioned users. Kourouklides (talk) 01:06, 5 February 2022 (UTC)
14.  Strong support they cannot vote, but commenting yes.--アンジェロ先輩 (talk) 10:44, 5 February 2022 (UTC)
15.  Support MoxieOnline (talk) 15:14, 5 February 2022 (UTC)
16.  Support
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:17, 5 February 2022 (UTC) ］ |

Oppose (3.1)

1.  Oppose Per my support of Proposal 3 I do not support allowing unregistered editors to comment because comments are perfectly capable of influencing other views. I conditionally support this proposal if Proposal 3 is successful however because I assume the alternative would be to allow unregistered users to vote as well which would be totally unacceptable. --DeeM28 (talk) 18:18, 2 February 2022 (UTC)

   How is it problematic for a person's views to be influenced by an IP editor's comments? It's still their own opinion, unless the IP editor is somehow holding a gun to their head, so if a person's viewpoint changes from getting new information, it doesn't really matter that the one who said it is an IP editor. K599 (talk) 00:24, 5 February 2022 (UTC)

2.  Oppose Unregistered editors can still offer valid reasons to support or oppose a proposal. Furthermore, this proposal doesn't differentiate between unregistered editors and freshly registered editors. —  Arcversin (talk) 22:35, 2 February 2022 (UTC)

   That may be the case, but as far as I have seen it has been extremely rare (or even has never happened) that an good-faith IP editor has voted in an RfC. Please see my comments below for why. Reception123 (talk) (C) 15:57, 3 February 2022 (UTC)

3.  Oppose It's best to treat IP editors exactly as registered editors and not separate the two. TheDungeonMaster (talk) 13:25, 3 February 2022 (UTC)

   Why is that best? As I commented in the other proposal below and as was said in some supporting comments, giving IPs the same weight as users opens up a large risk of multiple voting. It is not that difficult for a user to go to different places and vote from separate IPs, and that would be without consequences. The downsides are that good-faith IP users would be affected, but in reality how many IP users do you think would actually participate in an RfC? If they are so interested in Miraheze's policies, why would they not create an account and become more involved? Reception123 (talk) (C) 15:57, 3 February 2022 (UTC)

   Perhaps you may be interested in w:WP:IPSOCK? Firestar464 (talk) 03:46, 4 February 2022 (UTC)

   IP edits are free to make contributions to Meta or any other Miraheze wiki that allows it. I also supported the proposal which would allow them to make comments on RfCs, I just don't think that their votes should be counted as such due to the risk of sockpuppetry. Once again, I find a situation very rare when someone who hasn't made an account would be so interested in how Miraheze works that they would wish to contribute in an RfC. Reception123 (talk) (C) 07:08, 4 February 2022 (UTC)

4.  Strong oppose See w:WP:IPHUMAN. Firestar464 (talk) 03:36, 4 February 2022 (UTC)
5. Obviously, there is the remember the human factor here. We do already judge users who present opinions based on their position in the use of the platform. Votes have always been considered differently based on whether a user is a reader, a new user, a "power user", a Miraheze veteran, etc. They are also evaluated based on how the role fits into whatever systems, features, or community aspects the proposal or discussion affects. We have also always judged participants based on their contributions across the farm. I see no reason why IPs could not be evaluated just the same. dross (t • c • g) 02:19, 5 February 2022 (UTC)

Comments (3.1)

• There is unclarity involved here due to sloppy language from the initiator: some people cast their non-votes for opposite reasons. I see both "I support 3.1 because it prevents IP editors from initiating RfCs" and "I support 3.1 because it allows IP editors to comment". These two voices are likely on the opposing ends of the spectrum. Just a heads-up to those having to untangle the response. TheDungeonMaster (talk) 13:28, 3 February 2022 (UTC)
  • I have noticed that and apologise that that was made confusing, I did not anticipate the two types of responses when drafting the 19-proposal-long RfC, and it seems neither did the other users that reviewed it and made changes. Reception123 (talk) (C) 15:58, 3 February 2022 (UTC)

Proposal 4 (Voting)

Users may not participate in Requests for Comment with more than a single account, in accordance with the User accounts policy.

Support (4)

1.  Support This proposal is really just here to make things absolutely clear, but this is clearly already the case. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support While it is a violation of the User accounts policy to use multiple accounts to mislead people, this proposal allows for it to be very clear to users that sockpuppetry is against the spirit of Requests for Comment. Agent Isai ^{Talk to me!} 16:15, 2 February 2022 (UTC)
3.  Support This one is very obvious. If the user participates, he must state that the other account is his. I see users gaining rights in RfPs with votes from accounts created hours ago. --YellowFrogger (talk) (✔) 16:19, 2 February 2022 (UTC)
4.  Strongest support Per my statement below. --DarkMatterMan4500 (talk) (contribs) 17:24, 2 February 2022 (UTC)
5.  Support an obvious provision. --DeeM28 (talk) 18:18, 2 February 2022 (UTC)
6.  Strongest support This is necessary, I use multiple accounts to separate my wiki activities but only vote with one per issue to ensure I'm not double-dipping. I see this as entirely necessary for volunteers to verify that proposal votes are fair and users are only voting once per issue! | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
7.  Support This would already be considered abuse of multiple accounts. — Arcversin (talk) 22:36, 2 February 2022 (UTC)
8.  Strong support Should go without saying.Soukupmi (talk) 00:28, 3 February 2022 (UTC)
9.  Strong support Why not?  Anpang📨  06:33, 3 February 2022 (UTC)
10.  Support This is not something that should be encouraged in the first place. --  Joseph  TB  CT  CA  09:29, 3 February 2022 (UTC)
11.  Support Magogre (talk) 09:34, 3 February 2022 (UTC)
12.  Support To keep things simple. This is honestly a tad bit stating the obvious. Firestar464 (talk) 03:49, 4 February 2022 (UTC)
13.  Support - for similar grounds as stated by the aforementioned users. It also acts as a safeguard in the (unlikely) scenario that rules/policies ever allow this. Kourouklides (talk) 01:23, 5 February 2022 (UTC)
14.  Strongest support obviously...--アンジェロ先輩 (talk) 10:47, 5 February 2022 (UTC)
15.  Support MoxieOnline (talk) 15:15, 5 February 2022 (UTC)
16.  Strongest support obviously this can't be allowed. That would definitely compromise vote integrity if it were.
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:19, 5 February 2022 (UTC) ］ |

Oppose (4)

1.  Weak oppose as a heavy handed measure especially paired with 4.1. I appreciate the idea for vote integrity (though that is covered largely by other clauses and by proper Steward review) and to encourage the principle of getting established before partaking in serious decisions, but I do not like the principle of disallowing even comments that add something to the table, especially when I've already voted positively towards comments for unregistered users. --Raidarr (talk) 22:13, 2 February 2022 (UTC)
2.  Weak oppose Should not have to be stated. Already not allowed. TheDungeonMaster (talk) 13:29, 3 February 2022 (UTC)

   @TheDungeonMaster: There is no rule about this. It's just not recommended/allowed. The rules will be able to warn about. --YellowFrogger (talk) (✔) 03:45, 4 February 2022 (UTC)

Proposal 4.1 (Voting)

Users who created their accounts after a Request for Comment has been published may not vote in that Request for Comment. Such users may participate in Requests for Comment by way of comments, but these will not ultimately be taken into account when deciding consensus and will not count as 'votes'.

Support (4.1)

1.  Support As a safeguard against the use of multiple accounts in order to influence the result of an RfC, I think this is necessary. While people opposing may claim that it's not fair because an RfC could run for weeks (or even months) and by then a new user could be involved in the Meta community I think it's nonetheless more important to make sure that RfCs are not inappropriately influenced by multiple account users. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support per Reception123. It is very important to uphold the integrity of Requests for Comment. While most RfCs don't run for too long (at most a few weeks), it is still very important to have such a safeguard so as to prevent the potential abuse that could arise from cases of sock/meatpuppetery. Agent Isai ^{Talk to me!} 16:17, 2 February 2022 (UTC)
3.  Weak support It looks like bureaucracy, but in fact it's actually prevention. --YellowFrogger (talk) (✔) 16:22, 2 February 2022 (UTC)
4.  Strongest support Using multiple accounts in order to rig votes is unacceptable, and those who do so shall have their votes thrown out, and be blocked anyway (This may also be useful for the checkuser tool to be used if there was any form of vote rigging). This should serve as a huge reminder to voters who have multiple accounts to not vote multiple times, and to only vote once. Rigging votes on its own is just disruptive and goes against Miraheze's User accounts policy. --DarkMatterMan4500 (talk) (contribs) 17:23, 2 February 2022 (UTC)
5.  Support Even if this indeed as is suggested above might stop new users of good faith from taking part in Requests for Comment that might take a long period of time in which the new user gets accomodated to Miraheze I think it is necessary to have that minor inconvenience in order to preserve the integrity of the RfC process. --DeeM28 (talk) 18:19, 2 February 2022 (UTC)
6.  Strongest support This also seems necessary to me for the reasons others mentioned above. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
7.  Support, perhaps a small touch weakly when considering that even now and in the spirit of this proposal, the issue this is aimed to circumvent can be largely negated by thorough Steward review of a scenario that seems in any way fishy while this ruling as well as 4.0 adds the dimension of requiring new oversight based on new account age independent of what the account is bringing to the table. I support this at least because the argument the individual brings will still be valid, of course assuming that the individual is a unique identity as stipulated in an above, clearly likely to succeed clause. --Raidarr (talk) 22:10, 2 February 2022 (UTC)
8.  Support Makes sense to know ones way around before voting on stuff. I remember my first vote - I had to double check some things to be able to cast a profound vote. Takes time.Soukupmi (talk) 00:32, 3 February 2022 (UTC)
9.  Weak support I can see both ways here. There is legitimate cases of registering after RfCs begin, but it is also a good safeguard to prevent it.
   —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:21, 5 February 2022 (UTC) ］ |

Oppose (4.1)

1.  Weak oppose as rules creep, I don't see a need to an explicit prohibition of this outside of the User accounts policy. — Arcversin (talk) 22:42, 2 February 2022 (UTC)
2.  Oppose I oppose restricting IP editors and thus oppose this too. TheDungeonMaster (talk) 13:30, 3 February 2022 (UTC)
3.  Oppose I don't understand - in the third proposal section every supporting comment is "Registration is easy, so it's OK to ban IP users from voting/participating. If they want to participate they should make an account." But this would disallow them from participating even if they made an account. CatboyMorgantalk 15:37, 3 February 2022 (UTC)

   That would be the consequence, yes. It may be a contentious proposition but in my view it is necessary in order to prevent multiple account abuse. It is frankly also very unlikely that either an IP user or a new user would start their "Miraheze journey" by immediately voting in an RfC. Without this provision in place, it would be possible for a User A who voted in the proposal to go to their public library or so on, create an account and vote again with no consequence and that would clearly be wrong. Reception123 (talk) (C) 15:54, 3 February 2022 (UTC)

4.  Weak oppose One can just tag the comment as been made with an account with little or no edits outside of the discussion, thus making nearby editors more watchful of anything suspicious. There doesn't need to be an outright ban. See also w:WP:AGF. Firestar464 (talk) 03:52, 4 February 2022 (UTC)

   Tagging is always possible but I don't think it would do much to change how votes are being counted by a Steward. If all comments made by an account with little or no edits outside of the discussion would be tagged and users would be suspicious of them, why is an outright ban not an appropriate way to prevent them? Reception123 (talk) (C) 07:10, 4 February 2022 (UTC)

5.  Oppose This is very unfriendly to new users, as they essentially have no say in any changes to this wikifarm. If sockpuppeting is suspected, then a proper investigation should be done, not blocking with no evidence. K599 (talk) 00:24, 5 February 2022 (UTC)
6.  Oppose - for similar grounds as stated by the aforementioned users. In my subjective opinion, I also find it advantageous for new users to register after a RfC since this might potentially make (some of) them more engaged and active in future RfC and votes than otherwise. So in a sense, it might grow the community and make it more connected together. Kourouklides (talk) 01:15, 5 February 2022 (UTC)

Abstain (4.1)

1.  Neutral  Anpang📨  06:33, 3 February 2022 (UTC)

Comments (4.1)

• Everybody's oppose to (2) should be treated as opposing this as well. Please do not enact (4.1) without taking the outcome of (2) into account. TheDungeonMaster (talk) 13:31, 3 February 2022 (UTC)
  • I'm not sure why that should be the case. Proposal 2 regards co-initiation and does not concern voting by new users or registered users. Reception123 (talk) (C) 15:55, 3 February 2022 (UTC)

Proposal 5 (Drafting)

Users are strongly advised to create a draft Request for Comment before publishing it and opening it to a vote. Users can add their draft RfCs under the appropriate section of the Requests for Comment page and ask the community for feedback. During the drafting stage, there should be minimal discussion about the substantive issues and the focus should be on improving the existing proposals (wording, copyediting, etc.) or adding new proposals.

Support (5)

1.  Support Drafting is clearly helpful and should be encouraged as much as possible. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support I think it is very important for RfCs to be drafted before being submitted to prevent SNOWballs and to prevent the community's time from being wasted unnecessarily with frivolous RfCs but at the same time, there are valid use cases in which drafting may need to be bypassed so I wouldn't want to make this a rigid mandate but instead just an exhortation. Agent Isai ^{Talk to me!} 16:20, 2 February 2022 (UTC)
3.  Support --YellowFrogger (talk) (✔) 16:25, 2 February 2022 (UTC)
4.  Support If Proposal 5.1 is not successful I definitely believe that drafting should be strongly recommended and RfCs opened without prior drafts frowned upon by the community. --DeeM28 (talk) 18:22, 2 February 2022 (UTC)
5.  Support Encouraging good proposal writing, in my opinion, can only be beneficial to serious and clear proposals, which would be greatly appreciated. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support as a reasonable principle. It is also not absolute, nor do I think it has to be so long as a preference for this is clearly expressed and backed by community process per this vote. It also allows flexibility, which I like here. --Raidarr (talk) 22:27, 2 February 2022 (UTC)
7.  Support Drafting is beneficial. — Arcversin (talk) 22:43, 2 February 2022 (UTC)
8.  Support Drafting helps a great deal, especially when dealing with difficult topics. The more people are reviewing it the better. But I don't want it mandatory. Soukupmi (talk) 00:35, 3 February 2022 (UTC)
9.  Support I agreed with Reception123 - TriNguyen12348 (talk) 4:44, 3 Febuary 2022 (UTC)
10.  Support  Anpang📨  06:33, 3 February 2022 (UTC)
11.  Support This makes sense because it will help alleviate unconstructive RfCs and aid in the creation of more constructive RfCs from users who aren't well-versed in basic wiki editing abilities and sorts. --  Joseph  TB  CT  CA  09:33, 3 February 2022 (UTC)
12.  Support per Agent. Magogre (talk) 09:36, 3 February 2022 (UTC)
13.  Support It should be recommended, but not mandatory. 77topaz (talk) 16:54, 3 February 2022 (UTC)
14.  Support Shouldn't be a problem, as long as it progresses in the long run. --DarkMatterMan4500 (talk) (contribs) 17:50, 3 February 2022 (UTC)
15.  Weak support Why not? Firestar464 (talk) 03:56, 4 February 2022 (UTC)
16.  Strongest support Drafting allows the RFC more time to develop and remain constructive, and hopefully allow it to gain the best results when it goes public. TigerBlazer (talk) 15:29, 4 February 2022 (UTC)
17.  Weak support--アンジェロ先輩 (talk) 10:48, 5 February 2022 (UTC)
18.  Support yes, it should be advised, but I'm not sure this proposal even properly fits in an RfCs since it isn't change policy, just advisement, which is already advised most of the time.
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:23, 5 February 2022 (UTC) ］ |
19.  Support Many of the failed RfCs might have been a success if only they were drafted beforehand. In the case of Requests for Comments, prior collaboration and drafting trends toward positive participation. dross (t • c • g) 02:20, 7 February 2022 (UTC)

Proposal 5.1 (Drafting)

Users must create a draft Request for Comment before publishing it and opening it to a vote. Users should add their draft RfCs under the appropriate section of the Requests for Comment page and ask the community for feedback. During the drafting stage, there should be minimal discussion about the substantive issues and the focus should be on improving the existing proposals (wording, copyediting, etc.) or adding new proposals. A Request for Comment cannot be opened unless it has been drafted in advance and published on Meta as a draft. Drafts should stay open for at least three (3) days.

NOTE: This Proposal is an alternative to Proposal 5, making drafting mandatory rather than strongly recommended.

Support (5.1)

1.  Support I believe that in order to have the best version possible of an RfC mandatory drafting is a good idea since if it remains a recommendation only some people may still choose not to which generally will achieve RfCs of a lesser quality since the more people look at something the better it will become. --DeeM28 (talk) 18:21, 2 February 2022 (UTC)

Oppose (5.1)

1.  Oppose While I strongly support the idea of drafting RfCs before publishing them and always do so myself, I don't feel like it needs to be an obligation at this point and can see some hypothetical situations where it would be easier/better to open one without a draft in place before. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Oppose Yes, this one is looking more bureaucratic. --YellowFrogger (talk) (✔) 16:45, 2 February 2022 (UTC)
3.  Weak oppose While I see the utility and benefit of this, I'm not sure this is necessary.| -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
4.  Oppose While beneficial, a formal mandate would be excessively bureaucratic. — Arcversin (talk) 22:44, 2 February 2022 (UTC)
5. Yikes. I wasn't even planning on participating on this RFC but this is extremely scary. No, requiring drafting is ridiculous and also completely violates the standard for basic wiki or site operation in general. People can publish it when they want, not draft it, or do so locally. Plus, the proposal's definition of a "draft" sounds a lot less like a draft and more like a pre-RFC RFC. Naleksuh (talk) 00:33, 3 February 2022 (UTC)
6.  Oppose As above, I don't want it mandatory. Soukupmi (talk) 00:36, 3 February 2022 (UTC)
7.  Oppose meh  Anpang📨  06:33, 3 February 2022 (UTC)
8.  Oppose Magogre (talk) 09:38, 3 February 2022 (UTC)
9.  Oppose It should be recommended, but not mandatory. Making it mandatory might result in the loss of useful RfCs just because of a procedural error. 77topaz (talk) 16:56, 3 February 2022 (UTC)
10.  Oppose Unnecessary. Recommending is fine, though. Firestar464 (talk) 03:58, 4 February 2022 (UTC)
11.  Oppose While drafting is very useful, users shouldn't be required to do a draft first, especially if it's an RFC that requires very little to get its point across. TigerBlazer (talk) 15:45, 4 February 2022 (UTC)
12.  Oppose - for similar grounds as stated by the aforementioned users. Also, it would be too bureaucratic and could potentially become cumbersome (or an overkill) in some cases. Kourouklides (talk) 01:28, 5 February 2022 (UTC)
13.  Oppose this shouldn't be a hard requirement.
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:24, 5 February 2022 (UTC) ］ |

Abstain (5.1)

1.  Abstain I wouldn't mind this at all, as long as it doesn't cause a butterfly effect in the end. --DarkMatterMan4500 (talk) (contribs) 17:19, 2 February 2022 (UTC)

Proposal 6 (New proposals/amendments)

After a Request for Comment has been published and is open for voting, users may add new proposals or amendments to existing proposals. It is however encouraged that this is done during the drafting process rather than once it is open in order to avoid confusion.

Support (6)

1.  Support Since drafting is not mandatory (unless Proposal 5.1 passes) and that either way the drafting process is less advertised and less visible to users, I think it is fair to still allow people to add new proposals and amendments after voting has begun, even though it shouldn't be encouraged and in my opinion should only be done if it's really necessary. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support Adding a recommendation but not a full blown ban is the best course of action here for RfCs. I understand that things may slip in the drafting process and that's alright but we also want to make sure users think their RfC proposals over and don't later go adding proposals to already existing RfCs that will likely see little engagement due to voters thinking they've voted on all possible proposals. Agent Isai ^{Talk to me!} 16:23, 2 February 2022 (UTC)
3.  Support It can assuage uncomfortable proposals as done in a recent RfC. --YellowFrogger (talk) (✔) 16:47, 2 February 2022 (UTC)
4.  Support It is very possible that following a discussion on an RfC proposal a user will get an idea for a better proposal or an amendment and it would be unfair to not allow them to add it. I acknowledge that it may be inconvenient for some reasons but not allowing the practice would not be a good idea in my view. --DeeM28 (talk) 18:24, 2 February 2022 (UTC)
5.  Support Agree with the above, some flexibility is generally helpful. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support As a reasonable supplement to 6.0, carrying a similar good flexibility even if it raises the possibility of confusion, and imo raises a bit of a flaw in the RfC formula (though I don't think the subsequent proposal is an answer to it). But it is at least standard to how things are and have been done that have gotten us this far. --Raidarr (talk) 22:29, 2 February 2022 (UTC)
7.  Support — Arcversin (talk) 22:45, 2 February 2022 (UTC)
8.  Support One can't think of everything, so some flexibility is needed. Soukupmi (talk) 00:40, 3 February 2022 (UTC)
9.  Strong support  Anpang📨  06:33, 3 February 2022 (UTC)
10.  Support This, too, makes sense, at least from my perspective. --  Joseph  TB  CT  CA  09:35, 3 February 2022 (UTC)
11.  Support This allows flexibility while encouraging editors to add their stuff to the drafts. --Firestar464 (talk) 03:59, 4 February 2022 (UTC)
12.  Strongest support with some additional strength to this vote: Yes, that should be fair enough to drafters, so we don't end up flooding RfCs with silly spam, or disruptive contents. --DarkMatterMan4500 (talk) (contribs) 16:54, 4 February 2022 (UTC)
13.  Support - This allows flexibility while encouraging editors to add their stuff to the drafts. Kourouklides (talk) 01:34, 5 February 2022 (UTC)
14.  Support
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:32, 5 February 2022 (UTC) ］ |

Oppose (6)

•  Oppose Either drafting becomes mandatory --> then changing/editing an RfC after the draft has gone "live" should be prohibited, why otherwise bother with a draft? Or drafting is not mandatory --> then changing/editing should of course be openly allowed. In both cases it is best to not have a rule regarding this issue. TheDungeonMaster (talk) 13:35, 3 February 2022 (UTC)
  • This proposal precisely allows people to submit new amendments and proposals after an RfC is opened. The reason for having a rule is to make it clear to everyone what the best practices are, rather than just have them unwritten which may lead some users to think perhaps that they are not allowed to add new proposals or amendments. Reception123 (talk) (C) 07:11, 4 February 2022 (UTC)

Comments (6)

• This section should be for 6.1 not 6.2 TheDungeonMaster (talk) 13:32, 3 February 2022 (UTC)

  I fixed numbering

  —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:30, 5 February 2022 (UTC) ］ |

Proposal 6.1 (New proposals/amendments)

After a Request for Comment has been published and is open for voting, no new proposals or amendments may be added. Any new proposals or amendments must go through a new Request for Comment.

This Proposal is an alternative to Proposal 6

Oppose (6.1)

1.  Oppose Per above, I don't think a complete ban is appropriate and good ideas could be missed because of it. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Oppose Support that a user can open new proposals during an RfC. --YellowFrogger (talk) (✔) 16:48, 2 February 2022 (UTC)
3.  Oppose Per my comment in Proposal 6 --DeeM28 (talk) 18:24, 2 February 2022 (UTC)
4.  Oppose Per my 6 comments. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
5.  Oppose There can be valuable amendments/additional proposals that didn't have a chance to be included during the drafting process. — Arcversin (talk) 22:46, 2 February 2022 (UTC)
6.  Oppose Per my comment above. Soukupmi (talk) 00:41, 3 February 2022 (UTC)
7.  Strong oppose That doesn't make any senses if there is no new proposals or amendments after we created some RFCs. - TriNguyen12348 (talk) 04:47, 3 Febuary 2022 (UTC)
8.  Strong oppose It creates the needs for a new RfC page of just a proposal of a similar topic, instead of a new proposal to the original RfC.  Anpang📨  06:33, 3 February 2022 (UTC)
9.  Oppose Inflexible. --Firestar464 (talk) 04:00, 4 February 2022 (UTC)
10.  Oppose - per my comments in Proposal 6. Kourouklides (talk) 01:32, 5 February 2022 (UTC)
11.  Strongest oppose This would be a window for missed opportunities, and some of those rejected ideas might be useful in the end. --DarkMatterMan4500 (talk) (contribs) 12:26, 5 February 2022 (UTC)
12.  Oppose
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:34, 5 February 2022 (UTC) ］ |

Comments (6.1)

• It is a bit silly the way this part of the RfC is structured. We could end up with the case where changes to a "live" RfC are prohibited, yet there is no requirement for a Draft phase. It would have been better to not offer two independent parts of the RfC and only offer a choice between a mandatory Draft process and a locked live RfC on one hand, and a less regulated RfC process (much like today) on the other. TheDungeonMaster (talk) 13:38, 3 February 2022 (UTC)

Proposal 7 (Closure)

Requests for Comment must generally stay open for at least five (5) days. They can be closed before either if they are out-of-scope, invalid per Proposal 2 (assuming it passes), otherwise malformed or if it is clear that there is no chance of consensus.

Support (7)

1.  Support Time should be given so that as many users possible can participate. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support per above. Agent Isai ^{Talk to me!} 16:24, 2 February 2022 (UTC)
3.  Support --YellowFrogger (talk) (✔) 16:50, 2 February 2022 (UTC)
4.  Support It is sensible to have a minimum time limit as well as some exemptions to the general rule. --DeeM28 (talk) 18:25, 2 February 2022 (UTC)
5.  Support Per Reception123's comments, I believe this helps to ensure users are given adequate time to participate. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support as a codification of common practice and a baseline for the subsequent proposals, presuming 'closed by a Steward' is the employed language in whatever document this text will apply to since it is not explicitly outlined here (perhaps it should be). --Raidarr (talk) 22:32, 2 February 2022 (UTC)
7.  Support Yep. Give us some time there. |Soukupmi (talk) 00:49, 3 February 2022 (UTC)
8.  Strong support  Anpang📨  06:33, 3 February 2022 (UTC)
9.  Support As per Reception123 and FrozenPlum. 77topaz (talk) 16:51, 3 February 2022 (UTC)
10.  Weak support That all depends on what the topic of said RfC is about. If it was utter nonsense, or is being used as a way to attack or to publicly out them, then it could possibly be shut down if it was being used for that purpose. --DarkMatterMan4500 (talk) (contribs) 16:58, 4 February 2022 (UTC)
11.  Support
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:38, 5 February 2022 (UTC) ］ |

Oppose (7)

1.  Oppose I don't believe we should entirely shut out the possibility of a SNOW closure, particularly due to my opposition to Proposal 2. — Arcversin (talk) 22:52, 2 February 2022 (UTC)

   I don't see how this shuts out SNOW, as the language here offers the technical equivalent by "if it is clear that there is no chance of consensus" - a lengthier form to say that it is SNOWing. --Raidarr (talk) 01:00, 3 February 2022 (UTC)

   No, snowing is absolute consensus, not no consensus. --Firestar464 (talk) 04:01, 4 February 2022 (UTC)

   Apologies for the conflation in terms. Would you (Arc) as well as others support an alternate that explicitly allows user closure by grounds of SNOW (though with more specificity than the language used above)? I'd be inclined take that route as well. --Raidarr (talk) 20:38, 4 February 2022 (UTC)

Comments (7)

1. While I don't oppose this, what about SNOW closures? --Firestar464 (talk) 04:02, 4 February 2022 (UTC)

   @Firestar464: In my view as the drafter of this proposal, this is a SNOW closure, it's just worded a bit differently but in essence it covers SNOW closures. Reception123 (talk) (C) 07:12, 4 February 2022 (UTC)

   I think the issue here is that there can be a distinction made between 'no consensus' (of any sort, which can mean no traffic) and no consensus in favor for the RfC. Perhaps a better version might address with specificity, to avoid this distinction being of issue? --Raidarr (talk) 20:40, 4 February 2022 (UTC)

• I think 7 days would be better, similar to appointment of global sysops as a precedent. If others support this change, we should then make an amendment. K599 (talk) 00:24, 5 February 2022 (UTC)
  • I second this. Kourouklides (talk) 01:38, 5 February 2022 (UTC)
  • I've actually always wondered why this isn't the case. I've been nearly shut out of participating in RfCs before because of spending a few days considering the proposals. To me, 5 days is not enough time to establish consensus. I would even entertain a policy of closure only after participation rate drops below a certain percentage of activity or number of users, whichever is greater. The numbers that come to mind are 20% or 5 users. dross (t • c • g) 02:29, 5 February 2022 (UTC)

Proposal 7.1 (Closure)

In the event that a Request for Comment is opened without a second user co-initiating it (assuming Proposal 2 passes), any registered user may close the Request for Comment as invalid. In all other cases, a Steward must close Requests for Comment.

NOTE: This Proposal will only have effect if Proposal 2 passes

Support (7.1)

1.  Support The intention of the rule is to have less inappropriate RfCs, so it makes sense to allow for a quick closure. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support Reasonable proposal to prevent invalid RfCs from requiring unnecessary Steward attention which may rob time from other crucial tasks at hand. Agent Isai ^{Talk to me!} 16:26, 2 February 2022 (UTC)
3.  Support Without allowing users to close requests that clearly fall foul of the rule in Proposal 2 invalid requests may go on for hours and people would potentially waste their time while taking part in them. Since whether there is a co-initiator or not present is clear to anybody and not open to debate it is fair that users should be able to close such requests as invalid. --DeeM28 (talk) 18:27, 2 February 2022 (UTC)
4.  Support To me if Proposal 2 passes, this just provides a quick cleanup of inappropriate RfC, which has good utility. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
5.  Support; if this is grounds to close something that would be closed anyway given the mandate of preceding proposals that I have supported, I see minimal cause for concern here. The possible ambiguity is very slight at best. --Raidarr (talk) 22:34, 2 February 2022 (UTC)
6.  Weak support Whilst I oppose Proposal 2, this would be beneficial should it pass. — Arcversin (talk) 22:50, 2 February 2022 (UTC)
7.  Support Yep - saves time. |Soukupmi (talk) 00:55, 3 February 2022 (UTC)
8.  Strong support This is to prevent time-wasting, and having to pump out shovelware RfCs that are either rushed or incomplete. --DarkMatterMan4500 (talk) (contribs) 17:00, 4 February 2022 (UTC)
9.  Support
   —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:40, 5 February 2022 (UTC) ］ |

Oppose (7.1)

1.  Oppose While it's good that a user should consult with others before opening an RfC, there's no need to reach the last level if they don't. --YellowFrogger (talk) (✔) 16:57, 2 February 2022 (UTC)
2.  Oppose I don't think is neccesary to reach this levels of pre-consult everything.... Jakeukalane (talk) 18:22, 2 February 2022 (UTC)

   @Jakeukalane: I do not believe there is any question of 'pre-consulting' here - the opposite actually. This proposal means (as I understand it) that any user can close a clearly invalid request rather than only Stewards being allowed to do that. --DeeM28 (talk) 18:28, 2 February 2022 (UTC)

   But it doesn't say that. Says anyone can close a RfC if there are not two people supporting it from the beginning. So, in order to open a RfC you need to consult with other user, if not anyone can close it without needing an excuse for it, because is automatically "invalid" if is not shared with another user. Jakeukalane (talk) 18:35, 2 February 2022 (UTC)

   @Jakeukalane: I apologise if I made things unclear, I've tried to make it a bit more clear now. I should mention that this proposal would only be effective if Proposal 2 passes, so if you disagree with that Proposal you should rather oppose that proposal, as this proposal just regulates what would happen assuming that that proposal passes. So by opposing this proposal you are in effect saying that IF Proposal 2 passes only Stewards would be able to (and have to) close RfCs for not respecting the rule in Proposal 2. Opposing here does not effect Proposal 2 itself passing though. Reception123 (talk) (C) 18:51, 2 February 2022 (UTC)

   I should mention that this proposal would only be effective if Proposal 2 passes, so if you disagree with that Proposal you should rather oppose that proposal. I did just that. However, it didn't say it's connected or I didn't see it. --YellowFrogger (talk) (✔) 18:57, 2 February 2022 (UTC)

3.  Oppose I feel that there is an issue where if the contents of the RfC are fine, but the proposer simply didn't go through the bureaucratic process from proposal 2, then any user can close such RfCs in bad faith. K599 (talk) 00:24, 5 February 2022 (UTC)

Proposal 7.2 (Closure)

In addition to Proposal 7.1, users may also close clearly out-of-scope or malformed requests.

Support (7.2)

1.  Weak support because there is a chance that proposals like this are just a SNOW, as I saw in an RfC about users having rights when adopting a Wiki, which was unanimously opposed for being poorly formatted. --YellowFrogger (talk) (✔) 17:05, 2 February 2022 (UTC)
2.  Support I definitely couldn't agree more, but having to be buried under an avalanche is just too much pressure for the whole community. --DarkMatterMan4500 (talk) (contribs) 17:18, 2 February 2022 (UTC)
3.  Support Malformed requests eat up review time that need not occur, and per my comments in 7.1. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
4.  Weak support Only weak because of clearly in the definition. That's a bit vague to me.|Soukupmi (talk) 01:02, 3 February 2022 (UTC)
5.  Support I conditionally support this possibility if Proposal 2 fails. This is because without Proposal 2 it will still be very easy for unexperienced users to create inadequate RfCs that waste time and would have to be closed by Stewards. Therefore, without that safeguard this safeguard which allows users to speedily close such RfCs would be necessary in my opinion. Reception123 (talk) (C) 11:34, 3 February 2022 (UTC)

Oppose (7.2)

1.  Oppose While I supported Proposal 7.1 I cannot support this proposal. While in Proposal 7.1 there is a binary question: is there a co-initiator? in this case the issue is more complicated and it is possible to lead to user disputes about whether something is out-of-scope or not. With the co-initiator rule it is also less likely that such situations occur and if they do a Steward can handle them. --DeeM28 (talk) 18:29, 2 February 2022 (UTC)
2.  Weak oppose; I like the idea of agency on this subject as there are users who can make the call perfectly reasonably, but so too are there users and circumstances where I can see the margin of error being too big where 7.1 is much more clear cut especially in properly defining out of scope and malformed. In other words I don't think the saved circumstances would outweigh potential issues. If malformed but otherwise valid I think it is the responsible act to un-malform it unless of course it's mangled beyond reason, which would be rather unusual if it is then properly paired with a co-proposer. Likewise its scope is a more nebulous subject and not something that just anyone should be able to make the call for. Thus this is a line a bit far for me and I'd rather leave it in the discretion of duly elected + trusted officials. --Raidarr (talk) 22:39, 2 February 2022 (UTC)
3.  Oppose I think this should be left to Stewards, especially given the ambiguity of what "out-of-scope or malformed" could mean. 77topaz (talk) 16:49, 3 February 2022 (UTC)
4.  Oppose I think this should be left to Stewards, especially given the ambiguity of what "out-of-scope or malformed" could mean. Kourouklides (talk) 01:41, 5 February 2022 (UTC)
5.  Oppose
   —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:41, 5 February 2022 (UTC) ］ |

Abstain (7.2)

1.  Abstain While I like the idea, this would be better suited by altering the User close policy into something similar to WP:NAC, resulting in this sort of close taking the form of a non-administrator SNOW close, which would be preferable. — Arcversin (talk) 22:58, 2 February 2022 (UTC)

   I would be willing to contribute to a proposal that better defines user closure for various areas of Meta including RfCs and requests under expanded, but still quite specific conditions. And if this proposal doesn't work out on technical grounds, or even after it passes it can be integrated into that effort as well. --Raidarr (talk) 23:07, 2 February 2022 (UTC)

Comments (7.2)

•  Support out-of-scope closures in full.  Oppose malformed closures in favor of forced move to draftspace to correct errors. dross (t • c • g) 02:32, 5 February 2022 (UTC)

Proposal 7.3 (Closure)

If a Request for Comment is opened without having been drafted in advance, a Steward may close it immediately if it is too vague or unclear.

Support (7.3)

1.  Support as proposer. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support Very reasonable. This allows for Stewards to close proposals which may unnecessarily waste the community's time. Agent Isai ^{Talk to me!} 16:28, 2 February 2022 (UTC)
3.  Strong support Yes. This should serve as a reminder to those who plan on making ridiculous RfCs that are intended for disruptive purposes to not do so. We don't want a whole backlog of unnecessary RfCs or disruptive RfCs that are bound to be snowballed in the end. --DarkMatterMan4500 (talk) (contribs) 17:15, 2 February 2022 (UTC)
4.  Support Obviously this should be possible. --DeeM28 (talk) 18:30, 2 February 2022 (UTC)
5.  Support This seems necessary to ensure proposers do their due diligence, and so RfC creation is respectful of people's time. I'm in agreement with Reception123 on this topic. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support This I can fully support. |Soukupmi (talk) 01:04, 3 February 2022 (UTC)
7.  Support - fair enough. This sounds reasonable to me. Kourouklides (talk) 01:44, 5 February 2022 (UTC)
8. Frankly, stewards should be able to close any proposal which is unfit, improper, or otherwise inappropriate while acting within community trust. dross (t • c • g) 02:34, 5 February 2022 (UTC)
9.  Support
   —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:42, 5 February 2022 (UTC) ］ |

Oppose (7.3)

1.  Oppose Per 7.1, we don't need to get to the last level. --YellowFrogger (talk) (✔) 17:07, 2 February 2022 (UTC)

Abstain (7.3)

1.  Abstain This is reasonable, but I would prefer for such a close to take the form of a SNOW closure as opposed to a separate procedure. — Arcversin (talk) 23:05, 2 February 2022 (UTC)

Comments (7.3)

• Could we perhaps instead consider communicating with the proposer to turn their RfC into a draft first? This proposal's suggestion comes off as unnecessarily hostile to people whose issue would just be that they need to be using clearer wording. K599 (talk) 00:24, 5 February 2022 (UTC)

Proposal 8 (Withdrawal)

The original initiator may not only withdraw a Request for Comment except if

there have been no support votes or if all users who expressed support agree with the withdrawal.

Support (8)

1.  Support I don't think it would be fair for the person that initiated an RfC to have that much power over it, especially if people like the ideas and have already supported. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support per above. Agent Isai ^{Talk to me!} 16:39, 2 February 2022 (UTC)
3.  Support I thought had this before. --YellowFrogger (talk) (✔) 17:09, 2 February 2022 (UTC)
4.  Support a sensible idea. --DeeM28 (talk) 18:31, 2 February 2022 (UTC)
5.  Strongest support Makes sense. --DarkMatterMan4500 (talk) (contribs) 19:02, 2 February 2022 (UTC)
6.  Support Agreed, makes sense. If a proprosal has good utility, it has good utility and should be elligible for use. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
7.  Support Reasonable. — Arcversin (talk) 23:04, 2 February 2022 (UTC)
8.  Support In the hope that the wording of the proposal means the same as "...may only withdraw [] if: ..." - a Yes. |Soukupmi (talk) 01:09, 3 February 2022 (UTC)
9.  Support  Anpang📨  06:33, 3 February 2022 (UTC)
10.  Support As per Reception123. I think only Stewards should be able to close the RfCs. 77topaz (talk) 16:47, 3 February 2022 (UTC)
11.  Support
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:44, 5 February 2022 (UTC) ］ |

Proposal 9 (Consensus)

No minimum threshold or support ratio exists for Requests for Comments. Stewards will use their discretion to decide whether consensus has been reached on a proposal.

Support (9)

1.  Support At this time, I don't think a minimum threshold or support ratio would be helpful for RfCs. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support Stewards are elected by the community to interpret consensus, I think we can definitely trust them to interpret consensus in edge cases. Agent Isai ^{Talk to me!} 16:38, 2 February 2022 (UTC)
3.  Support thanks to the opinions of stewards that bad proposals didn't pass, despite having great support. To me, it's better to have a big comment justifying the opposition than a lot of dull support citing "per above", instead of forming your own opinion of what is best for you. Comments like that should have no effect. --YellowFrogger (talk) (✔) 17:20, 2 February 2022 (UTC)
4.  Support I do not think that it would be easily to define an appropriate threshold or minimum ratio for Request for Comment due to their complex and diverse nature so leaving them to discretion of the Stewards is an appropriate solution. --DeeM28 (talk) 18:32, 2 February 2022 (UTC)
5.  Support This makes the most sense since bad proposals can affect the entire community negatively, and some things have security implications that a proposal may not adequately take into account. Stewards can be trusted to make that call, and I could easily envision them needing to make that call for a variety of security, practicality, and technical reasons. Also, when something is of good enough benefit to the community, it should not fail due only to a lack of a threshold number of votes. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support as a codification of something that seems about standard now, as I don't think there is a true threshold written for RfCs - though at least in my mind, there should be at least a discretionary measure for minimum engagement and support even if that bar is based on a Steward's integrity and trust in determining consensus. Ultimately I have sufficient trust in our ability to hold Stewards accountable as well as trust in them through election in the first place to mitigate foreseeable consequences of the discretion offered here. --Raidarr (talk) 22:46, 2 February 2022 (UTC)
7.  Support per WP:VOTE. — Arcversin (talk) 23:02, 2 February 2022 (UTC)
8.  Support Stewards are trusted. They know what works for and what harms the community, so they can also decide this. And as the others I wouldn't want to see a good suggestion fail because of a rather random threshold. |Soukupmi (talk) 01:16, 3 February 2022 (UTC)
9.  Support --  Joseph  TB  CT  CA  09:36, 3 February 2022 (UTC)
10.  Support. --Magogre (talk) 09:44, 3 February 2022 (UTC)
11.  Support This seems more appropriate and reliable than a simple numerical threshold/ratio. 77topaz (talk) 16:44, 3 February 2022 (UTC)
12.  Support We use consensus, not voting. Firestar464 (talk) 04:45, 4 February 2022 (UTC)
13.  Strongest support Community consensus has always been a natural thing that the stewards along with this community have been achieving for years now. It's not out of the question that a community consensus should be used as a way to resolve issues that may arise later. --DarkMatterMan4500 (talk) (contribs) 12:23, 5 February 2022 (UTC)
14.  Support
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:45, 5 February 2022 (UTC) ］ |

Abstain (9)

1.  Abstain  Anpang📨  06:33, 3 February 2022 (UTC)

Proposal 10 (Local Meta RfCs)

Local Meta Requests for Comment will be subject to the same rules as above, except that all mentions of Stewards are replaced by Meta Bureaucrats. Stewards may still close local Requests for Comment in limited circumstances. Local Meta RfCs should clearly be identified.

Support (10)

1.  Support Makes sense to have the same rules. Reception123 (talk) (C) 15:46, 2 February 2022 (UTC)
2.  Support Clear. --YellowFrogger (talk) (✔) 17:25, 2 February 2022 (UTC)
3.  Support There is no real reason why Meta's standards from RfCs should differ from global ones. --DeeM28 (talk) 18:32, 2 February 2022 (UTC)
4.  Strong support Nothing wrong with that. It should be enforced anyway. --DarkMatterMan4500 (talk) (contribs) 19:03, 2 February 2022 (UTC)
5.  Support Unifying rules makes things easier. | -- FrozenPlum (Talk / Email) 20:15, 2 February 2022 (UTC)
6.  Support as natural continuity. --Raidarr (talk) 22:49, 2 February 2022 (UTC)
7.  Support Reasonable. — Arcversin (talk) 23:00, 2 February 2022 (UTC)
8.  Support Unified rules - yes. |Soukupmi (talk) 01:18, 3 February 2022 (UTC)
9.  Strongest support That makes senses anyways and this will be helpful for us - TriNguyen12348 (talk) 4:51, 3 Febuary 2022 (UTC)
10.  Strong support  Anpang📨  06:33, 3 February 2022 (UTC)
11.  Support
    —［ Universal Omega ］［ Talk | Contributions | Guestbook  18:46, 5 February 2022 (UTC) ］ |

Comments (10)

• What are the limited circumstances in which stewards may close local RFC's? --Magogre (talk) 02:35, 3 February 2022 (UTC)

  In my view such limited circumstances would be either if a bureaucrat requests that they do (for example for reasons of impartiality) or if the local Meta RfC turns out to have global consequences. Reception123 (talk) (C) 06:10, 3 February 2022 (UTC)

• Well, since I could barely do much of a thing (as my laptop has been giving me errors over 35 times as of this writing) all day, I'm just using my Acer computer until I can figure out a way to fix my laptop. But anyway, that's besides the point: This might be useful in some cases. --DarkMatterMan4500 (talk) (contribs) 23:21, 3 February 2022 (UTC)

  Off Topic: My computer is also Acer. Anyway, surprised that to this day Miraheze didn't have a policy on this. --YellowFrogger (talk) (✔) 23:24, 3 February 2022 (UTC)

• Why not just admins? --Firestar464 (talk) 04:48, 4 February 2022 (UTC)

  Standard practice on Meta as of current is bureaucrats, not just admins. Though that doesn't preclude argument for giving admins the reach. --Raidarr (talk) 10:24, 4 February 2022 (UTC)

---

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