Requests for Comment Policy

From Meta
(Redirected from Requests for Comment/Policy)
Other languages:
Shortcut:
RFCPOL,
RfCP
Requests for comment Policy
This page provides information regarding the Requests for Comments process (voting, closure, withdrawal, etc.)

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. Requests for Comments are an easy way to gather community feedback and to form community consensus on certain proposals, ideas, and issues. Requests for Comments can be used for a variety of purposes where the community should be consulted.

If the Miraheze community wishes to express a general recommendation, that may be done via Feedback Requests (FRs) that will take place on the community noticeboard, these are non-binding expressions of current opinion or 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.

Drafting[edit | edit source]

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 on community noticeboard or Meta-Wiki community noticeboard depending on whether the RFC has global or local effects. 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. It is also recommended that users have a co-initiator before opening an RfC.

Adding new proposals and amendments[edit | edit source]

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.

Voting[edit | edit source]

Users may not participate in Requests for Comment with more than a single account, in accordance with the user accounts policy. Only registered users may initiate or vote in Requests for Comment. Unregistered users (IPs) 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'.

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'. Should an anonymous IP editor or user who created their account after an RfC had started !vote in an RfC, their comment may be procedurally moved to the appropriate comments section by any experienced user on Meta Wiki.

Closure[edit | edit source]

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, malformed, or if it is clear that there is no chance of consensus. A Request for Comment that has not been drafted in advance may be closed by a Steward immediately if it is too vague or unclear.

Withdrawal[edit | edit source]

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

Determining consensus[edit | edit source]

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.

Local Meta-Wiki RfCs[edit | edit source]

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 (for example, if a Meta bureaucrat asks stewards to close the RFC or if the the local RFC turns out to have global effects). Local Meta RfCs should clearly be identified.

See also[edit | edit source]