Requests for Comment/Requests for Comment

Since the Miraheze 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)  as proposer. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  as co-initator.  Agent Isai  Talk to me! 15:55, 2 February 2022 (UTC)
 * 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)
 * 1) --YellowFrogger  ( talk ) ( ✔ ) 15:57, 2 February 2022 (UTC)
 * 2)  I couldn't agree more. --DarkMatterMan4500 (talk) (contribs) 16:05, 2 February 2022 (UTC)
 * 3)  Appears to be an appropriate definition of what an Request for Comment is. --DeeM28 (talk) 18:08, 2 February 2022 (UTC)
 * 4)  We need rules to simplify things. Tali64³ (talk) 19:42, 2 February 2022 (UTC)
 * 5)  - Agreed, makes sense and feels appropriate. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 6)  RFCs are the easiest way to organize the community for voting so I agree heavily here TigerBlazer (talk) 20:17, 2 February 2022 (UTC)
 * , though I feel a touch redundant given the unanimous nature of support so far. --Raidarr (talk) 21:46, 2 February 2022 (UTC)
 * 1)  — Arcversin (talk) 22:29, 2 February 2022 (UTC)
 * 2)  Definition makes sense to me Soukupmi (talk) 00:16, 3 February 2022 (UTC)
 * 3)  It makes sense and it is a more proper definition King Dice (talk) 01:34, 3 February 2022 (UTC)
 * 4)  --Magogre (talk) 02:36, 3 February 2022 (UTC)
 * 5)  RFCs will make senses in the future. --TriNguyen12348 (talk) 04:42, 3 Febuary 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)  as proposer. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  as co-initiator  Agent Isai  Talk to me! 15:56, 2 February 2022 (UTC)
 * 3)  He was responsible for the Purge and WikiSeo extension. --YellowFrogger  ( talk ) ( ✔ ) 15:59, 2 February 2022 (UTC)
 * 4)  Makes sense. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 5)  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)  — Arcversin (talk) 22:29, 2 February 2022 (UTC)
 * 7)  Good to differ those 2. Soukupmi (talk) 00:17, 3 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)  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) 100% per Reception123.  Agent Isai  Talk to me! 16:00, 2 February 2022 (UTC)
 * 3)  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)  Absolutely. This should be encouraged. --DarkMatterMan4500 (talk) (contribs) 19:07, 2 February 2022 (UTC)
 * 5)  - seems appropriate for helping to encourage appropriate proposals.|  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 6)  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) Hard for those with few connections but I see the point into this. Soukupmi (talk) 00:20, 3 February 2022 (UTC)

Oppose (2)

 * 1)  I think this should be encouraged but not obligated. Jakeukalane (talk) 18:59, 2 February 2022 (UTC)
 * 2)  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)
 * 4)  per Jakeukalane. I don't think this should be made necessary to initiate an RfC. Magogre (talk) 02:47, 3 February 2022 (UTC)
 * 5)  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.  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)

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)  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)  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)  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)  - 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) Yep, now the eremits also have a chance. Soukupmi (talk) 00:22, 3 February 2022 (UTC)

Oppose (2.1)

 * 1) I am placing an  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)

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 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) if Proposal 3.1 doesn't pass.  Agent Isai  Talk to me! 16:08, 2 February 2022 (UTC)
 * 2)  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)
 * 1)  also if Proposal 3.1 doesn't pass. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 2)  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)
 * 3) Prefer the 3.1 But it's okay. Soukupmi (talk) 00:25, 3 February 2022 (UTC)

Oppose (3)

 * 1) . Unregistered editors should at most comment. Before I could. --YellowFrogger ( talk ) ( ✔ ) 16:08, 2 February 2022 (UTC)
 * 2) . Unregistered editors are also valuable.Jakeukalane (talk) 17:53, 2 February 2022 (UTC)
 * 3)  IPs shouldn't have their comments discredited. — Arcversin (talk) 22:32, 2 February 2022 (UTC)

Comments (3)

 * 1) I conditionally  this proposal if Proposal 3.1 is not successful. Reception123 (talk) ( C ) 15:46, 2 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)  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)
 * 2)  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)
 * 3) 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)
 * 1)  IPs are people, too. Tali64³ (talk) 19:44, 2 February 2022 (UTC)
 * 2)  - This makes perfect sense to having trustworthy voting and preventing abuse as others have mentioned.|  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 3) ; 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)
 * 4) Yes, let them comment but not vote. Soukupmi (talk) 00:26, 3 February 2022 (UTC)

Oppose (3.1)

 * 1)  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)
 * 2)  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)

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)  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)  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) 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)  Per my statement below. --DarkMatterMan4500 (talk) (contribs) 17:24, 2 February 2022 (UTC)
 * 5)  an obvious provision. --DeeM28 (talk) 18:18, 2 February 2022 (UTC)
 * 6)  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)  This would already be considered abuse of multiple accounts. — Arcversin (talk) 22:36, 2 February 2022 (UTC)
 * 8) Should go without saying.Soukupmi (talk) 00:28, 3 February 2022 (UTC)

Oppose (4)

 * 1)  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)

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)  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)  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) It looks like bureaucracy, but in fact it's actually prevention. --YellowFrogger  ( talk ) ( ✔ ) 16:22, 2 February 2022 (UTC)
 * 4)  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)  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)  This also seems necessary to me for the reasons others mentioned above. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * , 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)
 * 1) 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)

Oppose (4.1)

 * 1)  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)

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)  Drafting is clearly helpful and should be encouraged as much as possible. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  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) --YellowFrogger  ( talk ) ( ✔ ) 16:25, 2 February 2022 (UTC)
 * 4)  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)  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)  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)  Drafting is beneficial. — Arcversin (talk) 22:43, 2 February 2022 (UTC)
 * 8) 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)

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)  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)  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) Yes, this one is looking more bureaucratic. --YellowFrogger  ( talk ) ( ✔ ) 16:45, 2 February 2022 (UTC)
 * 3) 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)  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) As above, I don't want it mandatory. Soukupmi (talk) 00:36, 3 February 2022 (UTC)

Abstain (5.1)

 * 1)  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.1 (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)

 * 1)  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)  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)  It can assuage uncomfortable proposals as done in a recent RfC. --YellowFrogger  ( talk ) ( ✔ ) 16:47, 2 February 2022 (UTC)
 * 4)  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)  Agree with the above, some flexibility is generally helpful. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 6)  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)  — Arcversin (talk) 22:45, 2 February 2022 (UTC)
 * 8) One can't think of everything, so some flexibility is needed. Soukupmi (talk) 00:40, 3 February 2022 (UTC)

Proposal 6.2 (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.1

Oppose (6.2)

 * 1)  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) Support that a user can open new proposals during an RfC. --YellowFrogger  ( talk ) ( ✔ ) 16:48, 2 February 2022 (UTC)
 * 3)  Per my comment in Proposal 6.1 --DeeM28 (talk) 18:24, 2 February 2022 (UTC)
 * 4)  Per my 6.1 comments. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 5)  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) Per my comment above. Soukupmi (talk) 00:41, 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)  Time should be given so that as many users possible can participate. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  per above.  Agent Isai  Talk to me! 16:24, 2 February 2022 (UTC)
 * 3)  --YellowFrogger  ( talk ) ( ✔ ) 16:50, 2 February 2022 (UTC)
 * 4)  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)  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)  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) Yep. Give us some time there. |Soukupmi (talk) 00:49, 3 February 2022 (UTC)

Oppose (7)

 * 1)  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)

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)  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)  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)  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)  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) ; 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)  Whilst I oppose Proposal 2, this would be beneficial should it pass. — Arcversin (talk) 22:50, 2 February 2022 (UTC)
 * 7) Yep - saves time. |Soukupmi (talk) 00:55, 3 February 2022 (UTC)

Oppose (7.1)

 * 1) 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. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 16:57, 2 February 2022 (UTC)
 * 2) I don't think is neccesary to reach this levels of pre-consult everything.... Jakeukalane (talk) 18:22, 2 February 2022 (UTC)
 * 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)
 * 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. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger ( talk ) ( ✔ ) 18:57, 2 February 2022 (UTC)

Proposal 7.2 (Closure)

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

Support (7.2)

 * 1) 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. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:05, 2 February 2022 (UTC)
 * 2)  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)  Malformed requests eat up review time that need not occur, and per my comments in 6.1. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 4) Only weak because of clearly in the definition. That's a bit vague to me.|Soukupmi (talk) 01:02, 3 February 2022 (UTC)

Oppose (7.2)

 * 1)  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) ; 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)

Abstain (7.2)

 * 1)  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)

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)  as proposer. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  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)  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)  Obviously this should be possible. --DeeM28 (talk) 18:30, 2 February 2022 (UTC)
 * 5)  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) This I can fully support. |Soukupmi (talk) 01:04, 3 February 2022 (UTC)

Oppose (7.3)

 * 1) Per 7.1, we don't need to get to the last level. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:07, 2 February 2022 (UTC)

Abstain (7.3)

 * 1) 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)

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)  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)  per above.  Agent Isai  Talk to me! 16:39, 2 February 2022 (UTC)
 * 3) I thought had this before. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:09, 2 February 2022 (UTC)
 * 4)  a sensible idea. --DeeM28 (talk) 18:31, 2 February 2022 (UTC)
 * 5)  Makes sense. --DarkMatterMan4500 (talk) (contribs) 19:02, 2 February 2022 (UTC)
 * 6)  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)  Reasonable. — Arcversin (talk) 23:04, 2 February 2022 (UTC)
 * 8) 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)

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)  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)  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) 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. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:20, 2 February 2022 (UTC)
 * 4)  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)  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)  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)  per WP:VOTE. — Arcversin (talk) 23:02, 2 February 2022 (UTC)
 * 8) 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)

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)  Makes sense to have the same rules. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2) Clear. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:25, 2 February 2022 (UTC)
 * 3)  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)  Nothing wrong with that. It should be enforced anyway. --DarkMatterMan4500 (talk) (contribs) 19:03, 2 February 2022 (UTC)
 * 5)  Unifying rules makes things easier. |  -- FrozenPlum  (Talk / Email) 20:15, 2 February 2022 (UTC)
 * 6)  as natural continuity. --Raidarr (talk) 22:49, 2 February 2022 (UTC)
 * 7)  Reasonable. — Arcversin (talk) 23:00, 2 February 2022 (UTC)
 * 8) Unified rules - yes. |Soukupmi (talk) 01:18, 3 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)