User:松/Requests for Comment/Require that RfCs undergo a public comment period/Proposed branch

Requests for Comment/Require that RfCs undergo a public comment period After confirming the comments, it seems that there are multiple sets of proposals to support.When I voted individually, I felt that I might support combinations of proposals that I did not intend.So I create a branch of the proposal.

==List of suggestions Please send any comments to the proposal itself to Requests for Comment/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 "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".  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.

Branch 1
Proposal 1:T

Proposal 2:T

Proposal 3:T

Proposal 4:T

Proposal 5:T

Proposal 6:T

Proposal 7:T

Branch 2
Proposal 1:F

Proposal 2:F

Proposal 3:F

Proposal 4:F

Proposal 5:F

Proposal 6:F

Proposal 7:F

Branch 3
Proposal 1:T

Proposal 2:T

Proposal 3:T

Proposal 4:T

Proposal 5:T

Proposal 6:F

Proposal 7:T