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)

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)

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)

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

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)

Oppose (3)

 * 1) . Unregistered editors should at most comment. Before I could. --YellowFrogger ( talk ) ( ✔ ) 16:08, 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. — Preceding unsigned comment added by Agent Isai (User talk:Agent Isai • Special:Contributions/Agent Isai) 16:11, 2 February 2022 (UTC)
 * 3) IPs should share their view and report us comments (eg an RfP). But it won't count as a vote. --YellowFrogger  ( talk ) ( ✔ ) 16:12, 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)

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)

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)

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

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)

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)

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)

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)

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.

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)

Proposal 7.2 (Closure)

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

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)

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)

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)

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)