Requests for Comment Policy
 | This page documents a global Miraheze policy. This policy follows consensus and/or guidelines set by global functionaries. All Miraheze users should follow it, and changes made to it should be discussed on the talk page. In the event of any differences in meaning between the original English version and a translation, the original English version takes precedence. |
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
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, copy editing, etc.) or adding new proposals. It is also recommended that users have a co-initiator before opening an RfC.
Adding new proposals and 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 to avoid confusion.
Voting
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.
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 considered 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
Requests for Comment that affect the global community must generally stay open for at least fourteen (14) days; and those that affect local communities (e.g. Meta, Login Wiki etc.), must generally stay open for at least five (5) days. They can be closed before either if they are out-of-scope, malformed, if it is clear that there is no chance of consensus, or if there is an emergency. 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.
Early closure
A Request for Comment may be closed early with no outcome, if, in the closer's discretion, the Request for Comment is found to have an insufficiently formed problem statement, is beyond the scope or capacity of the community, is extremely unlikely to result in a tangible outcome, or is otherwise a misuse of the process. Requests for Comment may also be withdrawn by the initiating drafter if all participants do not object to such action.
Emergency action
There are certain scenarios where the action required is so urgent it cannot wait for a Request for Comment to convene. The most notable example of this in Miraheze's history was the migration of IRC channels from Freenode to Libera Chat due to instability in the former. This decision was subsequently ratified by Requests for Comment/IRC.
Stewards and other functionaries may take immediate action on matters, beyond their usual authority, without a Request for Comment only if failing to take such an action would result in immediate service disruption or irreversible harm to Miraheze or to life, limb, or property. Once such an action is taken, a Request for Comment must be opened as soon as it is feasible to. During this Request for Comment, the action needs to be described as well as the circumstances that justified the action. The community will have the opportunity to approve the action without further modification, to modify the action taken, or to undo the action if appropriate. Such a Request for Comment is not necessary if the action taken was within that person's usual authority. Abuse of this process is grounds for sanctions.
Determining 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.
Local Meta-Wiki 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 (for example, if a Meta bureaucrat asks stewards to close the RFC or if the local RFC turns out to have global effects). Local Meta RfCs should clearly be identified.
Revision history
- 2022-02-07: Requests for Comment/Requests for Comment – RfC which led to the creation of this policy
- 2024-03-10: Requests for Comment/Changes to Requests for Comment Policy – 2024 amendments to this policy