Requests for Comment/Require that RfCs undergo a public comment period

Miraheze "Requests for Comment" (RfC), in practice, are formal votes where a majority is able to change the rules for behavior and the governing structure of Miraheze. Unfortunately, the RfC name and frequent practice mean that discussion and decision are intermixed, and a formal vote turns into an occasion for further brainstorming.

Instead, RfCs should undergo a drafting phase, with public notice and a chance for editing. It should only be presented for a vote when it has completed this phase.

Proposal: Require that RfCs undergo a public comment period
Anyone can propose a change to the Miraheze rules using a Request for Comment (RfC). For the proposal to be binding, it must follow these steps:
 * 1) The proposer writes the proposal in a new page in the proposer's userspace, whose title accurately describes the proposal.
 * 2) The proposer announces the proposal in a new section at Community noticeboard. This should explain the motivation for the proposal in enough detail that readers can decide if they want to participate.  It must point to the user page containing the draft.
 * 3) The proposer accepts comments and moderates any joint editing on this user page. Comments may oppose the proposal, and may propose to weaken it, but should not try to sabotage it.  The proposer shall respond to comments but controls the proposal, as the proposer has a goal in mind.  Opponents whose views do not prevail in the comment period should vote against the RfC and explain their opposition so as to convince other voters.
 * 4) The comment period shall last at least 1 week but shall remain in effect until comments die down. If the period lasts for more than 1 week:
 * 5) *The proposer ensures that the notice of the comment period remains on Community noticeboard throughout the comment period, either by disabling archiving (see Autoarchive) or, if it is archived, pulling it back from the archive file.
 * 6) *3 commenters may move the proposal to the RfC stage described below. Agreeing to advance the RfC does not mean that one agrees with the RfC or is obliged to vote to support it.
 * 7) The proposer then moves the proposal to mainspace, with a name starting with "Request for Comment/". The proposer moves the comments received to the proposal's talk page (or to a section at the bottom of the RfC with a title such as "Comments received during the editing phase".  The voting period begins and is conducted as before.
 * 8) It is not in order to write new proposals inside the RfC, such as a proposal to go in the exact opposite direction. If voters believe Miraheze should take different action, they should argue against and vote against the RfC and begin work on a separate RfC with its own comment period.  The RfC itself should not offer alternatives and multiple-choice.  This should have been worked out in the comment period and voters should be offered a single option to either accept or reject.
 * 9) Proposals in an RfC shall not be edited after a vote to Support or Oppose has been cast. If the proposal is poorly drafted, options are to defeat it and start over, or pass it anyway and then write another RfC to amend it.

RfCs shall not be struck down on the technicality that the above procedure was not followed, unless someone gave the proposer timely notice of the above procedure and the proposer refused to follow it.

From 松
The situation where discussion and voting are not clearly separated often makes me hesitant to vote, because the definition of the vote for or against the vote is not well-defined.However, since it is possible that the result of Proposal A will affect Proposal B(B is not well-Proposal(defined).), it is necessary to be open to the fact that discussion and voting are mixed.While this can be avoided by simulating a possible situation and branching the proposal when drafting, it can be difficult to complete.Therefore, even if the RfC is the same, I want to have flexibility so that I can vote for each proposal.Therefore, I would like to include a wording that allows the start date and time of voting to be set for each clause even with the same RfC. What do you think?It is based on the assumption that the proposal will be finalized as much as possible when drafting it.--松 (talk) 16:18, 15 June 2020 (UTC)

Addendum:I said "branching", but rather than ask the voters to pick a branch, I'd like to be prepared to prevent one suggestion from going in an unexpected direction because of another suggestion. .. Therefore, if you can enter the vote at the right time, only one branch will be presented.--松 (talk) 17:16, 15 June 2020 (UTC)


 * Thanks for your response. I have found a more suitable place for your suggestion on archiving.  I think there is no automatic way to keep it from being archived, but that the proposer should have the duty to see that it doesn't happen.


 * Your concern about the lack of separation of discussion and voting is exactly the motivation for my proposal. I don't agree that mixing these phases is a necessary evil.  Having proposals with multiple ballots, some of which make changes to others, is partly what I propose to eliminate with my proposal.  It may be that we conclude, during the vote, that the entire concept needs more discussion.  Then we should withdraw/defeat the proposal and start over.


 * I like your idea that, if there are multiple ballots in an RfC, they have separate clocks. (See Uncyclopedia for a page with one clock per ballot.)  However, this is outside the scope of my proposal; I explicitly avoid changing the existing voting process.  (See item 5, "The voting period begins and is conducted as before.")   18:03 15-Jun-2020


 * Thank you for changing to the right place.Automatic archiving can probably be avoided.(see Autoarchive)Regarding the proposal to divide the start time, it does not make any sense unless this RfC passes, so I will postpone it this time and think about whether to make a proposal after seeing the state of the new RfC that will be held after this RfC.(If nothing goes wrong, there's no need to suggest anything).--松 (talk) 18:56, 15 June 2020 (UTC)


 * Very good. I have added a mention of Autoarchive, as it's simpler than what I had suggested.   19:49 15-Jun-2020

From Dmehus
This seems fine, although, I must admit, I did chuckle a bit that we're proposed that all Request for Comments undergo a public comment period prior to publicizing. I realize, though, that the public comment period is on whether to move forward for the RfC; I'm not sure it should be mandated, but rather, just strongly encouraged. Also, I'm not sure we need to create a community noticeboard thread on it, but maybe we should just ping the users active in the last 30 days or so? What do you think? Dmehus (talk) 21:53, 15 June 2020 (UTC)


 * I notified Reception123, as we've discussed this type of thing before, which led him to follow a comparable procedure with his recent RfCs. After he responded, I did intend to give this the same treatment it seeks for other RfCs out of fairness.  Am not in a hurry


 * I do want to propose that it be mandated and not just encouraged, to avoid the practice of RfCs being brainstormed during a vote and instead bring forward RfCs that have already been reviewed and refined. It's why legislatures use committees, to preserve the time of the main body.


 * Notifying only the recently active users is too clever. What about someone just rejoining who wants to influence the development of this RfC?  A noticeboard is for notice; it also leaves a permanent record in the "diary" of the wiki.   00:14 16-Jun-2020

From Reception123

 * Copied here from his talk page

Looks like an interesting proposal, though I wouldn't necessarily agree with the 6th point you make which does change a lot. Though we can discuss all of them. Reception123 (talk) ( C ) 06:13, 16 June 2020 (UTC)

This RfC was announced at Community noticeboard at 15:05, 16 June 2020 (UTC)

There was no reaction during the public comment period. Proposer withdrew this at 23:41 23 June 2020 (UTC)