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

From Miraheze Meta, Miraheze's central coordination wiki
The following discussion is closed. Please do not modify it.
Closed by proposer: Vote divided, but majority against when counting conditional votes and votes with objections; no expression of additional support in over a month.

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[edit | edit source]

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:
    • 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.
    • 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.
  5. 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.
  6. 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.
  7. 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.

Support[edit | edit source]

  1.  Support. As proposer. Spıke (talk) 13:22 24-Jun-2020
  2.  Support. I think I had enough discussion with the proposer.My reasons are in the discussion below.--松•Matsu (talk) 15:35, 24 June 2020 (UTC)I added.--松•Matsu (talk) 05:20, 26 June 2020 (UTC)
  3.  Support I support the process except the 6th point and I would also like it to not be mandatory but just strongly recommended that users follow this process at least until people get used to it. DeeM28 (talk) 17:09, 26 June 2020 (UTC)
  4.  Support As per se Drgng (talk) 18:59, 28 June 2020 (UTC)

Oppose[edit | edit source]

  1.  Oppose particularly around 6, there are legitimate needs to redefine an opposite approach within the same RfC, such that two parallel lines are explored. The least of this is technical and passed along directional votes (example being the NordVPN RfC). The process of having an RfC being invalidated as well to me does not sit right just because it did not follow a weeks public consultation period. There’s legitimate cases where there may be a time sensitive issue where extending by a week or more may encounter a situation where community consensus may have to be subverted to allow a time resolution to a matter. My opinion is this RfC seeks to legislate for the sake of legislating rather than resolve an issue whereby the process would be improved - but rather cause detriment. John (talk) 16:18, 24 June 2020 (UTC)
  2.  Oppose While I do think that giving the community a chance comment on a draft RfC is a good idea, it should not be a requirement. This proposal would simply create a 'pre-RfC RfC' that would need to be passed before the actual RfC could be posted. Sario528 (talk) 19:15, 24 June 2020 (UTC)
  3.  Oppose Oppose a mandatory nature of this process and also the change made in 6. DeeM28 (talk) 17:09, 26 June 2020 (UTC)
  4.  Oppose, regrettably, per John above around #6. I also am not fond of the idea that an RfC could be invalidated by not having gone through a draft. #2-3 seem okay, #4-5 seem needless and unnecessary instruction to the closer of the proposed draft RfC and bureaucracy for the proposer and closer to have to undergo. #7 is okay, but should have customary exclusions to post-RfC closing editing limitations to include a renamed user updating their signature to match their new username, copyediting their own comments for typographical or formatting errors, and very minor things like that. As I say, #2-3 are the strongest parts of this RfC, and I would support the idea to reword the Requests for Comment instruction page to recommend, but not require, RfC drafters draft an RfC in their own userspace (ideally). Dmehus (talk) 16:39, 27 June 2020 (UTC)
  5.  Oppose per John. This is creating policy for the sake of creating policy and doing so is generally not a good thing because "things happen". Amanda Catherine (talk) 23:18, 28 June 2020 (UTC)
  6.  Oppose this RFC is unnecessarily badly written, unnecessarily convoluted, and simply unnecessary. It adds extra steps to the RfC process that makes it more difficult to pass an RfC quickly and for new users to engage with the process something which is not aided by language choices like "is not in order" and "should not try to sabotage it". In fact, having commenting, amending, and voting happen simultaneously allows each to inform the others. Under this, a proposal could spend days being meticulously drafted on a user page and then flooded by opposes once it arrives at the RfC board by people who do not think that it is a good idea. Inversely, a proposal might end up being struck down simply because nobody spotted a critical flaw during the drafting process. Another notable result of this RfC is that connected discussions will end up scattered across half-a-dozen hard to keep track of RfCs as RfCs are ditched and re-drafted or amended and then reamended and alternate choices are brought up. This will also add to the difficulty of engaging with the process. ~ El Komodos Drago (talk to me) 18:02, 12 July 2020 (UTC)

Abstain/Comment[edit | edit source]

  •  Comment: I must start my comment by saying that I disagree with the phrase "The RfC itself should not offer alternatives and multiple-choice" as right now this precise reasoning forcing me to neither support nor oppose this RfC because I agree with some parts but disagree with others. I don't see why working on a separate RfC would be better than simply having multiple choices in one RfC. If a user simply disagrees with a few point in an RfC (as is my case) it would be very confusing for them to have to initiate a whole RfC to dispute one point. If we take a legislative body (disclaimer: I don't know much about them), if someone disagreed with one part of a text they would propose an amendment to said text which could then be voted on (equivalent to our choice of multiple proposals) rather than create a whole new text. Having said this however, I do agree with the fact that drafting an RfC beforehand and allowing users to add their proposals and amendments there rather than at the same time as the vote is taking place is sensible and I fully support that approach. Therefore from a practical point of view I  Support points: 1, 2, 5 and 7 and I  Oppose 3 (Comments may oppose the proposal -> this should be done in the voting period IMO), 4 (disagree with the strict rules imposed) and 6. I would say that my main concern is that we do not make the process of creating and voting on RfCs too complicated to a point where it may discourage users who are not so familiar with Miraheze or the process to take part in discussions. Reception123 (talk) (C) 17:13, 24 June 2020 (UTC)
  • As I set out below, an RfC cannot dictate the rules for its own passage, so the rule in this RfC against amendments-on-the-fly is not (yet) in effect. However, @DeeM28:'s split vote achieves the same thing in a way I had not thought of (and prohibited), cobbling together a new proposal while others are in the middle of voting on something else. Too many of these conditional votes and it could get baffling to figure out what we approved! @Reception123:'s comment (just above) reflects the same opinion about the RfC. In my book, he is properly a vote against, as under the RfC's (not-yet-mandatory) ground rules, he doesn't support the proposal as written, and the RfC suggests that we should go back and do some redrafting. Except that I don't agree with them because we don't need a big new rule that invites people not to follow it. Spıke (talk) 10:47 27-Jun-2020
  • Since this RfC is the creation of rule sentences, it seems that it is necessary to rewrite the rule sentences from scratch for proposals other than addition and removal of proposals.--松•Matsu (talk) 16:43, 28 June 2020 (UTC)
  • What does "Comments may oppose the proposal, and may propose to weaken it, but should not try to sabotage it" even mean? ~ El Komodos Drago (talk to me) 17:22, 12 July 2020 (UTC)

Comments received before the proposal was announced[edit | edit source]

From 松[edit | edit source]

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.") Spıke (talk) 18:03 15-Jun-2020
@Spike: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. Spıke (talk) 19:49 15-Jun-2020

From Dmehus[edit | edit source]

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)

@Dmehus: 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. Spıke (talk) 00:14 16-Jun-2020

From Reception123[edit | edit source]

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)
  • This became a formal RfC at 13:18 24 June 2020 (UTC)

Comments received during the editing phase[edit | edit source]

From 松[edit | edit source]

[Proposed amendment after withdrawal]

In this case, I think that the absence of comments during the public comment period will not hinder the transition to RfC.Currently,there are currently no rules to comment before publishing RfC.Therefore, the RfC I am currently commenting on is we don't have to follow new rules, and you can't adapt to past RfCs.(Even if this RfC is recognized, at that time, this RfC is a thing of the past.)This time, it may be better to install a new one like RfC_Beta rather than a revision.Because it is RfC for RfC, problems like Liar paradox may occur.(e.g. After the RfC vote began, if the RfC was approved based on current rules, even if the proposal was amended or the comment period did not go well, it often creates a contradiction. There is also a dilemma that there are currently no rules to prevent this problem.(I don't think there are many people who follow rules that don't exist.))The rules required for approval of RfC held to decide the rules of RfC_Beta are the current rules.By this,I think you can avoid Liar paradox. Also, since you haven't received any comments for a week, you may need an appropriate category (name) to indicate the RfC public draft, not the user subpage.

Addendum:I apologize in advance for the possibility that some of my expressions may seem offensive.I am ashamed of my lack of vocabulary.--松•Matsu (talk) 05:44, 24 June 2020 (UTC)

Reception123 had a similar comment on my talk page, so I will indeed submit it as an RfC.
I don't understand your reference to the Liar paradox, unless you think it is paradoxical that a draft RfC obeys its own rules that are not yet enacted. I did this as a courtesy, not because it is mandatory. Likewise, its life as an RfC is not on its own terms, and it should be valid to amend it or offer other ballots, which it seeks to prohibit in future RfCs. Spıke (talk) 13:08 24-Jun-2020
I realized that my worries were meaningless, not because they were mandatory, but because they were courtesy.--松•Matsu (talk) 15:31, 24 June 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it.
Retrieved from "https://meta.miraheze.org/w/index.php?title=Requests_for_Comment/Require_that_RfCs_undergo_a_public_comment_period&oldid=238188"