User:Spike/Recommend 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.

A previous RfC sought to mandate a public comment period before the vote begins. The vote on it was divided, but one voter and one non-voter objected to the mandatory nature of the procedure and especially the prohibition on generating new options during the life of the RfC. The current RfC recasts this as a non-mandatory recommendation.

Proposal: Recommend that RfCs undergo a public comment period
Anyone can propose a change to the Miraheze rules using a Request for Comment (RfC). The proposal should follow these steps:
 * 1) The proposer writes the proposal in a new page in the proposer's userspace on Meta, whose title accurately describes the proposal.
 * 2) The proposer announces the proposal in a new section at Community noticeboard, which explains 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) This begins a public comment period, whose goal is to devise solid wording of a single proposal to present for an up-or-down vote. 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; opponents should vote against the RfC and explain their opposition so as to convince other voters.
 * 4) The comment period should remain open for at least 1 week, or longer if commenters continue to raise new points. If the period lasts for more than 1 week, the proposer must ensure that the notice of the comment period remains on Community noticeboard throughout the comment period, such as by disabling archiving (see Autoarchive).
 * 5) To present the draft as a formal RfC, the proposer moves the page to mainspace on Meta, with a name starting with "Requests 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").  If the proposer elects not to present the draft, any participant can present it without restarting a public comment period.
 * 6) The voting period begins and is conducted as before.
 * 7) Rather than redrafting during a vote, the preferred method of dealing with unsatisfactory RfCs is to vote them down and return to a public comment period to revise the proposal. Commenters may append new ballot propositions to the RfC, but the original proposition should be sufficiently worked out as to not offer alternatives and multiple-choice.

A ballot question must not be edited after someone other than the editor has cast a vote.

RfCs claiming to be too urgent to undergo the public comment period must include an explanation of the urgency.

RfCs shall not be struck down on the technicality that the above requirements were violated, unless someone gave the violator timely notice of the above rules and the violator refused to follow it.

[This RfC shall be implemented by copying the above procedure into Requests for Comment and modifying the form field to create a new page in userspace rather than as a subpage of Requests for Comment.]