Requests for Comment/Requests for Comment

Since the Miraheze was created, Requests for Comment have never had any particular set rules and are currently based on convention and discretion solely. Following a discussion in a Miraheze Meeting where several users expressed support for some of my ideas (and proposed ideas of their own) it seems right not only to codify some existing conventions (which can be unclear) but also to add some new rules. This is to ensure that RfCs are created appropriately and to avoid situations where RfCs are out-of-scope, created rashly without much thought given, too vague, etc. which usually end up being opposed. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)

Co-initiator signature: Agent Isai  Talk to me! 06:55, 2 February 2022 (UTC)

Note: Due to the amount of proposals, in order to avoid potential edit conflicts, please consider voting for each section separately

Proposal 1 (Definition)

 * Requests for Comment (RfCs) are the mechanism by which the Miraheze community can discuss and vote on global policy proposals as well as other general matters pertaining to the Miraheze community.

Support (1)

 * 1)  as proposer. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  as co-initator.  Agent Isai  Talk to me! 15:55, 2 February 2022 (UTC)
 * I'm not sure if you're really a "co-initiator", as I've only seen one user talking about the idea. Still put the signature. --YellowFrogger ( talk ) ( ✔ ) 16:01, 2 February 2022 (UTC)
 * 1) --YellowFrogger  ( talk ) ( ✔ ) 15:57, 2 February 2022 (UTC)
 * 2)  I couldn't agree more. --DarkMatterMan4500 (talk) (contribs) 16:05, 2 February 2022 (UTC)
 * 3)  Appears to be an appropriate definition of what an Request for Comment is. --DeeM28 (talk) 18:08, 2 February 2022 (UTC)

Proposal 1.1 (Definition)

 * If the Miraheze community wishes to express a general recommendation, that may be done via a Feedback Requests (FRs) that will take place on the Community noticeboard, these are non-binding expressions of current opinion or interpretations of policy. An example of non-binding opinion/recommendation would be to recommend a certain action to be taken by SRE. Feedback Requests may also be used for single-issue policy amendments or clarifications.

Support (1.1)

 * 1)  as proposer. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  as co-initiator  Agent Isai  Talk to me! 15:56, 2 February 2022 (UTC)
 * 3)  He was responsible for the Purge and WikiSeo extension. --YellowFrogger  ( talk ) ( ✔ ) 15:59, 2 February 2022 (UTC)

Proposal 2 (Initiation)

 * In order to initiate a Request for Comment, the user proposing the Request for Comment must have at least one other user who is willing to co-initiate the Request for Comment. When the Request for Comment is published, the co-initiating user should be mentioned after the introductory statement and should sign themselves before voting begins (signing as co-initiator can also be done during the drafting process).

(Rationale: The rationale behind the co-initiator rule is to allow at least one other user to review the RfC in order to ensure that it's appropriate, written properly, etc. and to avoid situations when a user creates an RfC with little thought behind it. As with main initiators, a co-initiator does not have to support all (or any of) the proposals, they are just there to ensure that the RfC is adequately presented)

Support (2)

 * 1)  While this rule does impose a small restriction on initiating RfCs, I think it's necessary in order to allow someone else to review an RfC and make sure that thought has been put into it and that what is being proposed is clear. Of course, it's always possible for two users to also open an inadequately worded RfC, but the risk is less. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2) 100% per Reception123.  Agent Isai  Talk to me! 16:00, 2 February 2022 (UTC)
 * 3) Maybe avoid snowballing, but this one is more personal and feels more like a recommendation than a rule. --YellowFrogger  ( talk ) ( ✔ ) 16:03, 2 February 2022 (UTC)
 * It being a recommendation would arguably defeat its rationale which is to encourage discussion with someone else prior to opening an RfC. Reception123 (talk) ( C ) 16:05, 2 February 2022 (UTC)
 * 1)  While this is clearly a tough burden on users who do not have many connections at Miraheze I nonetheless weakly support it. In order to keep Requests for Comment serious and to not have the page flooded with requests which are not appropriate I agree that it is necessary to have an extra requirement in order to make sure that newcomers do not too quickly create RfCs without understanding the mechanism. A more flexible approach could have been sought however this current solution seems appropriate nonetheless as statistically speaking I am not aware of a successful RfC that has come from a new user with no connections so far and I think that is the case for obvious reasons. --DeeM28 (talk) 18:12, 2 February 2022 (UTC)

Proposal 2.1 (Initiation)

 * If a user is unable to find a co-initiator, they can instead request that a Steward or local Meta administrator reviews their drafted Request for Comment and signs-off on it.

(Rationale: The rationale behind this is in case a new user is not able to find a co-initiator and they should not be prevented from creating a Requests for Comment and should have an alternative path to RfCs)

Support (2.1)

 * 1)  While I see no problem with this idea, wouldn't asking a Steward or Meta administrator to 'sign-off' be the same as asking any user to co-initiate? The reason why I'd weakly support this is merely to make it clear to new users that they can ask Stewards or Meta sysops if they can't find anyone else. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  I agree with Reception123 that this should not be seen as anything special, just as an aid for newer users to know that they can ask a Steward/sysop to co-initiate an RfC. Since co-initiation != support, really anyone can co-initiate an RfC even if they don't support it's contents just as a gesture to affirm that they've verified that the user has not submitted a frivolous RfC.  Agent Isai  Talk to me! 16:05, 2 February 2022 (UTC)
 * 3)  In order to alleviate the toughness imposed by Proposal 2.0 this proposal will allow new users who wish to present a well-formed RfC to be able to by having a Steward review their 'work' prior to publication. --DeeM28 (talk) 18:13, 2 February 2022 (UTC)

Comments (2.1)

 * Similar to above as mentioned by user. This is worse because we only have 3 stewards, they will hardly respond. --YellowFrogger ( talk ) ( ✔ ) 16:07, 2 February 2022 (UTC)
 * The proposal indicates that "If a user is unable to find a co-initiator", so this does not require them to find a Steward, it is only an option they could use in the event that they are unable to find another regular user. Reception123 (talk) ( C ) 16:16, 2 February 2022 (UTC)

Proposal 3 (Voting)

 * Only registered users may initiate or vote in Requests for Comment. Unregistered users (IP editors) may not participate (i.e. comment) or vote in Requests for Comment.

Support (3)

 * 1) if Proposal 3.1 doesn't pass.  Agent Isai  Talk to me! 16:08, 2 February 2022 (UTC)
 * 2)  I do not see a reason for why allowances to users who are not registered must be made. On most websites that exist anonymous participation is not possible and user registration is required. In my view if an unregistered editor wants to participate in a Request for Comment they should create an account. Since creating an account does not even require an email there is no reason for why it should be difficult for someone to do so. Even if Proposal 3.1 allows comments only these comments can still very well influence other users and this influence may be undo if the IP/unregistered user is actually someone who is abusing multiple accounts. --DeeM28 (talk) 18:16, 2 February 2022 (UTC)
 * In my view if an unregistered editor wants to participate in a Request for Comment they should create an account. There's a proposal right here that doesn't allow new accounts to vote after creating an account after the RfC. --YellowFrogger ( talk ) ( ✔ ) 18:20, 2 February 2022 (UTC)

Oppose (3)

 * 1) . Unregistered editors should at most comment. Before I could. --YellowFrogger ( talk ) ( ✔ ) 16:08, 2 February 2022 (UTC)
 * 2) . Unregistered editors are also valuable.Jakeukalane (talk) 17:53, 2 February 2022 (UTC)

Comments (3)

 * 1) I conditionally  this proposal if Proposal 3.1 is not successful. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)

Proposal 3.1 (Voting)

 * Only registered users may initiate or vote in Requests for Comment. Unregistered users may participate in Requests for Comment by way of comments, but these will not ultimately be taken into account when deciding consensus and will not count as 'votes'.

NOTE: This proposal is an alternative to Proposal 3, with Proposal 3.1 allowing unregistered users to comment in RfCs.

Support (3.1)

 * 1)  I think it is fair to allow IP editors to express their views as long as their votes are not ultimately counted, mostly due to User accounts policy concerns. It's really easy to create an account so this shouldn't be imposing much of a restriction on anyone who wishes to vote. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  Nothing good has ever come out from an RfC created by IP users. Without a user account, it is very easy for anyone to use their home IP, work IP, school IP, coffeeshop IP, etc. to cast multiple votes. I could see a potential use case in which unregistered users may want to comment but allowing them to start/vote on RfCs, I would say no due to their long history of unhelpfulness and due to potential abuse.  Agent Isai  Talk to me! 16:42, 2 February 2022 (UTC)
 * 3) I remember voting here before, my vote was lost due to editing conflict before I think. Finally, IPs can express opinions about the case (especially with the candidate). --YellowFrogger  ( talk ) ( ✔ ) 17:29, 2 February 2022 (UTC)
 * Yeah, had voted before, accidentally removed? : Special:Diff/233572 --YellowFrogger ( talk ) ( ✔ ) 17:33, 2 February 2022 (UTC)

Oppose (3.1)

 * 1)  Per my support of Proposal 3 I do not support allowing unregistered editors to comment because comments are perfectly capable of influencing other views. I conditionally support this proposal if Proposal 3 is successful however because I assume the alternative would be to allow unregistered users to vote as well which would be totally unacceptable. --DeeM28 (talk) 18:18, 2 February 2022 (UTC)

Proposal 4 (Voting)

 * Users may not participate in Requests for Comment with more than a single account, in accordance with the User accounts policy.

Support (4)

 * 1)  This proposal is really just here to make things absolutely clear, but this is clearly already the case. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  While it is a violation of the User accounts policy to use multiple accounts to mislead people, this proposal allows for it to be very clear to users that sockpuppetry is against the spirit of Requests for Comment.  Agent Isai  Talk to me! 16:15, 2 February 2022 (UTC)
 * 3) This one is very obvious. If the user participates, he must state that the other account is his. I see users gaining rights in RfPs with votes from accounts created hours ago. --YellowFrogger  ( talk ) ( ✔ ) 16:19, 2 February 2022 (UTC)
 * 4)  Per my statement below. --DarkMatterMan4500 (talk) (contribs) 17:24, 2 February 2022 (UTC)
 * 5)  an obvious provision. --DeeM28 (talk) 18:18, 2 February 2022 (UTC)

Proposal 4.1 (Voting)

 * Users who created their accounts after a Request for Comment has been published may not vote in that Request for Comment. Such users may participate in Requests for Comment by way of comments, but these will not ultimately be taken into account when deciding consensus and will not count as 'votes'.

Support (4.1)

 * 1)  As a safeguard against the use of multiple accounts in order to influence the result of an RfC, I think this is necessary. While people opposing may claim that it's not fair because an RfC could run for weeks (or even months) and by then a new user could be involved in the Meta community I think it's nonetheless more important to make sure that RfCs are not inappropriately influenced by multiple account users. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  per Reception123. It is very important to uphold the integrity of Requests for Comment. While most RfCs don't run for too long (at most a few weeks), it is still very important to have such a safeguard so as to prevent the potential abuse that could arise from cases of sock/meatpuppetery.  Agent Isai  Talk to me! 16:17, 2 February 2022 (UTC)
 * 3) It looks like bureaucracy, but in fact it's actually prevention. --YellowFrogger  ( talk ) ( ✔ ) 16:22, 2 February 2022 (UTC)
 * 4)  Using multiple accounts in order to rig votes is unacceptable, and those who do so shall have their votes thrown out, and be blocked anyway (This may also be useful for the checkuser tool to be used if there was any form of vote rigging). This should serve as a huge reminder to voters who have multiple accounts to not vote multiple times, and to only vote once. Rigging votes on its own is just disruptive and goes against Miraheze's User accounts policy. --DarkMatterMan4500 (talk) (contribs) 17:23, 2 February 2022 (UTC)
 * 5)  Even if this indeed as is suggested above might stop new users of good faith from taking part in Requests for Comment that might take a long period of time in which the new user gets accomodated to Miraheze I think it is necessary to have that minor inconvenience in order to preserve the integrity of the RfC process. --DeeM28 (talk) 18:19, 2 February 2022 (UTC)

Proposal 5 (Drafting)

 * Users are strongly advised to create a draft Request for Comment before publishing it and opening it to a vote. Users can add their draft RfCs under the appropriate section of the Requests for Comment page and ask the community for feedback. During the drafting stage, there should be minimal discussion about the substantive issues and the focus should be on improving the existing proposals (wording, copyediting, etc.) or adding new proposals.

Support (5)

 * 1)  Drafting is clearly helpful and should be encouraged as much as possible. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  I think it is very important for RfCs to be drafted before being submitted to prevent SNOWballs and to prevent the community's time from being wasted unnecessarily with frivolous RfCs but at the same time, there are valid use cases in which drafting may need to be bypassed so I wouldn't want to make this a rigid mandate but instead just an exhortation.  Agent Isai  Talk to me! 16:20, 2 February 2022 (UTC)
 * 3) --YellowFrogger  ( talk ) ( ✔ ) 16:25, 2 February 2022 (UTC)
 * 4)  If Proposal 5.1 is not successful I definitely believe that drafting should be strongly recommended and RfCs opened without prior drafts frowned upon by the community. --DeeM28 (talk) 18:22, 2 February 2022 (UTC)

Proposal 5.1 (Drafting)

 * Users must create a draft Request for Comment before publishing it and opening it to a vote. Users should add their draft RfCs under the appropriate section of the Requests for Comment page and ask the community for feedback. During the drafting stage, there should be minimal discussion about the substantive issues and the focus should be on improving the existing proposals (wording, copyediting, etc.) or adding new proposals. A Request for Comment cannot be opened unless it has been drafted in advance and published on Meta as a draft. Drafts should stay open for at least three (3) days.

NOTE: This Proposal is an alternative to Proposal 5, making drafting mandatory rather than strongly recommended

Support (5.1)

 * 1)  I believe that in order to have the best version possible of an RfC mandatory drafting is a good idea since if it remains a recommendation only some people may still choose not to which generally will achieve RfCs of a lesser quality since the more people look at something the better it will become. --DeeM28 (talk) 18:21, 2 February 2022 (UTC)

Oppose (5.1)

 * 1)  While I strongly support the idea of drafting RfCs before publishing them and always do so myself, I don't feel like it needs to be an obligation at this point and can see some hypothetical situations where it would be easier/better to open one without a draft in place before. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2) Yes, this one is looking more bureaucratic. --YellowFrogger  ( talk ) ( ✔ ) 16:45, 2 February 2022 (UTC)

Abstain (5.1)

 * 1)  I wouldn't mind this at all, as long as it doesn't cause a butterfly effect in the end. --DarkMatterMan4500 (talk) (contribs) 17:19, 2 February 2022 (UTC)

Proposal 6.1 (New proposals/amendments)

 * After a Request for Comment has been published and is open for voting, users may add new proposals or amendments to existing proposals. It is however encouraged that this is done during the drafting process rather than once it is open in order to avoid confusion.

Support (6.1)

 * 1)  Since drafting is not mandatory (unless Proposal 5.1 passes) and that either way the drafting process is less advertised and less visible to users, I think it is fair to still allow people to add new proposals and amendments after voting has begun, even though it shouldn't be encouraged and in my opinion should only be done if it's really necessary. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  Adding a recommendation but not a full blown ban is the best course of action here for RfCs. I understand that things may slip in the drafting process and that's alright but we also want to make sure users think their RfC proposals over and don't later go adding proposals to already existing RfCs that will likely see little engagement due to voters thinking they've voted on all possible proposals.  Agent Isai  Talk to me! 16:23, 2 February 2022 (UTC)
 * 3)  It can assuage uncomfortable proposals as done in a recent RfC. --YellowFrogger  ( talk ) ( ✔ ) 16:47, 2 February 2022 (UTC)
 * 4)  It is very possible that following a discussion on an RfC proposal a user will get an idea for a better proposal or an amendment and it would be unfair to not allow them to add it. I acknowledge that it may be inconvenient for some reasons but not allowing the practice would not be a good idea in my view. --DeeM28 (talk) 18:24, 2 February 2022 (UTC)

Proposal 6.2 (New proposals/amendments)

 * After a Request for Comment has been published and is open for voting, no new proposals or amendments may be added. Any new proposals or amendments must go through a new Request for Comment.

This Proposal is an alternative to Proposal 6.1

Oppose (6.2)

 * 1)  Per above, I don't think a complete ban is appropriate and good ideas could be missed because of it. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2) Support that a user can open new proposals during an RfC. --YellowFrogger  ( talk ) ( ✔ ) 16:48, 2 February 2022 (UTC)
 * 3)  Per my comment in Proposal 6.1 --DeeM28 (talk) 18:24, 2 February 2022 (UTC)

Proposal 7 (Closure)

 * Requests for Comment must generally stay open for at least five (5) days. They can be closed before either if they are out-of-scope, invalid per Proposal 2 (assuming it passes), otherwise malformed or if it is clear that there is no chance of consensus.

Support (7)

 * 1)  Time should be given so that as many users possible can participate. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  per above.  Agent Isai  Talk to me! 16:24, 2 February 2022 (UTC)
 * 3)  --YellowFrogger  ( talk ) ( ✔ ) 16:50, 2 February 2022 (UTC)
 * 4)  It is sensible to have a minimum time limit as well as some exemptions to the general rule. --DeeM28 (talk) 18:25, 2 February 2022 (UTC)

Proposal 7.1 (Closure)

 * In the event that a Request for Comment is opened without a second user co-initiating it (assuming Proposal 2 passes), any registered user may close the Request for Comment as invalid. In all other cases, a Steward must close Requests for Comment.

Support (7.1)

 * 1)  The intention of the rule is to have less inappropriate RfCs, so it makes sense to allow for a quick closure. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  Reasonable proposal to prevent invalid RfCs from requiring unnecessary Steward attention which may rob time from other crucial tasks at hand.  Agent Isai  Talk to me! 16:26, 2 February 2022 (UTC)
 * 3)  Without allowing users to close requests that clearly fall foul of the rule in Proposal 2 invalid requests may go on for hours and people would potentially waste their time while taking part in them. Since whether there is a co-initiator or not present is clear to anybody and not open to debate it is fair that users should be able to close such requests as invalid. --DeeM28 (talk) 18:27, 2 February 2022 (UTC)

Oppose (7.1)

 * 1) While it's good that a user should consult with others before opening an RfC, there's no need to reach the last level if they don't. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 16:57, 2 February 2022 (UTC)
 * 2) I don't think is neccesary to reach this levels of pre-consult everything.... Jakeukalane (talk) 18:22, 2 February 2022 (UTC)
 * I do not believe there is any question of 'pre-consulting' here - the opposite actually. This proposal means (as I understand it) that any user can close a clearly invalid request rather than only Stewards being allowed to do that. --DeeM28 (talk) 18:28, 2 February 2022 (UTC)
 * But it doesn't say that. Says anyone can close a RfC if there are not two people supporting it from the beginning. So, in order to open a RfC you need to consult with other user, if not anyone can close it without needing an excuse for it. Jakeukalane (talk) 18:35, 2 February 2022 (UTC)

Proposal 7.2 (Closure)

 * In addition to Proposal 6.1, users may also close clearly out-of-scope or malformed requests.

Support (7.2)

 * 1) because there is a chance that proposals like this are just a SNOW, as I saw in an RfC about users having rights when adopting a Wiki, which was unanimously opposed for being poorly formatted. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:05, 2 February 2022 (UTC)
 * 2)  I definitely couldn't agree more, but having to be buried under an avalanche is just too much pressure for the whole community. --DarkMatterMan4500 (talk) (contribs) 17:18, 2 February 2022 (UTC)

Oppose (7.2)

 * 1)  While I supported Proposal 7.1 I cannot support this proposal. While in Proposal 7.1 there is a binary question: is there a co-initiator? in this case the issue is more complicated and it is possible to lead to user disputes about whether something is out-of-scope or not. With the co-initiator rule it is also less likely that such situations occur and if they do a Steward can handle them. --DeeM28 (talk) 18:29, 2 February 2022 (UTC)

Proposal 7.3 (Closure)

 * If a Request for Comment is opened without having been drafted in advance, a Steward may close it immediately if it is too vague or unclear.

Support (7.3)

 * 1)  as proposer. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  Very reasonable. This allows for Stewards to close proposals which may unnecessarily waste the community's time.  Agent Isai  Talk to me! 16:28, 2 February 2022 (UTC)
 * 3)  Yes. This should serve as a reminder to those who plan on making ridiculous RfCs that are intended for disruptive purposes to not do so. We don't want a whole backlog of unnecessary RfCs or disruptive RfCs that are bound to be snowballed in the end. --DarkMatterMan4500 (talk) (contribs) 17:15, 2 February 2022 (UTC)
 * 4)  Obviously this should be possible. --DeeM28 (talk) 18:30, 2 February 2022 (UTC)

Oppose (7.3)

 * 1) Per 7.1, we don't need to get to the last level. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:07, 2 February 2022 (UTC)

Proposal 8 (Withdrawal)

 * The original initiator may not only withdraw a Request for Comment except if: there have been no support votes or if all users who expressed support agree with the withdrawal.

Support (8)

 * 1)  I don't think it would be fair for the person that initiated an RfC to have that much power over it, especially if people like the ideas and have already supported. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  per above.  Agent Isai  Talk to me! 16:39, 2 February 2022 (UTC)
 * 3) I thought had this before. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:09, 2 February 2022 (UTC)
 * 4)  a sensible idea. --DeeM28 (talk) 18:31, 2 February 2022 (UTC)

Proposal 9 (Consensus)

 * No minimum threshold or support ratio exists for Requests for Comments. Stewards will use their discretion to decide whether consensus has been reached on a proposal.

Support (9)

 * 1)  At this time, I don't think a minimum threshold or support ratio would be helpful for RfCs. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2)  Stewards are elected by the community to interpret consensus, I think we can definitely trust them to interpret consensus in edge cases.  Agent Isai  Talk to me! 16:38, 2 February 2022 (UTC)
 * 3) thanks to the opinions of stewards that bad proposals didn't pass, despite having great support. To me, it's better to have a big comment justifying the opposition than a lot of dull support citing "per above", instead of forming your own opinion of what is best for you. Comments like that should have no effect. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:20, 2 February 2022 (UTC)
 * 4)  I do not think that it would be easily to define an appropriate threshold or minimum ratio for Request for Comment due to their complex and diverse nature so leaving them to discretion of the Stewards is an appropriate solution. --DeeM28 (talk) 18:32, 2 February 2022 (UTC)

Proposal 10 (Local Meta RfCs)

 * Local Meta Requests for Comment will be subject to the same rules as above, except that all mentions of Stewards are replaced by Meta Bureaucrats. Stewards may still close local Requests for Comment in limited circumstances. Local Meta RfCs should clearly be identified.

Support (10)

 * 1)  Makes sense to have the same rules. Reception123 (talk) ( C ) 15:46, 2 February 2022 (UTC)
 * 2) Clear. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 17:25, 2 February 2022 (UTC)
 * 3)  There is no real reason why Meta's standards from RfCs should differ from global ones. --DeeM28 (talk) 18:32, 2 February 2022 (UTC)