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

note:This RfC is a simulation for the future using actual examples. Depending on the result of the original RfC, it may not be submitted as an official RfC.

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
Anyone can propose a change to the Miraheze rules using a Request for Comment (RfC). For the proposal to be binding, it must/recommended(Proposal 0) 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.

Proposed branch(This chapter will be deleted when sending RfC)
Passing conditions (Since it is a draft, it may be changed):Among the branches that have passed the RfC passage condition so far, the one with the highest approval rate is selected.If there are multiple branches with the highest proportion, only the branch with the highest proportion is left and the votes are cast again.If it is not decided yet, it will be voted at Steward's discretion as before.

Ｔ:Truth (Assuming the proposal passed)

Ｆ:Falese (Assume that proposal was rejected)

Branch 0
Proposal 0:Ø

Proposal 1:F

Proposal 2:F

Proposal 3:F

Proposal 4:F

Proposal 5:F

Proposal 6:F

Proposal 7:F

The resulting vision
This vision is that It means that no changes are needed from the current state.

Branch 1-1
Proposal 0:Must

Proposal 1:T

Proposal 2:T

Proposal 3:T

Proposal 4:T

Proposal 5:T

Proposal 6:T

Proposal 7:T

The resulting vision
This vision is that in a week, anyone interested gets the proposal firm enough that we don't have to keep doing it during the vote.

Branch 1-2
Proposal 0:Recommended

Proposal 1:T

Proposal 2:T

Proposal 3:T

Proposal 4:T

Proposal 5:T

Proposal 6:T

Proposal 7:T

The resulting vision
This vision is that in a week, anyone interested gets the proposal firm enough that we don't have to keep doing it during the vote.

Branch 2-1 (Old:Branch 3)
Proposal 0:Must

Proposal 1:T

Proposal 2:T

Proposal 3:T

Proposal 4:T

Proposal 5:T

Proposal 6:F

Proposal 7:T

Branch 2-2 (Old:Branch 3)
Proposal 0:Recommended

Proposal 1:T

Proposal 2:T

Proposal 3:T

Proposal 4:T

Proposal 5:T

Proposal 6:F

Proposal 7:T

Branch 3-1 (Old:Branch 4)
Proposal 0:Must

Proposal 1:T

Proposal 2:T

Proposal 3:F

Proposal 4:F

Proposal 5:T

Proposal 6:F

Proposal 7:T

The resulting vision
This vision seems to be a mix of the old and the new, the chance to edit before its official proposal on Community noticeboard, with the addition of flexibility.

Branch 3-2 (Old:Branch 4)
Proposal 0:Recommended

Proposal 1:T

Proposal 2:T

Proposal 3:F

Proposal 4:F

Proposal 5:T

Proposal 6:F

Proposal 7:T

The resulting vision
This vision seems to be a mix of the old and the new, the chance to edit before its official proposal on Community noticeboard, with the addition of flexibility.

Branch to send to RfC(Title after sending RfC: Candidate for branch)
note:Since the voting will be done later, the branches that I thought were necessary alone will be left.Later it will be integrated with the proposed branch.(The proposed branch chapter is not needed and will be deleted.)Feel free to add as many branches as you need.The order of the branches may change without notice for convenience.

Comments on this attempt
It seems that my Requests for Comment/Require that RfCs undergo a public comment period did not fully use its own process. expressed support for only part of it, now reflected in his abstention. Ideally, he/we would have written an alternative during the draft phase.

However, 128 options? Please! The brute-force-algorithm does not work! There are over 1000 words in the proposal and you could have a ballot on removal of each one, 21000 in all. (Insert emoticon here.)

You wisely see that not all 128 are meaningful. However, rather than use the truth table to set out a few meaningful ones, what I would like you to do is state a vision for the result. My vision is that in a week, anyone interested gets the proposal firm enough that we don't have to keep doing it during the vote. Reception123's vision seems to be a mix of the old and the new, the chance to edit before its official proposal on Community noticeboard, with the addition of flexibility. (I didn't incorporate that into the draft, because flexibility is the problem I set out to solve, meaning the question under vote changing while we're voting on it.)

noted a separate problem during the vote phase, the lack of a fast-track by which Miraheze could approve changes in procedures that cannot afford to wait a week for leisurely preliminary editing. 23:32 25-Jun-2020


 * Thanks for your response.Thanks to you,i can improve this RfC.


 * Writing 128 is an excuse for not writing everything, and the rest is a joke.)I personally liked the wording "There are over 1000 words in the proposal and you could have a ballot on removal of each one, 21000 in all".I created this RfC as a simulation, but if I had to submit it as an official RfC, I would need to change the section title.


 * I liked the suggestion of writing the resulting vision.It is effective in removing meaningless options.I'll follow my advice and add a vision, but it seems better to ask Branch 1's vision to and Branch 4's vision to  to do better than I write.


 * The reason I created the branches is that discussions often pass only the parts that have been agreed.If the number of votes reaches the stipulation with the ratio of the opinions of the arguments that led to the branch unchanged, it is possible that only 1,2,5,7 with almost everyone's consent may be passed.I don't know if the user who chose Branch 1 wants this, so I branched it.--松•Matsu (talk) 06:03, 26 June 2020 (UTC)

Well, two of your options, while meaningful, should not be submitted. T•T•T•T•T•T•T is identical to my RfC. As I am a couple weeks ahead of you, if this is the will of the community, then my RfC passes and we don't get to yours. Now, F•F•F•F•F•F•F can be eliminated too. As you state, it is the status quo ante, a result that is achieved simply by voting against both our RfCs. once included in an RfC a Proposal that was to make no change, but quickly conceded to me that to get that, you simply vote to Oppose the real Proposal. In fact, if the final vote is against my RfC, it is a waste of time to ask the group to vote against all seven again!

The value you can add is to sense the will of the community and write an RfC that meets it. It's not clear that the original will not pass, but the biggest minority opinion is that the mandatory part should be dropped. (Roughly your Branch 3.) I'm against this, because what happens is that we insert a 1-week delay to get an RfC edited on and in good shape...then during the vote, we lapse back to redesigning on-the-fly. If it is possible to discard the structure, then I would rather not have all my words erecting it. There is not even any reason for the 1-week editing period if editing winds up being done during the vote, nor any reason (other than sincere desire for improvement) for anyone to participate in the 1 week, editing before reading the opinions of voters. And your Branch 4 additionally drops the clause that puts the proposer in charge of the editing and warns against attempts to sabotage it. I don't see why to do this; the proposer wants to submit the most likely-to-pass proposal that achieves his objectives. He ought not have to preside over and submit a proposal that no longer does what he wants.

Your proposal assumes mine does not pass. If mine passes, an alternative bit of work might be to write a proposal to amend it to satisfy some Oppose voters. 00:20 27-Jun-2020


 * The response was delayed because it was being edited. I'm sorry.Sure, you might be able to omit the two examples you presented.However, the original RfC commented on whether the proposed text was recommended or required, and may need to be reflected.Branch 1-1 can be deleted as you pointed out.(Thank you for pointing out.)--松•Matsu (talk) 00:55, 27 June 2020 (UTC)
 * Looking at the original RfC, it seemed like there was a vote for each proposal, not the whole RfC.(We created the RfC so that it wouldn't happen, but as a result it was voted individually.)I am trying to improve it now.I think your goal is full implementation of the original RfC text.(i.e.Proposals that allow only part of the proposal will require opposition.)Therefore, I decided to separate the branch for full fulfillment from the branch for partial fulfillment.That is why I wrote T•T•T•T•T•T•T.This will allow you to oppose Branch 3,4.If you do not object to the original RfC being fully recognized or only partially fulfilled, this RfC is not necessary.--松•Matsu (talk) 01:51, 27 June 2020 (UTC)
 * I am worried that the most credible opinions will be the greatest common divisor of the votes when counting votes.(e.g.Assuming that proposals 2, 3, 5, 7, 11 exist.I claimed 2310.A claimed 210.B claimed 70.C claimed 770.D claimed 21.Proposal 7 has been approved as the consensus of the community.)The actual voting is not that simple, but I'm worried about it.--松•Matsu (talk) 02:55, 27 June 2020 (UTC)

Sorry! When I wrote, "(Insert emoticon here)", I did not mean "I want you to insert 21000 in your draft!" I meant, pretend I had inserted an emoticon here to clarify that I am joking! I should have simply inserted an emoticon to indicate that.

Too many branches now! I think that your Proposal 0, whether the entire thing is mandatory or a recommendation, should be a separate ballot. (Personally, I oppose "recommendation" RfCs that invite people to ignore them.) Your approach, where the branches present complete assemblies to the voter, is too complicated. It may have seemed as though the 7 sections of my RfC vere voted separately, but this is not true, and right now, there are 5 votes, though one is both Support/Oppose, achieving an amendment on-the-fly that the RfC seeks to prohibit! I don't entirely understand your mathematical last paragraph but you might be making the point that the result of balloting on independent branches may be to assemble a result that is meaningless.

By the way, it is routine for some of the 9 U.S. Supreme Court judges to write separate opinions agreeing with only part of the dominant opinion. So only the text that at least 5 agree with is mandatory. However, if they find that this process produces a meaningless result, they do not publish but continue negotiating! 03:45 27-Jun-2020


 * Thank you for your reply.I couldn't come up with a title and I gave it a light feeling, so it's my fault.Rather,I am sorry that I made you worry about me.The last part of the greatest common denominator I added last time may be meaningless, because I don't know how Steward sums up after all.The branch 0 part is not necessary unless there is a complaint against RfC itself, so we are considering removing it. Therefore, I assigned a number of 0.Actually,we can achieve it by voting against all branches.(If we vote negative for all branches, it is actually branch 0.)Add a section called the required branch.--松•Matsu (talk) 10:02, 27 June 2020 (UTC)
 * Proposal 0 was set because I thought the number of proposals accepted by must and recommended differed. (Recommended may accept more suggestions. It may not make sense to increase the conditions with recommended...)We are also considering replacing recommended with strong recommended.--松•Matsu (talk) 14:32, 28 June 2020 (UTC)


 * monologue:The original RfC and the members participating in this RfC vote may be different.It might be better not to narrow down the branches.With the original RfC, conditional voting has increased,so we may have to send this RfC.Timing to send to Community notice board is difficult.A lot of simple support votes or oppose votes may be added, and the original RfC result may be a result of yes,no dualism.I don't know at this time if counting will be impossible even if the number of conditional votes increases.I would like avoid duplicating and confusing the discussion.I don't plan to send it at this time.(This part is still under consideration.)--松•Matsu (talk) 16:07, 28 June 2020 (UTC)

Yes, I too will "wait and see." If my RfC fails, the best we could do is draft a proposal that seems to be the sense of the voters, rather than present them every possible alternative. A few, including Reception123, are basically opposed to any procedure being required. They are more willing than I to tolerate imprecision, such as the rewording of things we have already voted on. If this is the outcome, more RfCs won't matter. 16:10 28-Jun-2020
 * I think so too, this RfC is only useful when the original RfC tally is too contingent on the conditional votes to know what they agree with.If the original RfC draft didn't go through, there have to rewrite the draft from scratch.Especially if we want to turn recommendations into recommendations instead of deleting suggestions,they have to change the whole nuance of the sentence.--松•Matsu (talk) 16:54, 28 June 2020 (UTC)

monologue:If we can not count the votes well, convert this RfC into a competition format.Title change to "Competition of rule sentence to make RfC vote well-difind"--松•Matsu (talk) 17:56, 28 June 2020 (UTC)