Requests for Comment/Requests for Comment

'''This is a DRAFT RFC. Please DO NOT vote. You may add suggestions for wording or new proposals, but please do not vote on substantive issues'''

Since the creation of Miraheze, Requests for Comment 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 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. [SIGNATURE]

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 general other matters pertaining to the Miraheze community.

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

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.

(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 and to avoid situations when a user creates an RfC with little thought behind it)

Proposal 2.1 (Initiation)

 * If a co-initiator can not be found a user instead request that a Steward reviews and approves a prospective Request for Comment which would take the place of the co-initiator.

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

Proposal 3 (Voting)

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

Proposal 3.1 (Voting)

 * Unregistered users may participate in Requests for Comment by way of comments, but these will not ultimately be taking into account when deciding consensus and will not count as 'votes'.

This proposal is an alternative to Proposal 3

Proposal 4 (Voting)

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

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.

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 3 days.

This Proposal is an alternative to Proposal 5

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.

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

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.

Proposal 7.1 (Closure)

 * In the event that an RfC 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.

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.

Proposal 8 (Withdrawal)

 * The original initiator may not only withdraw a Request for Comment except if there have been no support votes or if there have all users who expressed support agree with the withdrawal.

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.

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.