VOOZH about

URL: https://en.wikipedia.org/wiki/Wikipedia_talk:Requests_for_comment

⇱ Wikipedia talk:Requests for comment - Wikipedia

Jump to content
From Wikipedia, the free encyclopedia
This is the talk page for discussing Requests for comment and anything related to its purposes and tasks.
👁 Image
NOTE: This talk page is not the place to post notices of disputes or requests for comment, or to ask questions about changes you would like to make to individual articles. Please follow Wikipedia:Requests for comment.
👁 Image
Are you having trouble getting your RfC listed? Please make sure the bot hasn't been turned off. If the bot hasn't run in the last few hours, then please alert the bot's owner. If the bot is apparently running, then the problem is almost certainly with the template formatting. To get help with formatting the template correctly, please leave a message, including the name of the page where you want to start the RfC, at the bottom of this page.
Frequently asked questions
The RFC question isn't neutral!
Wikipedians are rarely swayed by a non-neutral question. They've got their own minds and they'll come to their own conclusions. A non-neutral question might be a good reason to fix the question, but it is not usually grounds to halt or re-start the RFC. If you believe that a question is non-neutral, you are better off simply participating in the RFC to present arguments about the underlying dispute. An additional comment about the question's neutrality may or may not be appropriate, depending on its relevance to those arguments.
The RFC question is not brief. Can I fix it?
The "question" is the part that shows up on the RFC listing pages (example of listing page). If the RFC question itself is substantially longer than all the others and you are not appearing in the role of the loyal opposition, then you can copy a small part the original question plus the original timestamp (not usually the name) to the top or write a simplified question. If, however, the person who started the RFC discussion might consider you to be part of the dispute, you should ask someone else to adjust it (e.g., by asking the person who started the RFC to shorten it or by posting a note on the RFC talk page).
I don't like any of the options I've been asked to vote for.
RFCs aren't votes. You can suggest a compromise or an option that others haven't considered, exactly like you would in any other talk page discussion.
How long should an RFC last?
As long as all of the participants need, and no longer. If you started an RFC, and you believe other editors will not agree to your proposal, then you are permitted to admit defeat and withdraw it at any time. However, editors who believe their side is winning are advised to not even mention the possibility of ending an RFC early during the first week.
Is the result of an RFC binding?
Not inherently, but an RFC is usually an effective way of determining the consensus of editors, which is binding. The formal closing summary of an RFC is generally considered to be a summary of the current consensus, although consensus can change over time.
Aren't all RFCs supposed to get a formal closing summary?
No. Most of the time, the result is clear to all of the participants, and editors should not waste the community's time by asking someone else to officially write down what everyone already knows. Only a minority of RFCs get closing summary statements.
Can the person who started the RFC, or another involved editor, write a summary of the discussion?
Yes. In particular, when a proposal is soundly rejected, proponents are encouraged to accept defeat with grace. However, if the outcome could plausibly be disputed, then involved editors (on all sides of a dispute) are encouraged to let someone else write a summary.
There was an RFC a long time ago, but we're doing something different now. Do we have to hold a second RFC to officially over-rule the old RFC?
No. Consensus can change, and an RFC is not required to prove that the community's consensus has changed. However, if you have a dispute about what the current consensus is, then a new RFC is one way to resolve that dispute.
How many RFCs are there?
As of 2024, there are usually about two RFCs started each day. Before 2021, there were about three new RFCs each day.
How many people comment in RFCs?
The number of respondents varies depending on the subject area and the amount of effort needed to answer the question (e.g., higher for popular articles, lower for highly technical questions). It's not unusual to see about five to 20 people participate in a discussion, with a possible range from zero responses to (rarely) several hundred.

Archives
  1. Feb 2004
  2. Feb 2004–May 2005
  3. May 2005–Sep 2005
  4. Sep 2005–Oct 2005
  5. Oct 2005–May 2006
  6. May 2006–Dec 2006
  7. Jan 2007–Jun 2007
  8. July 2007–Dec 2007
  9. Jan 2008-Feb 2009
  10. Feb 2009-Feb 2010
  11. Feb 2010-January 2012
  12. January 2012—May 2013
  13. May 2013–August 2015
  14. August 2015–October 2016
  15. October 2016–June 2018
  16. June 2018–June 2020
  17. June 2020–April 2021
  18. April 2021–November 2021
  19. November 2021–May 2023
  20. June 2023–
  21. (future)
This page has archives. Topics inactive for 40 days are automatically archived 1 or more at a time by Lowercase sigmabot III.

Ways to handle Bad RfC

[edit]

An RfC was closed as bad on a page where I’m a contributor. I agree that the RfC needed to be reformatted. I’m wondering if there’s a more welcoming way to handle it. Here’s the close: Talk:2025 Potomac River mid-air collision#c-Rosbif73-20260218095600-RfC: Should it be changed from American Airlines Flight 5342 to American Eagle F Dw31415 (talk) 13:38, 18 February 2026 (UTC)[]

@Rosbif73, I agree with your assessment of the above RfC. There was a previous discussion about BadRfC’s here. Maybe this example helps find a consensus on how to handle. Dw31415 (talk) 13:42, 18 February 2026 (UTC)[]
I’ll look for the recent BadRfC discussion but I appreciate it if someone else links to it first. Dw31415 (talk) 13:56, 18 February 2026 (UTC)[]
  • I'm leaning towards reverting that close, which ought to have been a !vote. I'm almost, but not quite, certain enough to revert it summarily without discussion.—S Marshall T/C 14:21, 18 February 2026 (UTC)[]
    I say leave it closed because I coached the nominator on… wait a minute, the project RfC is still open. I’ll link to it here and on the talk page: Wikipedia talk:WikiProject Aviation#c-Zaptain United-20251101023400-RfC: Should the article title be styled as the IATA name, Branded name, or the I Dw31415 (talk) 15:01, 18 February 2026 (UTC)[]
    Then again, reverting would restore the FRS link. I didn’t revert because that felt like one aggressive response to another. I’d really appreciate some consensus on handling BadRfC’s, specifically, altering the question in the early days. Dw31415 (talk) 15:09, 18 February 2026 (UTC)[]
    I fixed the FRS link by adding ann anchor tag. Dw31415 (talk) 15:38, 18 February 2026 (UTC)[]
    My main rationale for the quick close was the rambling, non-neutral statement coupled with the apparent absence of any RFCBEFORE, and thus no apparent reason for holding an RfC rather than just a normal talk page discussion. It has now been pointed out that the issue had been raised previously. I didn't mean this to come across as an aggressive response, and I'd understand if the close is reverted. But I agree that consensus on how to handle "bad" RfCs would be helpful. It seems common that in cases where a poorly worded nom statement is amended after discussion has started, the whole process is often derailed, with meta-discussions about the statement mixed in with actual discussions about the issue at hand, and participants being unsure what they're !voting on. Rosbif73 (talk) 15:25, 18 February 2026 (UTC)[]
    @Rosbif73, please to go WP:RFCBEFORE and look for the little box in the sidebar. Find the words that say:
    "Are you trying to shut down someone else's RFC? "RFCBEFORE" is good advice, but it's not required."
    Having read that, do you now agree with me that "most importantly no WP:RFCBEFORE" isn't (ever) a valid reason to unilaterally shut down someone else's RFC? And what could we do to make that easier for experienced editors like you to discover this?
    The correct responses to an RFC such as that one are (in no particular order):
    • Add a brief, neutral RFC question to the top. For example, add "This article says 'American Airlines' throughout. Should we change that to 'American Eagle' instead? ~~~~~" (five tildes, so that nobody's name is in it).
    • Provide a sensible response (a "vote"). A clear reply can do a lot to reduce confusion.
    • Ask the OP if they'd like help improving or clarifying their RFC question (or if they'd like to use a different process).
    • Ask for help on this page.
    WhatamIdoing (talk) 18:01, 18 February 2026 (UTC)[]
    Having read WP:RFC more thoroughly, I entirely agree that my close was out of order, and apologise to @Zaptain United (the nom of the discussion in question) in particular.
    How could things be improved to make this easier to discover? Two quick comments: Firstly, the "are you trying to shut down..." sidebar isn't particularly visible, and the centralised discussion box pushes it down so that it isn't even opposite RFCBEFORE. Secondly, perhaps some advice about how not to close could be added to RFCEND, which seems a more logical place than RFCBEFORE to start looking for advice for someone considering closing an RFC. Rosbif73 (talk) 08:24, 19 February 2026 (UTC)[]
    Your gracious and reflective approach here is admirable. Respect.—S Marshall T/C 09:26, 19 February 2026 (UTC)[]
    +1 Dw31415 (talk) 12:43, 19 February 2026 (UTC)[]
    These are both great ideas. Maybe the box could get a little light blue background? Or an image that might catch someone's eye?
    I love the idea of putting something in RFCEND. I agree with you that this is actually the sensible place for people to look for that information. Do you want to add something yourself to WP:RFCEND? WhatamIdoing (talk) 22:57, 19 February 2026 (UTC)[]
    I've boldly added a {{tick}} and a {{n.b.}} to the side box. But I'm not yet confident that I understand the consensus surrounding early closes well enough to add something to WP:RFCEND. Would it be true to say that an early close of a bad RFC is always frowned upon, or are there cases where it would be recommended? For example, if an RFC proposed something that was a blatant violation of policy (say a suggestion to add information that would be a clear WP:BLPPRIVACY concern), would it be better to close the RFC preemptively, or just remove any concerns from the statement itself and then wait for it to SNOW? Rosbif73 (talk) 10:38, 20 February 2026 (UTC)[]
    That sidebox is against consensus (and worse yet, a bad idea), so drawing yet more attention to it is not an improvement. It should be removed.
    A minority thinks the RfC should be an unstoppable weapon, and there is no such thing as a bad RfC. This is incorrect. Polygnotus (talk) 10:58, 20 February 2026 (UTC)[]
    You disagree with the sidebox. However, you are not "consensus". WhatamIdoing (talk) 18:53, 20 February 2026 (UTC)[]
    Agreed. Neither of us is. That is my point. Polygnotus (talk) 19:00, 20 February 2026 (UTC)[]
    Here’s the last discussion: Wikipedia talk:Requests for comment#Bad RFC votes Dw31415 (talk) 15:51, 18 February 2026 (UTC)[]
    On my screen, that link doesn't work. On my screen it's at Wikipedia talk:Requests for comment/Archive 23#Bad RFC votes.—S Marshall T/C 20:02, 18 February 2026 (UTC)[]
  • OK. "Bad RfC" is an increasingly common response to a RfC question that the !voter doesn't want to proceed for various reasons, and we're increasingly seeing it appear in bold face. "Bad RfC -- question isn't neutral" or "Bad RfC -- see previous discussions X, Y, and Z" or "Bad RfC -- wrong place" all come into this category and they need different responses and get different weights.What we have for guidance on this is Wikipedia talk:Requests for comment/FAQ. I think it covers this situation.—S Marshall T/C 15:50, 18 February 2026 (UTC)[]
    Good point, Wikipedia:RFCRESPOND does explicitly say not to close a poorly worded RfC Dw31415 (talk) 15:57, 18 February 2026 (UTC)[]
    @S Marshall, the FAQ link above doesn’t work and I can’t find it. Would you please check the FAQ link? Dw31415 (talk) 16:09, 18 February 2026 (UTC)[]
    Well that's confusing. It's a valid link and it works fine for me. It's the template that appears near the top of this page.—S Marshall T/C 16:17, 18 February 2026 (UTC)[]
    Very strange! I get an empty talk page (Chrome on iOS) Dw31415 (talk) 16:20, 18 February 2026 (UTC)[]
    Oh, the FAQ is there hidden under “Learn more about this page”. Dw31415 (talk) 16:26, 18 February 2026 (UTC)[]
    All 'top matter' is hidden on the mobile site. WhatamIdoing (talk) 17:53, 18 February 2026 (UTC)[]
    Maybe some of the FAQ needs to find its way into the main page, especially since it's not so visible for editors using the mobile site. WhatamIdoing (talk) 18:02, 18 February 2026 (UTC)[]
  • Is there any way to deprecate the words “Bad RFC”? Sure, there are flawed RFCs (Non-neutral questions, overly rambling statements, etc) but it seems bitey to label any attempt to find consensus as “BAD” (naughty, naughty! Shame on you!). Blueboar (talk) 21:07, 18 February 2026 (UTC)[]
    This is the naming convention used everywhere else. Polygnotus (talk) 22:40, 18 February 2026 (UTC)[]
    We could make something like Template:Single-purpose account that can be used in opposition, e.g.:
    —See WP:RFCRESPOND and WP:RFCFAQ for advice on responding appropriately to RFCs that you believe are unnecessary, poorly framed, or otherwise improper.
    If there was relevant information at those two locations and the template got used fifty or a hundred times, I think people would get the message over time. WhatamIdoing (talk) 21:24, 18 February 2026 (UTC)[]
    The fundamental problem of BADRFCs cannot be solved by yet another obscure template, the problem can be solved by allowing people to close bad RfCs. Polygnotus (talk) 22:36, 18 February 2026 (UTC)[]
    Many reasonably contentious RfCs get !votes saying "Bad RfC", and they have different values and validities. For example:
    VoteActual objectionRecommended outcome
    Bad RfCQuestion isn't neutralUninvolved person to evaluate: if true, fix the question
    Bad RfCRepeat of recent, relevant previous discussionsUninvolved person to evaluate: if true, summarily close the RfC linking previous consensus
    Bad RfCWrong processUninvolved person to evaluate: if appropriate, move to RM, MR, DRV, PM, etc.
    Bad RfCPrematureUninvolved person to evaluate: if appropriate, convert to regular talk page discussion
    Bad RfCI want this to failUninvolved person to evaluate and offer support and guidance
    I wish we had more people clerking RfC.—S Marshall T/C 22:42, 18 February 2026 (UTC)[]
    @S Marshall I wish the tiny group of people who set the rules around here would stop trying to make the RfC the unstoppable weapon of mass destruction.
    Speculating that people who want to close an RfC are doing so in bad faith is a terrible look.
    Assuming that there is a huge number of "uninvolved" editors going around fixing bad RfC questions, closing and moving discussions is just incorrect. Polygnotus (talk) 22:46, 18 February 2026 (UTC)[]
    And you wrote if appropriate, convert to regular talk page discussion but RfCs are supposed to be regular talk page discussions with no special status. It is completely unworkable for me to go around closing lets say 60% of RfCs for being premature, but I wouldn't be surprised if 60% of RfCs are premature. Polygnotus (talk) 22:47, 18 February 2026 (UTC)[]
    I join issue with you on all that you say. I feel that summarily closing a RfC should be rare---although I have recently done it. Where the RfC is "bad", as it were, but we're dealing with a good faith user who thinks there's a problem to solve, the discussion should typically be delisted as a RfC with an explanatory note, but allowed to continue.I absolutely believe that there are people who use "Bad RfC" !votes as a spoiling tactic to prevent changes they oppose, and I think it's naive to pretend otherwise.RfC is Wikipedia's highest content dispute resolution process. It's an attempt to find consensus, and consensus is God Almighty.—S Marshall T/C 22:53, 18 February 2026 (UTC)[]
    @S Marshall Where the RfC is "bad", as it were, but we're dealing with a good faith user who thinks there's a problem to solve, the discussion should typically be delisted as a RfC with an explanatory note, but allowed to continue. I agree with that. In exceptional cases (e.g. trolls, IDHT) you can remove the template and close the discussion as well, but those are relatively rare compared to cases in which the template should just be removed and the discussion should continue.
    I absolutely believe that there are people who use "Bad RfC" !votes as a spoiling tactic to prevent changes they oppose, and I think it's naive to pretend otherwise. Maybe, but my point is not that they don't exist, my point is that its a bad look to assume bad faith in such cases. People disagree, you know. People have a different background, some people get the wrong end of the stick once in a while, some people consistently do and always say things that I believe are incorrect. But often they do it with the best of faith, which is very frustrating.
    RfC is Wikipedia's highest content dispute resolution process. No it isn't. A discussion is Wikipedia's only content dispute resolution process. The RfC tag is just a way to try to attract more people to a specific discussion.
    But since everyone thinks that the discussion they started is super important and needs immediate attention from a large group of people, we need to have a way to stop people wasting a fuckton of time. Wikipedia:Most ideas are bad and all that. Wasting everyone's time is a form of disruptive editing. Polygnotus (talk) 23:04, 18 February 2026 (UTC)[]
    We still get plenty of people - not all of them newbies - who launch an RfC as the first step in discussing a somewhat minor matter. It feels as if they believe that RfC is the only way of discussing a proposal. --Redrose64 🌹 (talk) 23:03, 18 February 2026 (UTC)[]
    For a low-traffic page, that's not a completely unreasonable belief. WhatamIdoing (talk) 01:10, 19 February 2026 (UTC)[]
    False, see WP:SEEKINPUT. Elevating RfCs over all other methods of getting more input leads to a lot of wasted time and effort. Polygnotus (talk) 01:11, 19 February 2026 (UTC)[]
    Another common failure mode for RFCs worth considering is when the question doesn't actually address the real problem on the page (I touched on one form of this in an essay at WP:MOTTE, but it's important to understand that it can happen very easily by accident just because the people on the page are talking past each other.) If the question for the RFC isn't well-formulated, all the time spent answering it could be wasted; and it sometimes won't be clear that there's a problem unless you're knee-deep in the dispute. Sometimes an ill-formatted question can be fixed by responses to the RFC along the lines of "this RFC asks X, but I think the real underlying question is Y, so I'm gonna answer that" (common for eg. questions where "is this a WP:RS" and "is this WP:DUE" are confused), but it can be a bit rough and make for a pretty confusing or hard-to-close RFC, especially if you end up with a bunch of people answering different questions. --Aquillion (talk) 06:29, 3 March 2026 (UTC)[]
    +1 for a template. I think it adds a little heft to reinforce the consensus view of how to respond to either the preemptive close or a more gentle nudge that the RFC question needs some attention. I'd be happy to join on working on it. Dw31415 (talk) 23:44, 18 February 2026 (UTC)[]
    Generally speaking, if the proposed solution to an alleged problem is concentrating yet more power in the hands of a tiny few, it is a terrible idea.
    Not just on Wikipedia, also in real life.
    Wikipedia talk:Requests for comment/FAQ is not supported by consensus and is mainly the work of 1 editor. Polygnotus (talk) 01:43, 19 February 2026 (UTC)[]
    I think a template would be better than one editor preemptively closing or another reverting the preemptive close, but open to ideas. I’d just like to see something change. Dw31415 (talk) 02:08, 19 February 2026 (UTC)[]
    Making a template available to everyone is the opposite of "concentrating yet more power in the hands of a tiny few".
    I have seen no evidence that the WP:RFCFAQ doesn't have consensus. I'm the person most likely to take the trouble to document the answers to common questions, but the answers are not just something I made up personally. WhatamIdoing (talk) 02:12, 19 February 2026 (UTC)[]
    Then you won't mind if I put my personal opinion somewhere and then post an official-looking template everywhere to link to it which heavily implies my way is correct and supported by consensus while others are not...
    But of course you would object to that, because that would feel unfair to you. So you doing the same feels unfair to me.
    I'm the person most likely to take the trouble to document the answers to common questions And I think that it is really important that someone does that job, and a lot of your edits are improvements, but we do end up in a situation where less than a handful of people decide important stuff for everyone else.
    And that wouldn't be a problem if those people never got the wrong end of the stick. But in this particular case, these attempts to make RfCs unstoppable weapons are misguided and they will exacerbate the problems we already have with RfCs (low quality, misleading, unfair advantage for the starter, presenting limited options leads to inferior decisions compared to a discussion et cetera et cetera).
    And since your position is in the minority, even with some of these advantages, it is probably not a good idea to make even more changes against consensus.
    Again, if you want to handle this fairly, lets combine forces and make an RfC that presents both our views side by side and then we can let the community decide. Polygnotus (talk) 12:04, 20 February 2026 (UTC)[]
    I think an RfC on preemptive closes would be a good thing and suggest we workshop it in a new section here. Dw31415 (talk) 13:22, 20 February 2026 (UTC)[]
    Sounds like a good idea. There are a few things it would be good to get wider input on. Polygnotus (talk) 13:35, 20 February 2026 (UTC)[]
    That's a tricky kind of discussion to have, especially with semi-random editors. Maybe just start with a regular discussion? It might help us understand how to frame it. WhatamIdoing (talk) 18:28, 20 February 2026 (UTC)[]
    Yeah we started in the section below with a regular discussion. Please do not start an RfC. Polygnotus (talk) 18:30, 20 February 2026 (UTC)[]
👁 Image
 I'm against a "Bad RfC" template. If you don't happen to like me putting my opinion on an RfC, you're free to object rather than trying to limit my freedom to object. Peter Gulutzan (talk) 20:37, 23 February 2026 (UTC)[]
Are you for or against preemptive closes (shutting down an RfC)? Like Talk:2025 Potomac River mid-air collision#c-Rosbif73-20260218095600-RfC: Should it be changed from American Airlines Flight 5342 to American Eagle F Dw31415 (talk) 01:47, 24 February 2026 (UTC)[]
That doesn't contain "Bad RfC". I thought from the thread title and the suggestion about finding a way to "deprecate" saying those words and the "template" proposal that this was about shutting down people like me who use those words. Peter Gulutzan (talk) 16:43, 2 March 2026 (UTC)[]
I started this conversation in hopes of reducing the occurrence of editors “shutting down” or “preemptively” closing RfC’s. I’m personally less concerned with “BadRfC !votes”. I’ve been waiting to see if a challenge arises to the current project page text, before making a concrete template suggestion. Your message is a good prompt that maybe it’s time to stop waiting. Dw31415 (talk) 19:24, 2 March 2026 (UTC)[]
"Free to object"...so long as the editors who are freely objecting don't use a template to do so? It's not like the template has any special consequences or power over the person posting a "bad RFC" !vote. WhatamIdoing (talk) 06:03, 3 March 2026 (UTC)[]
In the RFCBEFORE section, would it be helpful to elaborate on "If you are not sure if an RfC is necessary, or about how best to frame it, ask on the talk page of this project"? Two possibilities:
  • "Consider discussing your planned RfC question on the talk page or on this page's talk page, to see whether other editors have ideas for making it clearer, more concise, or more neutral, or whether they think an RfC is necessary or the right process." Then for #1 in RFCOPEN, add "and that you've considered workshopping the question" to the existing text. I think it could help to bring this possibility up sooner.
  • Add some questions to ask oneself, drawing on some of the issues that S Marshall raised in his table above, perhaps including the next step as well. For example, "Is this issue a repeat of recent, relevant previous discussions? If so, another discussion may not be needed at this time." "Is an RfC the right process, or would it be more appropriate to use RM, MR, DRV, PM, etc.?" "Is it premature? Consider using a regular talk page discussion." Etc.
FactOrOpinion (talk) 22:02, 20 February 2026 (UTC)[]
The first point is currently made under WP:RFCNEUTRAL. One question is whether we want to scatter it all around the page (that might sound bad, but it's sometimes the right choice) or concentrate it in one spot.
The second point sounds a little WP:CREEPY for this page but sounds like a valuable expansion of Wikipedia:Writing requests for comment. WhatamIdoing (talk) 05:28, 21 February 2026 (UTC)[]
In this case, I think it's best to scatter a bit. My guess is that editors who read this page are most often inexperienced creating an RfC (or perhaps they want to check something, such as whether modifying someone else's RfC question is allowed). I think it would help to say more than once that if you're having difficulty writing a brief, clear, neutral RfC question, consider workshopping the question before opening the RfC, and you can ask for help or feedback on this talk page or on the article's talk page (or policy talk page, etc., if the RfC is about a policy, ...). That way, if it doesn't sink in the first time, or they miss the suggestion in one location, hopefully they'll see it in another location. FactOrOpinion (talk) 17:54, 23 February 2026 (UTC)[]
I wonder how many RFC questions are explicitly workshopped in advance. WhatamIdoing (talk) 01:49, 24 February 2026 (UTC)[]
  • Part of the issue is that once an RFC gets going, it is very hard to fix issues with it or to close it early (unless it's a WP:SNOW situation.) For this reason I do think we should extend the benefit of the doubt to people who immediately lunge onto an RFC and close it right after it was opened, provided they articulate clear problems they have with it and are clearly working towards having a better RFC opened in a reasonable timeframe rather than just stonewalling. Yes, sure, that RFC could in theory have continued, but I don't think that that was a particularly great opening statement (to put it mildly) and I think taking a day or so to hammer out something better is not unreasonable. If a fatally-flawed RFC continues, we risk wasting the entire time that it's open and all the time and energy editors put into it. And it won't always be obvious to people at a glance what the problem is (one common form of fatally-flawed RFC asks a question that seems reasonable at a glance but which doesn't actually cover or resolve the underlying dispute on the page, which means that it can go for a month, get a bunch of people weighing in, then solve nothing regardless of how it's closed.) I think it's fair to give everyone involved in a dispute a chance to weigh in, which includes broad latitude to say "wait hold up" for at least a brief period of time provided they're not stonewalling and they articulate at least somewhat reasonable objections that point towards a potentially improved RFC. --Aquillion (talk) 06:29, 3 March 2026 (UTC)[]
    That does sometimes work, and I've even seen it work when the person stopping the RFC advertisements is a declared opponent of the RFC's proposal. But it often fails, sometimes very badly, so I'd rather that the 'loyal opposition' normally took a hint from WP:INVOLVED and found someone else to shut down a poorly conceived RFC. WhatamIdoing (talk) 06:10, 4 March 2026 (UTC)[]

Potential hypothetical theoretical disagreements

[edit]

There are a bunch of things that it would be good to get input on.

This is a work in progress/brainstorm. Please do not yet ask for more input. My brain is old and slow and it needs a couple of days to think.

I also need to go through the history of this page to see the various ways in which RfCs were elevated to unstoppable weapons (e.g. WP:BADRFC was deleted, WP:RFCBEFORE was neutered (for example here), a sidebox was added and there was even an proposal for a new template to truly make RfCs unstoppable).

  • Should one person just be allowed to change the rules for everyone without consensus?
  • Should RfCs be like !votes or should the RfC template just be another way to draw attention to a discussion
  • Should the person who starts the RfC get to choose the !voting options, if any, which makes it easy to present a false dichotomy
  • Should the RfC starter get to post a long non-neutral introduction
  • Should others be allowed to remove the RfC template when appropriate
  • Should people be forced to follow RFCBEFORE (before it got neutered)
  • Why not have an RfC where both sides present their view side by side

What else am I missing?

I actually had to make a tool that uses Claude to show how Wikipedia:Requests for comment evolved over time. Polygnotus (talk) 13:42, 20 February 2026 (UTC)[]

Far too many RfCs end up a mess, and at least some of it is down to the issues you raise here. As the situation currently stands, it is way too easy to construct a 'loaded' RfC, one that asks an ambiguous question, or one that clearly isn't going to solve an underlying issue. As to how to how best fix this, I'm unsure. If it wasn't yet another layer of bureaucracy, some sort of formal system for approving RfC questions in advance might possible help, though no doubt people would find ways to game that too. At minimum, I think we need to make it clearer to people starting RfCs that if they are going to ask for the broader community's time and attention, they need to put some serious thought into what they are doing first. And make it clear that failing to do so is likely to waste their time as well as everyone else's, since a messed-up RfC is unlikely to resolve anything. AndyTheGrump (talk) 14:19, 20 February 2026 (UTC)[]
@AndyTheGrump, I agree with you that these problems will always be with us. I think that part of our defense system has to rely on responding editors being smart and sensible.
You mention the importance of the underlying problems, and I think that's important to keep in mind when we talk about "bad" RFC questions. Sometimes the problem that needs solving isn't "What's the consensus?" but "I don't feel heard about ____". Accepting a loaded or biased RFC question may be the only way we can solve the underlying problem. Sometimes we have an editor who needs to be able to ask the community "Since WP:DAILYMAIL is obviously the most reliable source in the history of the universe, I propose that it be declared WP:GREL on Wikipedia:Reliable sources/Perennial sources", and then see what the community says, because a facially neutral question wouldn't make them feel like the community understood their view of The Daily Mail. Humans tend to believe that their view is the neutral, middle-of-the-road view, even if they're quite on the extreme end. WhatamIdoing (talk) 20:23, 20 February 2026 (UTC)[]
It is hard to believe that 50 people need to get messaged to get an answer to that question.
And the couterpoint is obviously that a truly dedicated hardhead baddie will just keep starting more and more RfCs and waste more and more of the only precious resource we have, the willingness of volunteers to help out. Polygnotus (talk) 20:29, 20 February 2026 (UTC)[]
50 people won't get messaged, so you can stop worrying about that. FRS never notifies more than 15, and rarely does even 10.
The problem of the occasional "truly dedicated hardhead baddie" is addressed in Wikipedia:Requests for comment#Multiple simultaneous RfCs on one page. We created this "rule" (it's not even a rule, but just a factual statement of what's statistically normal) years ago because of two editors, neither of whom are with us any longer, and it's been gently pointed out to a couple of editors since then, all of whom have immediately adjusted their behavior to conform. While the scenario you describe isn't impossible, based on existing experience, it is extremely unlikely, and even if it did happen, experience shows that we already have the tools we need to address it. WhatamIdoing (talk) 20:40, 20 February 2026 (UTC)[]
Well I have certainly wished for a way to stop someone with a Mohs 9-10 head from starting RfCs and there wasn't one (other than going to ANI, but their behaviour wasn't bad enough for that). They would laugh at a mere link to an information page; you'd need God himself to have a chance to convince them.
I'll read the Yapperbot code, thanks. Polygnotus (talk) 21:04, 20 February 2026 (UTC)[]
If they have more than one RFC open at a time, then put the links on this page, and let someone else have a chat with them. WhatamIdoing (talk) 21:08, 20 February 2026 (UTC)[]
In that case it was more a series of time-wasting RfCs IIRC. A huge timesink. Polygnotus (talk) 21:10, 20 February 2026 (UTC)[]
I suggest we stay away from:

Should one person just be allowed to change the rules for everyone without consensus?

Let’s assume good faith on those doing the hard work of trying to document the understanding of consensus and if the documentation has shifted from consensus, we, as a community, should take ownership for not having more discussion about it. I generally get the sense that the few editors being referred to are just out here doing the hard work and we owe them gratitude for that work. Dw31415 (talk) 16:13, 20 February 2026 (UTC)[]
Agreed, and I have also expressed my gratitude for that work. Especially because it is the kinda stuff I would find horribly boring.
Note also that I disagree with (or can find ways to improve) at least half my edits, so I'll happily admit my shit stinks.
I try to keep the "Main" slice of the XTools piechart as large as possible.
But we shouldn't end up in the situation that the rules for everyone are decided by less than a handful, and if that happens the way to counteract that is to point out that n=1 is worthless. And I think this topic is important enough to request far wider input (but not yet, still working on that, may take a few days). Polygnotus (talk) 16:31, 20 February 2026 (UTC)[]
One idea: Add (more) delay to when FRS sends it’s notification. On the above topic/RfC, I could have helped the nominator format the question because I follow the page. Instead I learned about the RfC through FRS and found another editor (from FRS) had preemptively closed because of lack of RFCBEFORE. That happened to be inaccurate because of 5 previous discussions on the RfC question. That said, the question had a major RFCNEUTRAL issue which could have easily been fixed. Adding a delay to FRS would give involved editors a chance to tidy up the question before it gets broadcast. Dw31415 (talk) 17:14, 20 February 2026 (UTC)[]
Or even have a special section on RFS where people can sign up who are willing to give feedback on future RfCs so that the bot can give those people a day or 3 to improve the RfC before it goes live. I think there are quite a few people who would be willing to help. Polygnotus (talk) 17:16, 20 February 2026 (UTC)[]
We've said for years that editors starting RFCs are invited to ask for help in writing the question on this talk page, and while we get more such requests than we used to, it's still on the order of 1% of RFCs. Most people who are starting RFCs don't believe that they need help. WhatamIdoing (talk) 20:06, 20 February 2026 (UTC)[]
Most people who are starting RFCs don't believe that they need help. I fully agree. So in this comment the workflow is: RfC created -> smaller group of people makes improvements -> RfC advertised to a larger group of people. This would sidestep the issue that people assume they know it all.
And sure, some people have a very complete understanding of the topic they want to start an RfC about. But many do not. Polygnotus (talk) 20:12, 20 February 2026 (UTC)[]
About an RfC where both sides present their view side by side: This is listed as an option in Wikipedia:Requests for comment/Example formatting#Pro and con. Very few RFCs have ever used that option. RFC questions are usually simpler than that (more "Shall we do this or not?" than "Shall we do this, with these three arguments in favor, or that, with those three arguments in favor?"). WhatamIdoing (talk) 20:05, 20 February 2026 (UTC)[]
Often the person who starts the RfC does not have a complete understanding of the topic (or, if you prefer a bad faith explanation, want to push people in a direction) which means they often do not ask the right question, do not provide the right context and do not offer the right choices.
The worst on that page is clearly "Separate votes from discussion" which sidesteps Wikipedia's consensus forming mechanism in favour of voting. Do you mind if I remove that one?
The second-worst is Separate support and oppose opinions because people will just form an opinion based on the original post and then post in their preferred section without reading the other comments. Do you mind if I remove that one? Polygnotus (talk) 20:27, 20 February 2026 (UTC)[]
Pushing in a particular direction is only a bad-faith behavior if the pushy person believes that direction will harm Wikipedia.
I suggest that you not remove any sections that describe styles that get used regularly and/or in highly publicized RFCs. You give the Zak Smith RFCs as an example below, and Talk:Zak Smith#RfC: Sexual abuse allegations (the second one) uses the "Separate votes from discussion" format. Large RFCs (also WP:RFA) such as Wikipedia:Requests for comment/Deployment of Vector (2022)#Support used the "Separate support and oppose opinions" format.
I think these should be used only for a minority of RFCs, but they should not be hidden or banned. WhatamIdoing (talk) 21:05, 20 February 2026 (UTC)[]
Pushing in a particular direction is only a bad-faith behavior if the pushy person believes that direction will harm Wikipedia. Intentionally (trying to) feed people misinformation in an attempt to influence them is pretty badfaithed in my book.
I can't imagine a scenario in which these formats would be superior to a freeform discussion (and I think that neither of the examples above benefit from these formats, compared to a normal discussion). Polygnotus (talk) 21:13, 20 February 2026 (UTC)[]
Pushing in a particular direction ≠ feeding people misinformation. I push people in the direction of using WP:MEDRS-compliant sources for Wikipedia:Biomedical information. That's "pushing people in a particular direction" but not "feeding people misinformation". Even if the people in question have Pathological demand avoidance and hate feeling "pushed", it's still not a bad-faith action or misinformation. WhatamIdoing (talk) 00:51, 21 February 2026 (UTC)[]
Agreed. But you can probably imagine a hypothetical situation in which an RfC opening statement attempts to misinform potential commenters/voters in order to push them in a particular direction. Polygnotus (talk) 00:58, 21 February 2026 (UTC)[]
In my experience, we have very few deliberate "attempts to misinform". We have many people who are attempting to properly inform – to the best of their understanding and ability, which often turns out to be poor understanding and limited ability. WhatamIdoing (talk) 01:14, 21 February 2026 (UTC)[]
Well, I gotta admit that it is impossible to read the minds of the various weirdos with internet connections (thank God!). But sometimes my spider-sense just tingles, you know? Polygnotus (talk) 01:16, 21 February 2026 (UTC)[]

Unstoppable weapons

[edit]

Here's why RfCs are unstoppable weapons: they attract contributions from a broader range of editors. If you don't bring in people from outside, then you get the local WikiProject making shit decisions. We've found this out the hard way, several times, but for a really clear example, Wikipedia used to have a special notability guideline for porn performers at WP:PORNBIO. It was so ghastly inclusionist that for several years, Deletion Review refused to enforce it, so when porn performers' biographies got deleted at AfD, they stayed deleted regardless of the rules. We finally got rid of it here.

NSPORTS is also crazy inclusionist. From 2010 to 2022, it had a rule that if you'd ever in your life played professional sports for five minutes, you were notable. We binned that in WP:NSPORTS2022. But the 2010 version of the rule only passed because the pre-2010 version was even more crazy inclusionist. These are biographies of living people.

In other words RfCs have become unstoppable weapons because if we don't want self-selected groups dominating our decision-making processes, then we have to bring in people from outside the bubble.

If you don't want RfCs to be unstoppable weapons, then your proposal needs an alternative way to bring in the wider community to stop localconsensus from making shit decisions.—S Marshall T/C 17:42, 20 February 2026 (UTC)[]

I think we should delete a massive amount of BLPs that meet NSPORTS but not GNG. If we do not have enough reliable sources to write a somewhat decent article about that particular human being then why have an article? It doesn't make sense to me.
WP:LOCALCONSENSUS says: Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope.
SmokeyJoe said it best: The SNGs are predictors of whether the topic will pass the GNG. The GNG is a predictor of whether the topic will pass AfD.
Luckily RfCs are not the only way to WP:SEEKINPUT but I agree that it is important that people can solicit external input, and I also agree that this fear is probably the underlying motivation for making RfCs unstoppable weapons of mass destruction.
But we probably shouldn't try to fix one problem by creating an even worse one. Polygnotus (talk) 17:57, 20 February 2026 (UTC)[]
We're not "making" RfCs unstoppable in the present tense. They were made, past tense, unstoppable over the course of years because we learned why they have to be.—S Marshall T/C 18:49, 20 February 2026 (UTC)[]
Nah, the push to make em unstoppable was pretty recent.
And they don't have to be. Polygnotus (talk) 18:51, 20 February 2026 (UTC)[]
I join issue with you on both of those claims.—S Marshall T/C 22:39, 20 February 2026 (UTC)[]
@S Marshall I actually have a tool that gets all revisions of the page, removes unnecessary fluff, filters out minor edits, diffs the revisions, figures out how many edits it can combine to stay under a preset token limit and then calls Claude to determine which were the most impactful changes.
It is pretty interesting to see how policy pages evolve over time. I may have to make a Wiki github. Polygnotus (talk) 22:50, 20 February 2026 (UTC)[]
Policy documents practice. By the time I was aware of policy pages, around 2009-ish, if you wanted to make a decision of any importance that was going to last and that wasn't shit, you held a RfC. And once you'd held a RfC, that decision was crystallised for a while and much harder for POV pushers to get rid of. In fact at that time RfC was broader in scope than it is now, because we could use it to discuss users as well as content decisions. RfC got cut back to broadly its current size when we deprecated RFC/U in 2014. The edits WAID made, which you seem to find so deeply objectionable, are actually just writing up how things work. You can certainly have a RfC about the RfC process if you want, and I'm starting to think that's easiest, because the community will set you straight.—S Marshall T/C 23:41, 20 February 2026 (UTC)[]
actually just writing up how things work Au contraire, mon frère. Knowing the Wikipedia community it seems rather unlikely that they are fine with these changes being made without being consulted. Even if they think they are a good idea then they still want to be able to voice their opinions.
Policy documents practice. In theory. No theory survives contact with reality. Just ask LTCM. Polygnotus (talk) 00:19, 21 February 2026 (UTC)[]
Ok, I genuinely tried to explain to you. These things you say are "changes" and you think the community would object to---you should go ahead and draw their attention to it. The community will set you straight.—S Marshall T/C 00:35, 21 February 2026 (UTC)[]
Thanks! Polygnotus (talk) 00:38, 21 February 2026 (UTC)[]
The "change" is that there was never a written rule allowing Poly to unilaterally shut down someone else's RFC over a perceived (but not actual) violation of RFCBEFORE (example), so they changed this page six minutes later to justify their action, and I eventually reverted their undiscussed change. If we're going to talk about "Should one person just be allowed to change the rules for everyone without consensus?", then I think that would make a reasonable example of someone changing the rules for everyone without consensus. WhatamIdoing (talk) 01:10, 21 February 2026 (UTC)[]
We already discussed that. And I explained how I could do the exact same if I wanted to, because it is easy to do such things. But is also counterproductive and not a nice thing to do. So its best if we don't. Polygnotus (talk) 01:15, 21 February 2026 (UTC)[]
About If we do not have enough reliable sources to write a somewhat decent article about that particular human being then why have an article?: What is the definition of "a somewhat decent article"? I believe that for the reader who wants to know what sport Alice Athlete played, then a single sentence saying something like "Alice Athlete was a long-distance runner in the 1976 Olympics" constitutes "a somewhat decent article". I believe that for the reader who wants to know a lot of information about Alice Athlete, this is not "a somewhat decent article". The result is that the community has to decide: Should the first reader not get an article that meets their limited needs, just because that limited article would not meet the second reader's more extensive needs? WhatamIdoing (talk) 18:53, 20 February 2026 (UTC)[]
What is the definition of "a somewhat decent article" My personal definition that is valid for only me? Or what the community accepts as a somewhat decent article? I am not sure I can answer either of these questions. Saying "it depends" feels a bit weak.
But it can be a bit worrying to see a BLP for which there is basically no source, except for perhaps a row in some database. For an astronomical object I find that less problematic. Polygnotus (talk) 18:58, 20 February 2026 (UTC)[]
Maybe an example is useful, because we all have a different experience. This is the kind of RfC I come across. Just one example out of many. Polygnotus (talk) 20:42, 20 February 2026 (UTC)[]
I'm not sure that I agree with @S Marshall that RFCs are an unstoppable force. This feels true in a collective sense, but the complaint seems to be about individual RFCs that an individual editor disapproves of.
I've shut down or re-written the question for individual RFCs that aren't helpful or functional, and I'm not the only one who has done that. In fact, I'm not even the most prolific of the RFC regulars to do that. So we have proof that this can be done, because people do that.
Rosbif73 asks above about problematic questions, so I'll give you some examples, and others can chime in with others (numbered to make it easier to disagree with me, of course). For clarity, I'm making a distinction between shutting down and closing: Shutting down happens earlier and is like getting your request rejected. Closing is what can happen if you've gotten useful responses and don't want/need any additional comments.
  1. The test edit. There's no question; there's no nothing. You should wait a bit to make sure that they're not in the middle of drafting the question, but if it's been more than half an hour, then you can assume it was a mistake and revert it.
  2. The l-o-n-g question. This is moderately common. First, the definition of an overly long question is one that looks a lot longer than (all/almost all) the others in Wikipedia:Requests for comment/All. A paragraph or two is okay, but 500 words is not. This RFC usually doesn't need to be shut down. Instead, figure out a short way to ask the question or describe the problem, and add that to the top with a ~~~~~ (date only) timestamp. The original version becomes the first "comment" rather than the RFC question itself.
  3. The formatting problem. The RFC system can't handle certain kinds of templates or formatting (e.g., tables) in the RFC question. Treat this like an overly long question and shorten the 'question' so that the RFC bot isn't trying to transclude the complex formatting.
  4. The nonsense question. We're talking word salad here, not just a question that's open to interpretation. Ordinary people have no idea what, if anything, is being asked, so none (or almost none) have responded. Pull the RFC tag and leave a note at the end of the section that invites the OP to discuss a clearer way to phrase their question here at WT:RFC.
  5. The hopelessly vague question. There's one of these open right now: What do you think of the article, and should we maybe try to improve it somehow? Editors dislike these and avoid answering them. It's not worth shutting down because the drama over shutting it down could exceed the cost of editors looking at the question and silently closing the tab. Sometimes these editors can be redirected to Wikipedia:Peer review. Otherwise, we mostly let these languish. If the OP complains about the lack of response, we can suggest starting over with a specific question.
  6. The lost cause question. This is the one where someone tries to argue that WP:DAILYMAIL is reliable for medical content. Editors generally see straight through this no matter how it's phrased. The most effective response is to leave the question alone and WP:PILEON with a clear rejection. If you want to be kind to the OP, or if there are already a dozen editors joining the fray, then you can point out to the OP that WP:RFCEND allows them to withdraw the question at any time.
    • NB that this kind of question isn't necessarily a waste of editors' time. Sure, there's zero chance of The Daily Mail being declared reliable for medical content. But there are also social benefits to giving editors an opportunity to publicly and collectively affirm their allegiance to the community's values and principles, and there are practical benefits to having some people learn that their POV is shared by a very small minority. Consequently, Wikipedia gets value out of this, even though it's not the face value of answering the nominal question.
  7. The slightly biased question. Maybe the question says 'many sources' but you think 'some' would be more accurate. Maybe it asks you to choose between picture A and B, and you think there should be no picture. The first line of response should be providing a sensible answer, which may include addressing your concern about the question in your response ("The question refers to 'the victim', which implies that he's actually a victim, which is exactly what's in dispute, but we all know what the OP is asking anyway"). Otherwise, this should be ignored because the cost of perfecting the question is higher than the cost of having a slightly imperfect RFC question.
  8. The obviously biased question. This is the one in which there's a legitimate dispute that could be solved by an RFC, and the question is written to support one answer. This is "Shall we include this WP:DUE material that is supported by the WP:BESTSOURCES?" or "Wikipedia is WP:NOTCENSORED, so we should put this contentious material in the lead." In an ideal world, it wouldn't be possible to look at the RFC question and tell what the OP's view is. However, as a practical matter, discovering the OP's view in the 'question' versus discovering the OP's view two centimeters lower on the page in the OP's 'response' does not seem to make much difference. I'm participating in one of these at the moment; last I checked, the discussion is five to one against the editor who cited a WP:GUNREL source in an WP:ARBPIA dispute. My conclusion is that the community is capable of handling this kind of biased question. I decided to participate this time; other times, I might have handled it like an overly long question (especially since that question is also long), or talked to the OP about the advantages of re-writing the question.
    • One thing to look out for here is whether there are voting-style responses that could get screwed up if you change the question. You need to avoid changing "Let's include this important material!" to a "Shall we exclude this?" question, because then the early votes are backwards.
  9. The subtlely biased question. This is the difficult one. This is usually in the 'question' and sometimes in pre-supplied voting options (yes/no, when it should be an open-ended discussion, or 1/2/3 when it should be 0 to 10). My preferred approach to this is discussion of the question in the RFC itself. My preferred approach is probably more effective if it's the first/early response. If these run their course, they may not settle the dispute. A subsequent RFC, with the question crafted based on what we learned from how this one failed, may be able to resolve it. (Of course, some disputes will never really be settled, no matter what we do.)
  10. The background section or the first response. This is officially Not a Problem, as only the RFC question itself (the bit that appears on Wikipedia:Requests for comment/All) "should" be brief and neutral (NB "should", not "must"), and responses are actually meant to not be neutral. That said, it generates some complaints, usually from people whose POV is not the most popular one ("How dare he explain why his view is correct before I could explain why my view is correct?!").
    • The reality behind this, which is that WP:TLDR is one of the iron laws of the internet, so people will read a few things but not everything in a long discussion, is why I think that when subsections are wanted, the ===Discussion=== section should precede the ===Survey=== one.
  11. The redundant question. Didn't we just do this last month? Sometimes these should just be shut down, especially if you think that the OP didn't know about the previous one. Give the OP a link to the prior one and pull the rfc tag. But if last month's result was weak, has been overtaken by events, or otherwise might not represent the current consensus, it's best to link to the prior discussion(s) and let this run again. If the problem is, as Andy describes above, that the RFCs aren't solving the underlying issue, then it can be helpful to facilitate a discussion with a goal of pointing people towards that underlying problem ("That's a good point, and how do you think it relates to the broader question of...?"). This category also overlaps with the lost cause: Yes, the community said 'no' last month, but WP:I didn't hear that and I need to be told again. If the result of the prior RFC is still valid, then reminding participants about the prior RFC will usually result in people voting the same way as the prior RFC, except louder (all the people who voted X last time, plus all the people who are voting X now just because they think the result of the prior RFC should be respected).
I also add some myths that are sometimes given by people who disapprove of a particular RFC question:
  • There was no prior discussion on this subject.
  • There was no prior discussion of the wording of the RFC question.
  • There was no prior discussion of whether to have an RFC.
What else would we add? WhatamIdoing (talk) 00:22, 21 February 2026 (UTC)[]
The wrong question. e.g. the dispute is not about W vs X but about underlying factors Y vs Z. Polygnotus (talk) 00:26, 21 February 2026 (UTC)[]
we should avoid providing pre-set answers That would be a great addition to the information page. Please add it. Polygnotus (talk) 01:23, 21 February 2026 (UTC)[]
I like preset answer options where appropriate. As in the Flight 5342 question, there’s three options raised in previous discussion. (American Airlines, American Eagle, PSA Airlines). What’s the problem with predefined options? Dw31415 (talk) 02:25, 21 February 2026 (UTC)[]
Two common problems:
  • When they're not necessary, they encourage and normalize voting behavior. As an example of "not necessary", if the RFC question is a simple yes/no question, you don't need to tell editors that the options are Yes and No.
  • When they're badly written, they can bias the discussion. As an example, if the RFC question should offer "0 to 10", and the preset answer options are "1 to 3", then it implies that neither "0" nor "4 to 10" are appropriate responses.
However, there are also benefits. Sometimes the preset options are the only way to figure out what the OP is actually asking. Sometimes the way the question is worded, you end up with "Yes, omit" or "No, support", and if people make up their own summaries, we end up with confusion. WhatamIdoing (talk) 04:33, 21 February 2026 (UTC)[]
Also the Anchoring effect, False dilemma/false exhaustiveness, framing, the Compromise effect and all that good stuff.
I have a book around here somewhere that lists like 10 more. Polygnotus (talk) 05:10, 21 February 2026 (UTC)[]
Another: The wrong process. Some are explicitly discouraged; like where the RfC statement basically asks "Should the article be deleted/merged/split/renamed". Others are not explicitly forbidden, but blatantly obvious; like this one. --Redrose64 🌹 (talk) 12:34, 21 February 2026 (UTC)[]
+1 for discussing that category. I just added a Template:Side box to the example you gave. I’d generally favor a template like this for a “softer, kinder, gentler” shut down of a “BadRfC”. Maybe a new template could include the RfC id so it renders the anchor tag and doesn’t break all the FRS links. I’m holding off proposing template solutions to see if @Polygnotus is going to test consensus of the RfC shutdown (and I like the term shut down for the preemptive close, especially because shutdown can refer to removing the RfC tag more than adding Template:Closed rfc top). Dw31415 (talk) 09:53, 22 February 2026 (UTC)[]
@Dw31415 and WhatamIdoing: Well I think the problems are broader than just the inability to shut down and change an RfC.
We want people to be able to attract the attention of uninvolved people. I think we all agree on that.
But from there, thing diverge.
We now have a few very oldskool ways that evolved over time and use terrible workarounds for Wikipedia's limitations.
But when you think about it, why do we do it this way? Is the way things evolved ideal? Then why do men have nipples, and not heated cupholders?
What are the differences between the various ways to WP:SEEKINPUT?
What if we had an editfilter that tagged an edit "RfC started" or "RfC closed"?
What if we had a bit of JS that follows the EventStream like ExternalLinkMonitor and tells people (who opted in) "yo there is a new RfC".
Why are we promoting using RfCs instead of telling people something like: "In most cases you can just use 3O. If that doesn't work, and you did RFCBEFORE and it still doesn't work, then maybe start an RfC"? Why use an unstoppable superweapon to kill a mosquito (Confucius 551-478 BCE)?
If we look at what the RfC starter wants, sometimes a broad consensus is indeed required (policy changes, whatever) but often just 1 or 2 people who show up quickly and agree with them is fine. And RfC starters don't even read this entire page full of instructions.
So why don't we flip it on its head, make a system where you can quickly attract 1 or 2 people to a potential problem, and then if you need more maybe you can start an RfC. Maybe. Polygnotus (talk) 10:41, 22 February 2026 (UTC)[]
Interesting. So maybe like a two-step process. Or an escalating one. Or maybe like in Bob’s rules where an RfC (a motion) requires a second before proceeding to debate.
Overall I’m willing to accept that the current system is the worst except for all the others that have been tried, but I have a lot of fun thinking about different governance ideas. Dw31415 (talk) 11:04, 22 February 2026 (UTC)[]
Another thing is that currently the RfC starter has to provide a topic area which could be replaced by a bit of code (and you can make it as granular as you want).
E.g. you start an RfC on a page about a writer, it shouldn't be too hard to automatically classify that as something that WikiProject Literature may care about.
For example see Category:Pages within the scope of WikiProject Astronomical objects (WP Astronomy Banner). Polygnotus (talk) 11:11, 22 February 2026 (UTC)[]
The difficulty with requiring a Second (parliamentary procedure) is that RFCs also function as signal flares for problems that we need to hear about. Imagine being stuck in an intractable dispute with two other people on a low-traffic page. None of your edits stick, and all of theirs do. There are three of you, so Third opinion won't work. Both refuse to 'second' your RFC. Everyone's being polite, so ANI won't help. Now what?
Well, you could go ask a friend, assuming you have any. You could go ask a WikiProject, assuming you know about them and assuming they'll respond (unfortunately unlikely). You could go to a noticeboard, which works best if you have a single point of disagreement. You could go to Wikipedia:Dispute resolution noticeboard, but they can refuse. The answer is: Let people start RFCs when they think they need them. WhatamIdoing (talk) 02:47, 23 February 2026 (UTC)[]
There are three of you, so Third opinion won't work.
So why must it be:
  • 1 person (who presumably agrees with themselves, unlike me)
  • 2 persons -> 3O
  • 3 persons -> RfC
Instead of Third Opinion why not have a similar "We'd like some more input please" option that is not limited to 3? I don't believe that the solution is not to make 3O basically unused and to tell everyone to start RfCs all the time for every minor thing. If the message is just "I'd like some more input please" then why have 2 options at all? And if we do have two ways of getting extra attention, why are they so functionally similar? Polygnotus (talk) 03:01, 23 February 2026 (UTC)[]
People may leave a neutrally-worded notice at the talk page of a WikiProject, directing them to the discussion (not necessarily an RfC). Templates such as {{fyi}} and {{subst:WikiProject please see}} are available for this. --Redrose64 🌹 (talk) 07:05, 23 February 2026 (UTC)[]
Problem is, most WikiProjects are dead. Polygnotus (talk) 07:06, 23 February 2026 (UTC)[]
People don't start RFCs all the time, much less for every minor thing. The median number of RFCs started by experienced editors is zero per lifetime. WhatamIdoing (talk) 07:10, 23 February 2026 (UTC)[]
Maybe some numbers would help. These days, people post about 9,000 comments on talk pages per day. They're starting about three (3) RFCs per day this month. If people were starting RFCs "all the time" or "for every minor thing", we'd get a lot more than one RFC per 3,000 (three thousand!) talk page comments. WhatamIdoing (talk) 07:18, 23 February 2026 (UTC)[]
@WhatamIdoing
Sure, but if you look at RfCs, do you always think "oh this is a good use of an RfC" or do you often think "hmm, I wonder why this person chose to use an RfC when that was unnecessary"?
I want RfCs to be useful for things like policy changes, that actually require a decently attended discussion.
Anyway I am answering you over here and that is actually a more interesting topic. Polygnotus (talk) 07:21, 23 February 2026 (UTC)[]
When I look at RFCs, I am more concerned with whether the discussion is likely to lead to a durable consensus than whether it feels "necessary" to me. RFCs do not have to be carefully rationed. It doesn't matter if we have 22 RFCs open this week vs 23 or even 25. WhatamIdoing (talk) 01:55, 24 February 2026 (UTC)[]
But the fact that RfCs lead to what you describe as a "durable consensus" is actually one of the major problems with RfCs.
Lets say X starts an RfC saying "Should political party Y be described as radical left, left, center, right, radical right".
See how they sneakily turned what should've been a discussion about reliable sources into a discussion about the personal feelings of the participants in the RfC? There are at least 2 such RfCs going on right now.
And then of course people who don't notice such things will voice their opinions.
And then person Z comes along and they have the perfect descriptor and 3 high quality academic sources to back that descriptor up.
But the second Z edits the article he will be reverted, because a headcount of uninformed opinions is more "durable" than high quality scholarly work.
Wikipedia is one of the very few places in which a tiny group (usually 1, sometimes 2 or 3) of good Wikipedians armed with reliable sources and common sense can defend against a horde of POV pushers.
Making RfCs unstoppable weapons that get used all the time makes life impossible for anyone defending against a flood of CPUSHers. Wikipedians are herd animals, and if the defender is offline for 2 weeks here are 3 new consensuses they will just have to accept (because restarting a new RfC after its been closed is bad form, and so is starting one about the same topic as a recently closed one).
What you call a "durable consensus" is antithetical to the "wiki" philosophy in which nothing is static and people are allowed to fix problems. What we need is iteration and improvement, not problems that cannot be fixed because some person managed to find or create Wikipedia accounts that agree with them. !Voting is the enemy, except in incredibly rare circumstances, otherwise those with the most sock- and meatpuppets will "win". Polygnotus (talk) 05:48, 24 February 2026 (UTC)[]
This comes back to the idea that RfC’s are really bad but better than all the governance methods available to a project like this. Are you closer to proposing any specific change? I think the change most worth discussing is some kind of draft stage before FRS does its magic. If you feel strongly that experienced editors should be able to shut down an RfC than I suggest you test that first. Any ideas on where we go from here? Dw31415 (talk) 13:50, 24 February 2026 (UTC)[]
@Dw31415 Well I would like to hear from @WhatamIdoing:. I am specifically interested in whatever common ground we may have.
In my view the status quo ante is that good-faith people are allowed to close bad RfCs, that good-faith people are allowed to edit RfC questions, that people can not unilaterally change the rules and that people should follow RFCBEFORE. So what we should do is edit the information page to make it reflect reality and then if people want to change how things work they can start a discussion here or elsewhere.
Using the appropriate tool for the job is easy: you start small and scale up when it doesn't work.
It would be interesting to have a wide(r) discussion about the direction the alleged community would like to go in, and if needed then something like an RfC to nail down the details and make it official. Polygnotus (talk) 14:22, 24 February 2026 (UTC)[]
This 2010 conversion Wikipedia talk:Requests for comment/Biographies of living people/Archive 1#Compromising on WP:BEFORE? is the only one I could find on mandatory prerequisites. I’d be interested to read others. Dw31415 (talk) 16:06, 24 February 2026 (UTC)[]
@Dw31415 I learned from WAID that 'should' as in people should follow RFCBEFORE should must be interpreted as described in RFC 2119.
But when I use the word 'should' its basically guesswork what I mean.
So according to 2119 it means:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
So under that definition the fact that people should follow RFCBEFORE does not mean that people, you know, should follow RFCBEFORE. Polygnotus (talk) 16:24, 24 February 2026 (UTC)[]
When we say people should follow RFCBEFORE, I'm not sure that we are talking about the same thing.
When I say people should follow RFCBEFORE, I mean something like "You should follow RFCBEFORE, which says not to use RFCs to propose a WP:MERGE".
When you say people should follow RFCBEFORE, I have the impression that you mean something like "You shouldn't start an RFC at all unless it's utterly unavoidable or mandated by another policy like WP:PROPOSAL, because posting a comment on the talk page is almost always going to be good enough, and if it isn't, then it would be better for you to try any form of Wikipedia:Dispute resolution except an RFC, because we need to minimize RFCs as much as possible". WhatamIdoing (talk) 18:31, 24 February 2026 (UTC)[]
I think that most of what you've said is wrong, and based on unreasonable opinions.
  • a "durable consensus" is actually one of the major problems with RfCs – The alternatives are unresolved disputes (the antithesis of WP:Dispute resolution, and so failing at the whole purpose of RFCs).  NB that "durable consensus" does not mean "permanent decision that can never change".  It means something much closer to "at least they'll stop edit-warring over this for a while".  
  • an RfC saying "Should political party Y be described as radical left, left, center, right, radical right". See how they sneakily turned what should've been a discussion about reliable sources into a discussion about the personal feelings of the participants in the RfC? – Nope.  This RFC is not asking for personal feelings.  The bit about "In the context of all our policies, especially verifiability and neutrality, instead of your personal feelings" is unstated because it's so obvious.  
  • Making RfCs unstoppable weapons that get used all the time – They aren't unstoppable, they aren't weapons, and they don't get used all the time. As an example of an unreasonable, logic-defying opinion, consider this claim that they get used all the time, right after you've been told that as a strictly factual matter, only 0.03% of comments start an RFC, and 99.97% don't.
  • makes life impossible for anyone defending against a flood of CPUSHers – RFCs are a favorite tool of those defenders, so it's not reasonable to say that they make life impossible for them.
  • restarting a new RfC after its been closed is bad form, and so is starting one about the same topic as a recently closed one – Sometimes, but not always, and the regulars on this page support repeats when the previous result does not seem to have reached a durable consensus.
  • !Voting is the enemy – I agree.  Fortunately, RFCs are not votes.
WhatamIdoing (talk) 18:26, 24 February 2026 (UTC)[]
Fortunately, RFCs are not votes. Agreed, but the problem is that people act as if they are. Polygnotus (talk) 02:03, 25 February 2026 (UTC)[]
I mean, RFCs usually have to be closed (and an RFC that lacked a formal closure doesn't have much force behind it.) If someone started that political-party RFC you mentioned, most people didn't cite any sources or policy-based arguments, and one person dropped a huge wall of high-quality sources that unambiguously supported one position, any reasonable closer would give more weight to the position with all the sources backing it up. But the flipside of your objections is that sources themselves aren't magically self-enforcing or self-evaluating; it's rare for RFCs to be that lopsided. More commonly we have people with competing lists of sources of differing degrees of quality or comprehensiveness or which word things in various different ways, and while it's great to talk over these things and dig for more sources, we do eventually have to put our pens down at least temporarily, because the article does have to say something (and even declining to say something about the topic is its own decision.) RFCs are necessary as a way to allow us to reach that point; and as someone who has edited a lot in lots of controversial topic areas I'd say they usually serve that purpose. They don't always reach the outcome I want specifically, but it is very, very rare for an RFC to reach an outcome that I'd consider totally and completely unsupportable, so to speak. Like, you talk about how Wikipedia is a place where a tiny group (usually 1, sometimes 2 or 3) of good Wikipedians armed with reliable sources and common sense can defend against a horde of POV pushers - but in my experience the way they do that, at least on more obscure articles that are facing a flood of new inexperienced users, is usually to fire off an RFC like the Bat-Signal, which usually attracts more experienced outside opinions and an even more experienced closer who can assess all their sources and common sense and policy-based arguments and reach a conclusion that is, if not always perfect, at least reasonable. --Aquillion (talk) 06:45, 3 March 2026 (UTC)[]
This is mostly wrong: RFCs usually have to be closed (and an RFC that lacked a formal closure doesn't have much force behind it.)
A recent spot-check showed that two-thirds of RFCs got closing summaries. I'd say that roughly one-third needed a summary because the result was not obvious, another third got a summary (despite the result being obvious) because it was a CTOP or other drama-prone situation, and the remaining third needed no summary, received none, and didn't seem to have any problems as a result. (If everyone cheerfully agrees to ____, then you don't really need someone to officially summarize it; folks just implement it and go their merry way.) If you mostly work in drama-prone areas, then you probably don't see the ones in that last category, but it does exist. WhatamIdoing (talk) 06:06, 4 March 2026 (UTC)[]
@Dw31415 We now have an editfilter and an RfC tag. See User:Polygnotus/Scripts/RfCs.js. Polygnotus (talk) 00:33, 5 March 2026 (UTC)[]
That’s interesting. I’ll take a look. Dw31415 (talk) 03:11, 5 March 2026 (UTC)[]
@Dw31415 Newer version at User:Polygnotus/Scripts/RfCMonitor.js. Polygnotus (talk) 03:13, 5 March 2026 (UTC)[]
You can also see the tags in RecentChanges now. WhatamIdoing (talk) 03:30, 5 March 2026 (UTC)[]
@WhatamIdoing I assume the intended link target was something like this, where you can see me polluting logs by being an idiot Polygnotus (talk) 04:19, 5 March 2026 (UTC)[]

RFC with no categories

[edit]

I think I know the answer to this question, but would like another opinion. An editor started an RFC, and did not include any categories in the {{RFC}} template. An error message shows up on the talk page along with the RFC. The RFC does have an RFC ID. If another editor adds categories to the template, will the bot notice that the RFC has been categorized, and add the RFC to the lists for those categories? Robert McClenon (talk) 20:47, 16 March 2026 (UTC)[]

I think Redrose told me it would. I’d add it (I have in the past). That doesn’t necessarily mean that FRS will notify the category though. Dw31415 (talk) 21:53, 16 March 2026 (UTC)[]
(edit conflict) Yes, add one or more category parameters, and Legobot will add it to the relevant lists next time it runs (it's often forgotten that once an hour Legobot looks at every page with a transclusion of {{rfc}}, if only to check the expiry). But the RfC will remain in Wikipedia:Requests for comment/Unsorted unless the |rfcid= is removed. --Redrose64 🌹 (talk) 21:58, 16 March 2026 (UTC)[]

Please close

[edit]

Why is Absolutiva inserting themself into a twenty-year old featured article without discussion? I found no several discussions above, only edit summaries and an RfC. I believe the talk page is the correct place to discuss disagreements. Can this RfC please be closed? Thank you. -SusanLesch (talk) 14:26, 18 March 2026 (UTC)[]

The tag has been removed. WhatamIdoing (talk) 16:06, 18 March 2026 (UTC)[]
Thank you. -SusanLesch (talk) 23:13, 18 March 2026 (UTC)[]

Question about Question about RFC

[edit]

I have received a note on my user talk page saying: I'm thinking of requesting an RfC, but it'd need to be based on Wiki policies, not simply the number of votes. I interpret that as meaning that the poster wants to request in advance that the closer pay little or no attention to the number of votes. I think that the poster is concerned that a majority of responders may make arguments that are not based on policies and guidelines. I am not sure that I understand the rest of the post. But my question is what should I reply to this poster? Are they making a reasonable request that I can help them with? Robert McClenon (talk) 19:27, 20 March 2026 (UTC)[]

I read the question on your talk page: User talk:Robert McClenon#c-Israell-20260320105500-RfC question.... I’d suggest they review RFCBEFORE and post a regular discussion topic first (or provide a link to one of it exists). Dw31415 (talk) 20:06, 20 March 2026 (UTC)[]
A little more digging seems to indicate that it’s the editor’s proposal is to include “songwriter” in the info box for Rihanna: Talk:Rihanna#c-Israell-20251125145800-Songwriter (in the infobox). Seems like an RfC is appropriate to me. This page is the appropriate forum to discuss potential RfC’s so maybe just tag them here. My take is that info box contents are one of the most super-majority-dependent areas of editing. So the editor should open the RfC knowing that it might not go their way, but it’s a good way to get editors less invested about this artist to comment. Dw31415 (talk) 20:17, 20 March 2026 (UTC)[]
Hi @Isreall, Robert inquired here about your question to him. Please see my answer above. If your question was about the linked discussion, I recommend you draft an RfC in the existing discussion and give existing editors a chance to review it. Also decide which RfC category you might select. Robert, my apologies if I’ve overstepped. Dw31415 (talk) 12:47, 21 March 2026 (UTC)[]
Correcting ping: @Israell Dw31415 (talk) 16:36, 22 March 2026 (UTC)[]
Thank you for your assistance. I've now asked Robert to initiate the RfC. It ought to be noted that such an RfC should not solely be a majority vote... It must also consider the points made and the multiple sources provided. Israell (talk) 16:43, 22 March 2026 (UTC)[]
That is true of any RfC. AndyTheGrump (talk) 16:59, 22 March 2026 (UTC)[]
Why would Robert start one? From reading the discussion it seemed like you should start it if you want the change. Dw31415 (talk) 17:45, 22 March 2026 (UTC)[]
Robert did offer, and frankly I think it might be better if he did, given that he is uninvolved. AndyTheGrump (talk) 17:53, 22 March 2026 (UTC)[]
You might review this close in order to decide if it’s worth opening one. It details how little policy there is to guide infoboxes: Talk:George Formby#RFC: Should there be an infobox? Dw31415 (talk) 19:14, 22 March 2026 (UTC)[]
Thank you, to those of you who tried to help me answer my question, which started because I was trying to help Israell, who had asked me an overly complicated question. I am finished here. I am no longer working on this dispute. I have come to the conclusion that the editor whom I was trying to help will complicate my efforts to help them, by taking bad advice when I was trying to figure out what advice to give them. I don't know who advised them that they should try arbitration. I have known for decades that it is a waste of my time to give advice to someone who is taking turns whose advice they listen to. Robert McClenon (talk) 01:22, 23 March 2026 (UTC)[]

Formatting of my RfC called Navigation for Michael Jackson abuse accuser

[edit]

Hello. I started a discussion on the talk page for FBI files on Michael Jackson about how readers should find information on sexual abuse allegations. Link to discussion: https://en.wikipedia.org/wiki/Talk:FBI_files_on_Michael_Jackson#RfC:_Navigation_structure_for_Michael_Jackson_abuse_accuser I seem to have messed up the formatting - not sure what i did wrong Bhdshoes2 (talk) 13:12, 22 March 2026 (UTC)[]

You need to pick a category (not “content”) from Wikipedia:RFCOPEN Dw31415 (talk) 16:34, 22 March 2026 (UTC)[]

RFCBEFORE wording

[edit]

Following this comment by @Athanelar: would it be a good idea to rename WP:RFCBEFORE to WP:RFCALT (and adjust the section title), to avoid people mistaking it for a mandatory workshopping phase by analogy with WP:BEFORE? Chaotic Enby (talk · contribs) 18:28, 22 March 2026 (UTC)[]

I'd support an additional RFCALT shortcut, but I oppose removing RFCBEFORE. As discussed in Wikipedia talk:Requests for comment#Ways to handle Bad RfC and other previous discussions, there are a lot of cases where the editor either should have done more before discussion, or other editors feel there should have been more "before". Dw31415 (talk) 18:37, 22 March 2026 (UTC)[]
In that case, should it be mentioned somewhere? Because right now, the section WP:RFCBEFORE points to doesn't mention this at all. Chaotic Enby (talk · contribs) 18:46, 22 March 2026 (UTC)[]
Yes, this is the salient point. If people think there should be a mandatory workshopping phase for RfCs, that's a separate rule which needs to be instituted. The current section only says that the 'before' steps are alternatives you could explore instead of using editor time on an RfC. WP:WORKSHOP could be a new requirement, but as it stands the term 'RFCBEFORE' is misleading. Athanelar (talk) 18:52, 22 March 2026 (UTC)[]
In fact, this process was WP:BOLDly suggested here by @The ed17, but reverted by @Giraffedata, and it could be good to hold a broader discussion to know whether there is consensus to recommend this process (or even to make it a requirement). Chaotic Enby (talk · contribs) 18:55, 22 March 2026 (UTC)[]
My suggestion, then, would be that we open an RFC to determine whether there is consensus to make it mandatory for people to workshop before submitting an RfC. If there is, then we write a new section and redirect the RFCBEFORE shortcut there, and move the content currently at RFCBEFORE to a new section provisionally shortcutted RFCALT. If there isn't, then we just do the latter. Either way, the content currently at RFCBEFORE needs to be moved somewhere less misleading. Athanelar (talk) 19:29, 22 March 2026 (UTC)[]
I presume an RfC should leave an option for the status quo, even if it might not be likely to succeed. Chaotic Enby (talk · contribs) 19:37, 22 March 2026 (UTC)[]
Yes, quite right. Athanelar (talk) 19:48, 22 March 2026 (UTC)[]
Glad to see someone thinks the language that Giraffedata called "vacuous" could be beneficial. After an insulting comment like that, I didn't care enough to carry it forward. Ed [talk] [OMT] 20:09, 22 March 2026 (UTC)[]
I like your edit. More generally a favor a mandatory draft RfC phase. Dw31415 (talk) 01:18, 23 March 2026 (UTC)[]
I think there are editors who would benefit from taking Ed's advice. I also think those editors are unlikely to recognize that Ed's advice is relevant to them. (Make sure it's appropriate? Of course my RFC is appropriate!) WhatamIdoing (talk) 03:53, 23 March 2026 (UTC)[]
Doesn’t mention at all? I think this text in the section addresses: If you are considering an RfC to resolve a dispute between editors, you should try first to resolve your issues other ways. Try discussing the matter with any other parties on the related talk page. If you can reach a consensus or have your questions answered through discussion, then there is no need to start an RfC. If a local discussion does not answer your question or resolve the problem.. Dw31415 (talk) 11:59, 23 March 2026 (UTC)[]
The core of the issue is that the section addresses alternatives to RfCs for dispute-resolution, which is different from workshopping a RfC. For instance, when proposing a new policy, a local discussion between a few editors wouldn't be an alternative. Chaotic Enby (talk · contribs) 12:31, 23 March 2026 (UTC)[]
Giving some context here. This is popping up now because, in the last 6 months, there have been two LLM PAG-related RfCs without any pre-RfC workshopping and one RfC with a rushed pre-RfC workshopping phase. Starting an RfC to modify our PAGs without prior community workshopping is concerning for a few reasons, as it may lead to lower quality proposals, increase the burden on the closer (for example if they have to assess consensus for a modification to what was originally proposed, as looks likely here), and (even though I am sure this is not the intention in the examples referenced above) may be a kind of supervote on our PAGs by the RfC creator. NicheSports (talk) 13:46, 23 March 2026 (UTC)[]
@NicheSports, those complaints should be considered violations of WP:PROPOSAL rather than violations of the RFC rules.
My impression (and I glance at more RFCs than most editors) is that RFCBEFORE complaints largely fall into two categories: "I don't want to have an RFC about this at all" (e.g., because this seems too unimportant to me; because this could be resolved another way; because I don't want outside scrutiny of this page) and "I'm going to lose, so I'm looking for a technicality to get this shut down". WhatamIdoing (talk) 19:38, 23 March 2026 (UTC)[]
Tbh I tend to think shutdowns along the lines of "we’ve discussed this to death" are genuine, disputes are exhausting esp. if repeating the same one again and again, but I guess you could add "… and my side won" to that Kowal2701 (talk, contribs) 19:53, 23 March 2026 (UTC)[]
Yes, I agree that when prior discussions (RFCs or otherwise) have reached a conclusion, then repeated RFCs are not usually helpful. However, because Wikipedia is written by humans, it shouldn't be the "winners" of the previous ones who do the shutting down. The winners should cheerfully dogpile into the RFC with links to prior discussions, or alternatively ask for a completely WP:UNINVOLVED person to shut it down. WhatamIdoing (talk) 20:14, 23 March 2026 (UTC)[]
Maybe we could explicitly say that regardless of context, RfCs can only be closed by those uninvolved in the dispute, and point involved editors to WP:AN and WP:CR? Technically this is an information page tho Kowal2701 (talk, contribs) 20:17, 23 March 2026 (UTC)[]
We explicitly say that the OP can end their RFC at any time, so "RfCs can only be closed by those uninvolved in the dispute" is wrong.
The desired outcome in these complaints doesn't seem to be "closing". Which of these terms seems most like what you're looking for?
  • End: The RFC template has been removed, and the bot removed it from central listings like Wikipedia:Requests for comment/All.
  • Close: The discussion has been boxed up with a template such as Template:Discussion top to discourage further comments.
  • Summarize: Someone has posted a comment summarizing the result of the discussion.
WhatamIdoing (talk) 21:21, 23 March 2026 (UTC)[]
I was under the impression people just want them closed with a Procedural close or similar summary. Maybe "Other than by being withdrawn, …" or similar? Kowal2701 (talk, contribs) 21:32, 23 March 2026 (UTC)[]
When we shut down RFCs (e.g., because they're hopelessly malformed), we usually just remove the RFC tag and leave a comment explaining what we've done and why. These can be reverted (but that almost never happens, at least when I pull the tag), and the usual goal is to get it re-opened in a functional form. By comparison, "procedural close" sounds more official or formal, like you would have to get permission to re-open it.
What do you think would happen next? The steps so far are:
  • There's a dispute.
  • Someone starts an RFC to resolve it.
  • Someone else unilaterally boxes it up and drops a Procedural close or similar summary at the top.
  • Now what?
WhatamIdoing (talk) 22:45, 23 March 2026 (UTC)[]
The OP gets WP:DROPTHESTICK cited at them and stonewalled (rightly or wrongly). The convention seems to be that an RfC less than 6 months after the previous exact-same one gets closed, maybe we could add that? (as in that's the only appropriate context to shut down an RfC besides removing the tag to workshop some more or do more local discussion) Kowal2701 (talk, contribs) 22:53, 23 March 2026 (UTC)[]
This might have some unforeseen edge cases, as it means someone could close an RfC citing on a lack of workshopping, and, once workshopped, close it again citing this rule. Chaotic Enby (talk · contribs) 23:15, 23 March 2026 (UTC)[]
The convention is 6 months, with editors allowed to ignore this. Past discussions have shown minority support for 12 months.
Repeated RFCs are not a very common problem. Unless you have a few recent examples at hand, I'd consider this WP:CREEP.
If the rule is written as "the previous exact-same one", then people will slightly re-phrase and be free to have another go, which does not solve the perceived problem. If it's defined more broadly, then legitimate repeats (e.g., new sources provide significant new information) will be stopped by editors in the loyal opposition.
You'd have to write the rule as "reaching a consensus" to prevent some edge cases (e.g., 'procedural' close followed by 'duplicate RFC' close; or no consensus, so now dispute resolution is prohibited from making any progress for the next six months).
But mostly I go back to the question of whether this is actually a problem. One expects a certain amount of this (e.g., in geopolitical disputes), but some of those need ArbCom to impose a moratorium, and a general rule just doesn't seem to be needed. WhatamIdoing (talk) 23:42, 23 March 2026 (UTC)[]
I'll try to do a mock up maybe tomorrow of an RFCBEFORE section for you to pick apart :) Kowal2701 (talk, contribs) 23:47, 23 March 2026 (UTC)[]
Kowal, do you think that telling the OP to drop the stick and stonewalling is going to resolve the dispute? WhatamIdoing (talk) 23:33, 23 March 2026 (UTC)[]
In a WP:OAM situation, there's no real way to resolve disputes, people just accept they 'lost' or get sanctioned for being disruptive. RfCs are meant to stop a small partisan clique from controlling the article by getting input from the wider community, and I think we need to put trust in that. The vast majority of the time it works really well (imo making an RfC when met with an uncompromising POV pusher is always better than having lengthy disputes, both for the article and editor). In cases where the community is generally partisan on an issue, there's really nothing we can do about that, it's just systemic bias, which needs more meta solutions re blocking, like bringing diversity of POVs in a topic area into consideration etc. Kowal2701 (talk, contribs) 23:44, 23 March 2026 (UTC)[]
I assume you meant User:Guy Macon/One against many instead of Wikipedia:Online Ambassadors/Mentors.
I agree that one of the things RFCs are meant to do is to stop a small partisan clique from controlling the article by getting input from the wider community. How does authorizing the partisan clique to shut down RFCs, or to limit the number of times per year that the wider community can be invited to provide input, help meet that goal?
What if the OP is not a lone POV pusher? What if the problem is "several against many", or "more or less half the community on each side"? Consider Talk:Pregnancy/Archive 4#Lead image RfC and related discussions; there were multiple RFCs, more or less back-to-back, plus many other discussions before that finally got settled. WhatamIdoing (talk) 00:23, 24 March 2026 (UTC)[]
Partisan cliques can only shut an RfC down if there was a recent RfC where the community affirmed their position (or if the RfC were malformed), so if they are truly partisan, then that's systemic bias in the community (or there was some dark arts, in which case ANI reports etc.). Limiting the number of RfCs is a trade-off between WP:CCC and WP:EDITORTIME (both the community's and local editors'). Tbh, worst case scenario, I don't think a slanted article for 6 months is that big of a deal, and the eventual comeuppance reflects awfully on those who caused the slant. One issue is that the shutdown of attempts can be treated as resetting the clock (which can be addressed in a RFCBEFORE). We need some guidance on moratoriums, they should really be done at WP:AN instead of locally Kowal2701 (talk, contribs) 10:02, 25 March 2026 (UTC)[]
It's not a good experience in terms of social rules for your opponents to declare that you aren't allowed to talk to the wider community. Under some circumstances, this amounts to authorizing the playground bullies to prevent their victim from seeking help. They are always the wrong people to do that. WhatamIdoing (talk) 16:41, 25 March 2026 (UTC)[]
The alternative is constant RfCs until one 'side' gets burnt out or bored, no? It’s endurance rather then strength of argument Kowal2701 (talk, contribs) 16:47, 25 March 2026 (UTC)[]
I think the alternative is having an WP:UNINVOLVED person shut down pointless RFCs. And, as the Pregnancy case indicates, sometimes you need two or three RFCs in a row. WhatamIdoing (talk) 17:11, 25 March 2026 (UTC)[]
Agreed. How does User talk:Kowal2701/sandbox#RFCBEFORE look? Kowal2701 (talk, contribs) 17:47, 25 March 2026 (UTC)[]
Tbh, worst case scenario, I don't think a slanted article for 6 months is that big of a deal. For articles, yes, but a 6 month delay can be problematic for wider project-scale issues, and make it so that Wikipedia can't change at the right timescale to address quickly developing threats. Chaotic Enby (talk · contribs) 15:47, 25 March 2026 (UTC)[]
see [2] for instance Kowal2701 (talk, contribs) 23:50, 23 March 2026 (UTC)[]
If the OP can end their RfC at any time then they can close it when 51% is reached. A terrible system of course. Polygnotus (talk) 22:28, 23 March 2026 (UTC)[]
There's nothing terrible about it at all, especially since this isn't the German-language Wikipedia, so 51% means nothing. WhatamIdoing (talk) 22:40, 23 March 2026 (UTC)[]
If there is nothing terrible about the current system, why do people keep trying to fix it? To me it seems that the one thing almost everyone agrees on is that the current RfC system is pretty bad. Even if they strongly disagree on ways to improve it. Polygnotus (talk) 22:43, 23 March 2026 (UTC)[]
I don't think people keep trying to fix that. I think everyone wants the OP to be able to withdraw their question, especially if it looks like it will fail to gain consensus.
To me, it seems that you are the only person who thinks the current system is pretty bad, and that your main complaint is that you can't get official permission to unilaterally close RFCs when you strongly oppose the proposal in the RFC. WhatamIdoing (talk) 22:48, 23 March 2026 (UTC)[]
It is generally considered bad form to strictly rely on ad hominems. It would be cool if you could make an effort to not do that. If I am wrong and my argument is so terrible, you surely don't need such tactics, right?
And the one time there was a discussion about this your view was in the minority. Polygnotus (talk) 22:54, 23 March 2026 (UTC)[]
This thread has at times been quite productive (such as resurfacing the forgotten scroll) but this exchange has already been hatted below and I think (gentle suggestion Polygnotus) could either happen somewhere else or not at all. Speaking of, @WhatamIdoing, I plan to message you at your talk page (hopefully ok) as I have several questions! NicheSports (talk) 22:59, 23 March 2026 (UTC)[]
Indeed. I keep hoping for a more civilized discussion where we can try to understand eachothers point of view a bit more.
I already gave up once because of the repeated ad hominems, but then the situation got even worse.
Ideally we would go to a status quo ante bellum and then have a civilized discussion. But it is more likely I'll just get bored of the lack of productivity again. Polygnotus (talk) 23:07, 23 March 2026 (UTC)[]
Polygnotus is many things, but partisan they are not Kowal2701 (talk, contribs) 22:55, 23 March 2026 (UTC)[]
I disagree with myself in like 49% of cases. So I am usually pretty easy to convince, if you have good arguments. Polygnotus (talk) 22:57, 23 March 2026 (UTC)[]
Ha! What do you know, it already exists and looks amazing. NicheSports (talk) 19:53, 23 March 2026 (UTC)[]
This looks pretty good. Are edits welcome? This thread is really hard to read now given its size and indentation. Maybe starting a new topic with this as its focus would be helpful (it would to me, many others are lost too)
Are there parts of that sandbox that really should go through RfC first (like the moratorium and invitation to list redundant RfC’s at CR? Dw31415 (talk) 15:29, 26 March 2026 (UTC)[]
I think we can just do normal editing, this is an information page so it's just meant to explain current practices, the prescriptive bits are minor enough imo, but can see if anyone challenges it. I'll make a subsection below and ping everyone later Kowal2701 (talk, contribs) 15:50, 26 March 2026 (UTC)[]
Can I plug this, basically something to put in RFCALT that for complex disputes (ie. not binary), it may be better to solicit input to the discussion from relevant noticeboards (like WP:NPOVN, WikiProjects etc.) and do consensus building with more participants (which RfCs are famously awful for) Kowal2701 (talk, contribs) 20:02, 22 March 2026 (UTC)[]
No, RFCBEFORE is mandatory, and that should stay that way. Polygnotus (talk) 21:50, 22 March 2026 (UTC)[]
You should probably read what WP:RFCBEFORE actually says. It is neither mandatory nor is it anything to do with workshopping an RFC before you launch it. Athanelar (talk) 22:02, 22 March 2026 (UTC)[]
Yeah it was recently changed against the consensus. Polygnotus (talk) 22:06, 22 March 2026 (UTC)[]
As I pointed out above, the page was recently edited to add something about RfC workshopping, but that was reverted an hour later. As far as I know, it doesn't seem to have been there before. Chaotic Enby (talk · contribs) 22:15, 22 March 2026 (UTC)[]
I am happy to explain the situation in more detail on Discord; its a long story. Polygnotus (talk) 22:40, 22 March 2026 (UTC)[]
I spot checked a revision of WP:RFC from February 2025 and RFCBEFORE was largely the same at that time; it still said Editors should try to resolve their issues before starting an RfC. and says nothing about a mandatory workshopping phase. Athanelar (talk) 00:38, 23 March 2026 (UTC)[]
Yeah I have some code somewhere that uses Claude to check how a PaG page evolved over time. The code is far from production-ready tho. Polygnotus (talk) 02:52, 23 March 2026 (UTC)[]
I tried using Copilot to see how the should vs must debate evolved. It seemed to summarize something in 2014-2016 but couldn’t produce links to any history or discussion. Dw31415 (talk) 03:01, 23 March 2026 (UTC)[]
When the RFCBEFORE shortcut was first added eight years ago, the advice was:

Before using the RfC process to get opinions from outside editors, it's often faster and more effective to thoroughly discuss the matter with any other parties on the related talk page. Editors are normally expected to make a reasonable attempt at working out their disputes before seeking help from others. If you are able to come to a consensus or have your questions answered through discussion with other editors, then there is no need to start an RfC.

It's the words "normally expected to make a reasonable attempt" that are (to me) important here. I still see people jumping straight to RfC without any indication that anything else has been attempted. --Redrose64 🌹 (talk) 08:39, 23 March 2026 (UTC)[]
Yeah, at points the page was far more clear than that about requiring some due diligence. But a minority disagreed with that. Polygnotus (talk) 10:00, 23 March 2026 (UTC)[]
There are ultimately cases where RfC is the unavoidable way forward; like when proposing a new policy/guideline, there is nothing else to attempt, gaining community consensus is mandatory.
This is where people usually erroneously quote RFCBEFORE to tell editors that they should workshop their RfC before they run it to make sure that they're clear on what its goals are, what terminology they're going to use, to iron out any loopholes in their proposed wording etc etc; but of course RFCBEFORE has nothing to do with any of that, and that's the crux of the discussion here; whether that specific norm should itself be enshrined into PAG or not. Athanelar (talk) 08:50, 23 March 2026 (UTC)[]
If you use Wikipedia's terrible search system and you look for RfC in which people said "BADRFC" or "BEFORERFC" you'll find that those people are basically always correct.
In a tiny minority of cases I was unsure if they were correct or not. And in the few cases that I disagreed with them no harm was done, it is not like any normal user can forbid another user to start RfCs forever so there was a bit of discussion and then an RfC started, usually a better one. Polygnotus (talk) 22:24, 23 March 2026 (UTC)[]
This ends up being specific to one BRD situation. Ed [talk] [OMT] 15:48, 23 March 2026 (UTC)[]
I don't know why you'd want to give details in a closed forum vs. giving them here, where the discussion is happening? Ed [talk] [OMT] 00:48, 23 March 2026 (UTC)[]
@The ed17 That is actually a more interesting question than you'd think.
Explaining a more complicated topic is a bit like a tree. The annoying thing about an open forum and one to many communication is that you have to explain a lot of branches in far more detail that you could mostly skip in 1 to 1 communication (because you wouldn't bother going in-depth if someone already understands a particular branch or does not ask about it). Leaving messages on talkpages and having to repeatedly hit F5 is also quite annoying (my WikiNotifications software has a userbase of 1). It is also easier to tailor your explanation to someone, give examples you know they are familiar with, things that would resonate with them etc. If I don't know who I am writing for I spend far more time explaining stuff, because people will inevitably shout: "you missed a branch and therefore your argument is invalid", even though the fact that someone didn't bother explaining a branch or two does not invalidate the tree as a whole.
The conventional turn-based "correspondence chess" way to communicate is far more inviting to the 'gotcha'-style of communication while the more immediate and direct communication in a chatbox often makes it easier to actually understand each other, adapt to another's communication style and even to see them as human instead of an enemy to be defeated.
Moderating chatboxes is, in my experience, also easier than moderating forums. Something about the medium just makes toxicity easier (I am no psychologist, and I am not gonna pretend to know the why and I am unable to quantify this; I am just basing this on personal experience).
Note that talkpages were invented a long time ago and not necessarily the best or only solution to the problem of communication between Wikipedians.
I have spent quite a bit of time thinking about this problem, because it is interesting (to me), but I don't have a (perfect) solution yet.
I believe the WMF actually should brainstorm about such things: how to re-imagine MediaWiki if we leave the past behind and make a 2.0?
I hate Discord and it is actively undergoing enshittification at the moment. While I love IRC I am not so nostalgic to not see its flaws.
Ideally this chat-like interface would be hosted on WMF servers and would integrate with existing talkpages, relying on external providers for something so essential would be a tactical mistake. A bit like Stack Exchange chat maybe.
The RfC discussion is pretty damn complicated and I'd have to dig up my old code and spend quite a bit of time to really make a comprehensive overview that would stand up to scrutiny from random people with an internet connection. Giving a single person an idea where I am coming from and why I believe the things I believe is far less time consuming. Polygnotus (talk) 02:39, 23 March 2026 (UTC)[]
(The WMF planned a replacement for discussion pages. It would have been awesome – imagine something purpose-built specifically with enwiki's AFD and ArbCom cases in mind, so it could have done things like tally up Arb votes automatically. Unfortunately, it would not have been backwards compatible, so editors here hated it. It's now neglected and will not be maintained. Anyone with at least US$10 million, five years, and a team of awesome engineers is welcome to fork the code. Prior devs are willing to answer some questions, but they warn that it needs to be re-architected. Instead, you get the mw:Reply tool, the [Subscribe] button, and an invisible database that makes those clever permalinks work. Do not expect any significant changes on this front until at least after the next global strategy. WhatamIdoing (talk) 04:59, 23 March 2026 (UTC))[]
Interesting, thank you. I was thinking more along the lines of something more chat-like. The page you linked to says Users are encouraged to stop using it. Polygnotus (talk) 09:17, 23 March 2026 (UTC)[]
Just give people the links and let them see for themselves. Or don't bother; I'll do it for you:
  • 31 July 2025 at 15:02: A WP:NAC closed an RFC, finding a consensus for including a coat of arms in the infobox and identifying the need for a second discussion to choose which version to include, as editors had discussed different options but not settled on one. Polygnotus had advocated for the opposite result during the RFC.
  • 15:08: The NAC starts a second RFC to determine which image to use, and thus to implement the result Polygnotus disagrees with.
  • 15:33: Polygnotous claims that RFCBEFORE wasn't followed (even though there obviously had been prior discussion, since the new RFC in question was a follow-up on a thread of discussion in the prior RFC).
  • 15:34: Polygnotus removes the RFC tag without discussion or consensus.
  • 15:38: Polygnotous scolds the OP for starting an RFC without following (Poly's personal interpretation of) RFCBEFORE.
  • 15:40: Polygnotous changes the RFC page without a single word of discussion on wiki to retroactively justify the edit at 15:34.
I reverted the undiscussed addition to WP:RFCEND several months later and then added a clarification to RFCBEFORE in the hope that we could prevent this kind of WP:GAMING and self-serving WP:INVOLVED actions in the future.
My main take-away from lengthy discussions on multiple pages about this is that the important difference between these two points:
  • Myth: Nobody at all is allowed to shut down or otherwise "clerk" RFCs. (I shut one down just last week, so clearly it can be done.)
  • Reality: The specific biased and WP:INVOLVED individual human(s) who !voted against the proposal in an RFC should not be shutting down other editors' RFCs themselves (though they're welcome to ask other editors to do so, including on this page).
is something that is extremely obvious to most editors, but not to a small minority of editors.
More generally, if someone wants to start another discussions about whether RFCs need to be discussed in advance, I suggest first collecting a list of all the prior discussions on this subject, reading them, and then explaining why you believe you would get a different answer now. We have fewer total RFCs and more RFC participants than we used to, so "wasting community time" should probably not be your leading answer. WhatamIdoing (talk) 04:48, 23 March 2026 (UTC)[]
Not exactly sure how many times you tried this same trick now, and you still don't get how badly it can backfire if I wasn't too lazy to put in the work.
I get it, you are still pissed off that the consensus was against you. And we both got grumpy.
Was kinda hoping you'd move on.
RFCBEFORE has been used as a reason to (try to) shut down many RfCs (and in almost all cases that was a good idea). And the wording on the page supported that interpretation.
WAID disagreed with the consensus, and changed the wording without consulting the community. I reverted. Drama ensued.
Not wanting to deal with the drama, I moved on. Attempts to make RfCs unstoppable weapons continued and even intensified.
We had a discussion. WAIDs view was in the minority.
Myth: Anyone is allowed to edit PaGs and information pages, and they are descriptive not prescriptive.
Polygnotus (talk) 09:12, 23 March 2026 (UTC)[]
But thanks for proving my point I guess. Polygnotus (talk) 14:01, 23 March 2026 (UTC)[]
@Chaotic Enby, I like the idea of an WP:RFCALT shortcut. I suggest handling it as an "addition" instead of a "replacement".
The section heading could be changed to something like ==Alternatives to consider before starting an RFC== (thus incorporating both). WhatamIdoing (talk) 04:53, 23 March 2026 (UTC)[]
Maybe we could have a separate small section for RFCBEFORE which only gives advice on workshopping RfCs, along with the first para of the current section. RFCALT can then talk about other options. Would that address your concern about RFCBEFORE being weaponised? Kowal2701 (talk, contribs) 13:43, 23 March 2026 (UTC)[]
Speaking in terms of the general climate and policy writing practices, words like "normally expected to make a reasonable attempt" tend to be interpreted as "is absolutely mandatory unless certain very unusual or carefully specified conditions are met, and I am allowed to edit war your effort away if you don't" in a surprising number of situations. Think, e.g., of editors who insist that all articles must cite a source, when WP:V doesn't say that and every proposal to change that has been rejected by the community. They know they're on the side of truth and righteousness, so fiddly little details like "normally" (or, in the case of WP:V, WP:LIKELY) have no meaning.
One of the ways that we mitigate this is providing information about what's "popular", rather than what's supposed to be done. Most editors want to follow the ordinary practice, so if you tell then that _____ is popular, they'll choose that, but they're less likely to mistake "popular" for "required".
Which takes us to the main problem: Most people don't workshop their RFCs in advance, and that usually works out really well.
The first five RFCs in Category:Wikipedia requests for comment at the moment are:
This feels pretty typical to me. Most of the time, there has been some attempt to discuss the problem before starting an RFC, and most of the time, the RFC isn't workshopped (meaning the wording of the RFC question isn't discussed). That means we'd be imposing a rule on the community to change their collective behavior, and that almost never works out. I would oppose such a proposal, and (separate from my own views) I do not think it has a realistic chance of getting adopted.
WhatamIdoing (talk) 20:10, 23 March 2026 (UTC)[]
Most people don't workshop their RFCs in advance, and that usually works out really well. Then why do so many RfCs suck so much? If RfCs are usually perfect, basically no one would want to close them, because perfection requires a balance.
Also why do you keep insisting that those awesome perfect RfCs would somehow be destroyed if people were allowed to express the opinion that they are WP:BADRFCs (which you had deleted Wikipedia:Redirects_for_discussion/Log/2025_March_1#Wikipedia:BADRFC) or were allowed to say "we should probably talk about this for a bit before we start an RfC".
If there is no problem to be fixed, why does a majority of the community believe there is? And why can't they overrule one person? Polygnotus (talk) 22:20, 23 March 2026 (UTC)[]
I disagree with your belief that many RFCs suck. What is your evidence for this claim?
I disagree that a majority of the community believes there is a problem to be fixed. What is your evidence for this claim? WhatamIdoing (talk) 23:31, 23 March 2026 (UTC)[]
If we can agree on an armistice I am still willing to explain my point of view and how I reached my conclusions. But it would probably be best to start a new section to not derail this too much. If you want to keep fighting I'll go do something more productive. My evidence for the claim that there are quite a few RfCs that suck is that I read a bunch. I focused mostly on those where I felt I could quickly form an opinion. My belief that people think that there is a problem to be fixed is that a majority disagreed with you in that discussion and that people keep tinkering with the process, it is not "stable". Polygnotus (talk) 23:35, 23 March 2026 (UTC)[]
I also read a bunch of RFCs, and I conclude from reading them that only a few that have significant flaws. Unlike you, I don't focus on the ones that sound like they'll be quick to answer. (If something's reached the RFC level, it is less likely than average to be quick and easy to answer.) I know that @Redrose64 also reads many RFCs when they're posted; maybe they could share their impression. Or maybe you could post ~5 examples of current RFCs that you believe suck.
There were 14 participants in Wikipedia talk:Requests for comment/Archive 23#Bad RFC votes. Most of the comments had nothing to do with whether your undiscussed bold addition to WP:RFCEND was a good idea. Others show clear and direct support for keeping RFCBEFORE "optional". Consider, e.g., @Aquillion: "I would be strenuously opposed to making RFCBEFORE mandatory (and I'm under the impression that this has been discussed and settled at length?)" and Blueboar: "I am a strong supporter of the principle of RFCBEFORE… but I too would oppose making it mandatory. It is extremely good advice, but no more." WhatamIdoing (talk) 03:27, 24 March 2026 (UTC)[]
Well, you are clearly not ready to stop fighting. Pinging people to try to get more on your side is perhaps not the greatest strategy ever, nor is misrepresenting history.
If you ever decide you are ready you can ping me. Polygnotus (talk) 03:55, 24 March 2026 (UTC)[]
Half of that discussion was about whether it's fair to ping people when you quote them. There, I got yelled at for not pinging people. Now you complain that I did. WhatamIdoing (talk) 05:04, 24 March 2026 (UTC)[]
In that discussion: WhatamIdoing did not ping people whose edits she was criticizing. I pinged them instead. WhatamIdoing replied ... pinging exclusively people who represent one POV is a violation of Wikipedia:Canvassing (specifically "Vote-stacking: Posting messages to users selected based on their known opinions").. I tried to get wording of WP:VOTESTACK adjusted. WhatamIdoing opposed. It's unfixed. Peter Gulutzan (talk) 14:35, 30 March 2026 (UTC)[]
And, because you can never say such things often enough, I disagree strongly on this one subject but you do good work in other areas. Polygnotus (talk) 04:30, 24 March 2026 (UTC)[]
Since WAID mentioned me… I will re-iterate my opinion on RFCBEFORE (which I expressed in more detail in previous discussions): I support stating it as advice - I oppose making it mandatory. Blueboar (talk) 11:37, 24 March 2026 (UTC)[]
  • I mean, RFCs serve, among other things, as a pressure-release valve for some of the highest-tension disputes on Wikipedia (and real-world disputes that leak into Wikipedia.) They serve as a way to settle long-running disputes where editors are often very entrenched and feel strongly about the outcome. It's to be expected that there would, therefore, sometimes be editors unhappy with specific RFC outcomes - but I don't think that the RFCs are causing this problem, or making it worse; the issue is that some of the highest-profile RFCs are for things where any outcome would inevitably have a lot of people feeling upset. The fact that RFCs serve such a load-bearing role in so many high-profile situations is, I think, also a reason to be skeptical of any drastic changes that aren't very well explained. I think there's some room for improvement, but it's mostly in the form of soft encouragement for specific sorts of things and discussion of some of the ways RFCs can go awry. Overall, though, RFCs seem to mostly be working, in terms of eg. settling editorial disputes in a reasonable timeframe, or avoiding situations where disputes over a single sentence or somesuch consume endless editorial time and energy forever, or things like that. If you think that RFCs are actually making things worse you'll have to actually put together that argument. If you're going to say the majority of the community thinks there's a problem, though, I'm definitely going to slap a {{citation needed}} on that. --Aquillion (talk) 03:51, 24 March 2026 (UTC)[]
    Well of those who actually responded of course, I didn't go to everyone's house with a clipboard. 52m Wikipedia accounts. Polygnotus (talk) 03:57, 24 March 2026 (UTC)[]

RFCALT

[edit]

New section to focus on edits Dw31415 (talk) 23:16, 24 March 2026 (UTC)[]

Having followed the discussion. I think there is support for:
  • keeping RFCBEFORE shortcut with a focus on local discussion before an RFC
  • adding RFCALT shortcut to highlight alternatives
  • further discussion on if/how to include something on “workshopping” or Wikipedia:Proposal
Did I miss anything from the above discussion? Dw31415 (talk) 23:23, 24 March 2026 (UTC)[]
I'm not sure what the focus on local discussion would cover beyond the alternatives currently mentioned, as both appear to focus more on RfCs as a potential tool for small-scale dispute resolution. Chaotic Enby (talk · contribs) 23:28, 24 March 2026 (UTC)[]
I’d like to keep the RFCBEFORE shortcut and the current language on local discussion. Are you suggesting a change to either? Dw31415 (talk) 23:41, 24 March 2026 (UTC)[]
I believe either individually is fine, but both together aren't consistent with the current way RFCBEFORE is used. Chaotic Enby (talk · contribs) 00:02, 25 March 2026 (UTC)[]
I usually see it used to shut down, scold, or helpfully coach newbies from not doing (enough) local discussion topic. Is that how you see it used? Dw31415 (talk) 22:38, 25 March 2026 (UTC)[]
Often, it is for not doing enough workshopping, which I believe to be distinct from local discussion, especially in the case of wide-ranging policy changes where local discussion simply isn't an alternative. Chaotic Enby (talk · contribs) 22:40, 25 March 2026 (UTC)[]
In an RFCALT section, is it worth in a couple sentences summarising the strengths and drawbacks of RfCs compared to other options? Have a rough idea but WhatamIdoing may have more clue Kowal2701 (talk, contribs) 21:35, 4 April 2026 (UTC)[]

RFCBEFORE

[edit]

@Chaotic Enby, Dw31415, Athanelar, The ed17, WhatamIdoing, NicheSports, Polygnotus, Redrose64, Blueboar, and Aquillion: Have written this based on the above discussion (was thinking it'd come after an RFCALT section?), feel free to edit it and suggest changes. Would also like to make it so moratoriums can only be decided on at WP:AN, but that'd probably have to be discussed at Wikipedia talk:Attempting to overturn recent consensus Kowal2701 (talk, contribs) 18:04, 26 March 2026 (UTC)[]

Looks good! I've added a carveout in the timer for an RfC following one that was procedurally closed for workshopping. Chaotic Enby (talk · contribs) 18:11, 26 March 2026 (UTC)[]
There are basically three points being made in the proposed text:
  • Editors should attempt to resolve disputes locally at the relevant talk page before starting an RfC.
  • Editors can workshop the RfC beforehand to ensure a smoother process, which is especially important for changes to Wikipedia's policies and guidelines (see WP:PROPOSAL).
    • I don't think we should address "ways to not have an RFC at all" (alternatives) in the same place as "how to write your RFC question" (workshopping).
  • RfCs started soon after the closure of another RfC on the same question (eg. less than 3 or 6 months after) for a reason other than workshopping, where nothing has substantially changed, can be listed at Wikipedia:Closure requests or Wikipedia:Administrators' noticeboard, and should only be closed by someone uninvolved in the dispute. Such closures do not reset the clock since the last [proper?] RfC.
    • This needs clearer language about what kind of "closure" we mean. In particular, we need "reached consensus".
    • Since people usually start these back-to-back RFCs because they're either unaware of or dissatisfied with the previous results, it might be more practical to tell them what to do instead of what not to do (e.g., challenge the summary of the recent RFC before starting a second one).
    • This could result in claims that removing an {{rfc}} tag from a malformed request or from an abusive WP:SOCK is in violation.
    • It will put up significant barriers to repeat RFCs when these are actually needed (e.g., the Pregnancy example).
    • It will be invoked as a way to shut down related-but-different "compromise" RFCs of the sort we want to encourage. Action item: Where is the evidence that repetitive RFCs are a significant, ongoing problem? If this isn't happening frequently, then we shouldn't create these barriers.
    • Wikipedia:Closure requests will not appreciate such requests, and WP:AN might redirect it to ANI. Right now, the best place to get a new RFC shut down is probably this page.
  • For guidance on moratoriums, see Wikipedia:Attempting to overturn recent consensus § Moratoriums.
    • This might need its own section.
    • I believe that most moratoriums are imposed by ArbCom.
Another approach: What if we say that if you're irritated by frequent, redundant RFCs, then you should seek a moratorium, without which there are no restrictions on repeating RFCs? WhatamIdoing (talk) 18:50, 26 March 2026 (UTC)[]
I fully agree with WAID's points here regarding repeat RfCs and moratoria. If we want to avoid people immediately running another RfC if they don't like the outcome of the first one, the correct thing to do is, as stated, to tell them the right thing to do (challenging the closure of the first RfC); that'd mostly solve the issue. If there still happens to be a lot of RfCs on a particular topic out of genuine necessity, but the community is getting annoyed by this, then that's precisely what moratoria are for, so we should be telling people to seek a moratorium in that case. Athanelar (talk) 18:58, 26 March 2026 (UTC)[]
1. made this change (have always found CONLEVEL unintuitive)
2. I agree, this proposed RFCBEFORE section is intended to come after a RFCALT section, ie. they'd be separate
3. I agree this shouldn't apply to 'no consensus' closes. Agreed that advice on WP:CLOSECHALLENGE would be good. The intention isn't to create barriers, but to add guardrails to existing practices that counter abuse. Cutting the WP:CREEP and saying people should just seek moratoriums is a neat idea, but we would need to rework WP:MORATORIUM to prevent abuse. Tbh I've never seen one imposed by Arbcom, the four I remember were Talk:Zionism, Talk:Gaza genocide, Talk:Gulf of Mexico, and Talk:Reform UK, all decided locally. Kowal2701 (talk, contribs) 17:54, 27 March 2026 (UTC)[]
WP:ARBDSRFC authorizes moratoriums on (some?) CTOPs. I think it's better if the community self-imposes without needing to invoke the CTOP option. WhatamIdoing (talk) 18:26, 27 March 2026 (UTC)[]
Is Editors can workshop the RfC beforehand to ensure a smoother process what we want to go with? If we want to suggest that people workshop first, that "can" should be a "should," otherwise surely it's better left out? Editors can do anything they like, so I'm not sure what function this statement serves currently. Athanelar (talk) 18:54, 26 March 2026 (UTC)[]
  • And "should" will be interpreted as "must" by the loyal opposition, which sets us up for avoidable disputes. (Consider how many people already claim that they can shut down even pre-discussed RFCs because of RFCBEFORE 'violations'. That would only get worse.)
  • We have some evidence that most RFCs aren't workshopped. Moving even to a "should" standard would mean that we're imposing new rules on the community, instead of documenting the community's practices.
  • What happens if editors workshop the RFC question, but they can't agree on how to phrase it? Do they then switch to workshopping an RFC on resolving their dispute about the RFC question? Can one side stonewall the RFC and prevent the community from learning about the problems in an article?
About that last point, I've been herding cats in a dispute recently. The real-world facts are a series of events in which at least three parties take turns screwing up. One of the editors keeps proposing "neutral" summaries that amount to "B screwed up. B screwed up again. B screwed up another way. C was sad that B kept screwing up", while omitting the information about A and C screwing up. It feels like they're stuck so deep in their little POV bubble that they can't even imagine the possibility that B is not the only party that screwed up. If this ends up with an RFC, I doubt that workshopping would get that editor to propose a version that isn't a one-sided list of how B screwed up, excluding all the other parties that also screwed up. What then? We "should" workshop it, but the workshopping didn't produce an agreement about what to propose. What do you think should happen when workshopping fails, as it inevitably will? WhatamIdoing (talk) 19:43, 26 March 2026 (UTC)[]
You beat them to starting the RfC :) or call it out as non-neutral, people will follow, and the question would either get changed, or time will get wasted and the RfC eventually closed as malformed, serving as a blemish on that editor's record re POV pushing Kowal2701 (talk, contribs) 18:04, 27 March 2026 (UTC)[]
In that case, why should anyone bother workshopping the RFC question in the first place? The end result won't change. WhatamIdoing (talk) 18:28, 27 March 2026 (UTC)[]
Hopefully in most cases editors will collaborate, this is just "worst case scenario", but the proposal below waters down advice on workshopping normal RfCs Kowal2701 (talk, contribs) 18:30, 27 March 2026 (UTC)[]
If we think of this as a spectrum, it runs something like this:
[A B C D E F G H I J K L M N O P Q R S T U V W X Y Z]
and I suggest that:
  • A through T are simple enough that a pro-workshopping rule would be all costs and no discernible benefit.
  • U and V would get some worthwhile benefits (and one of them is already workshopping the question).
  • X, Y, and Z are going to be a mess no matter what, and workshopping might add another layer of drama ("The workshopping phase was not conducted in good faith, because he didn't agree to my suggestions!").
For this ~5% benefit, we'd be imposing costs on all the RFCs. I'm pro-workshopping – I suspect that every word on this page about workshopping and seeking help was put there by me – but I'm not pro-requirement. WhatamIdoing (talk) 18:58, 27 March 2026 (UTC)[]
neither! Kowal2701 (talk, contribs) 19:01, 27 March 2026 (UTC)[]
Now that I (we? ha) are aware of WP:PROPOSAL I am wary of advancing changes to the language on the RfC page. I am inexperienced in content-related RfCs (even more reason for me to abstain here) but I intuitively understand WhatamIdoing's concern about changes to the page being used to shut down such RfCs. If anything, I would support adding a clarification at the end of RFCBEFORE (or a hatnote above) along the lines of For the expected community workshopping process preceding a proposal for modifications to Wikipedia's PAGs, instead see WP:PROPOSAL NicheSports (talk) 22:22, 26 March 2026 (UTC)[]
Maybe "expected" would be too strong of a word? Something like "For the community workshopping process that may precede a proposal..." Chaotic Enby (talk · contribs) 22:32, 26 March 2026 (UTC)[]
Good catch thanks. I struck "expected" above but would support your language as well NicheSports (talk) 22:38, 26 March 2026 (UTC)[]
WP:PROPOSAL is already linked (and has been for a long time) at Wikipedia:Requests for comment#Publicizing RfCs.
Can we talk about the overarching theme, which is that if anyone finds anything on this page useful, they believe that thing is (or should be) in RFCBEFORE and not in any of the other sections on the whole page? I'm a bit frustrated about this, and I'm wondering whether RFCBEFORE should be turned into a WP:DAB page. You know the type:
"If someone told you to look at RFCBEFORE, they might have meant:
We could pretty much duplicate the Table of Contents and throw in a couple of extras, because at some point, someone will need that process or information "before" whatever it is that they need to do next. WhatamIdoing (talk) 00:39, 27 March 2026 (UTC)[]
Turning RFCBEFORE into a disambiguation is also a fairly elegant solution to the problem of people invoking RFCBEFORE like a magic RfC-invalidating spell. Athanelar (talk) 01:45, 27 March 2026 (UTC)[]
I chose the shortcut name (see above) to specifically concern the section named "Before starting the process" as a parallel to the existing shortcuts WP:BEFORE (WP:AFD#Before nominating: checks and alternatives) and WP:BEFORECFD (WP:CFD#Manual nominations → Before nominating a category). There is also WP:BEFOREMOVING (WP:MOVE#Before moving a page), but that was created about five weeks after RFCBEFORE. I put the letters RFC first, not last, to match with WP:RFCEND. --Redrose64 🌹 (talk) 18:01, 27 March 2026 (UTC)[]
I appreciate the parallel nature of the name. The problem isn't the name itself, but rather that editors are looking for a stick to beat an RFC with ("beat" both in the sense of hitting it and of winning), and RFCBEFORE has become the word that they use. Their use of it frequently has nothing to do with the name; it's just a magic power word that means you lose and I win because bureaucracy rules!
I think that turning it into a DAB page would actually allow it to be useful while discouraging its use as a stick and even encouraging editors to say what they actually mean. WhatamIdoing (talk) 19:02, 27 March 2026 (UTC)[]
I don't think turning it into a disambiguation page would prevent abuse, people will still cite it and point to the bit they like. Deleting it at RfD is a better option if we go this route, but I can't see that gaining consensus unless the nom provided massive amounts of evidence Kowal2701 (talk, contribs) 18:06, 27 March 2026 (UTC)[]
How does this version look? Kowal2701 (talk, contribs) 18:13, 27 March 2026 (UTC)[]
Compare:
−
Editors can the though not to a workshopping phase.
+
Editors can the though not to a workshopping phase.
WhatamIdoing (talk) 18:52, 27 March 2026 (UTC)[]
I like the first sentence, but Most RfCs don't need a workshopping phase. or Most RfCs function well without undergoing a workshopping phase. appear clearer? Kowal2701 (talk, contribs) 19:06, 27 March 2026 (UTC)[]
I lean slightly towards "Most RfCs don't need a workshopping phase". WhatamIdoing (talk) 19:09, 27 March 2026 (UTC)[]
Should we just say Editors should not cite this section as a way to shut down an RfC. on its own line rather than trying to engineer? It'd still require someone clicking the shortcut lol Kowal2701 (talk, contribs) 19:14, 27 March 2026 (UTC)[]
"Prior discussion of the RFC question is not required and is not a valid reason to shut down an RFC"? WhatamIdoing (talk) 19:41, 27 March 2026 (UTC)[]
I like that, we can also have a hatnote pointing to PROPOSAL to mitigate confusion Kowal2701 (talk, contribs) 19:46, 27 March 2026 (UTC)[]
How often does a full-scale WP:PROPOSAL happen? Maybe twice a year? If so, repeating and emphasizing that is irrelevant information that will distract >99% of editors from the information they need. WhatamIdoing (talk) 00:02, 28 March 2026 (UTC)[]
Looks great! We could even adapt the existing "Are you trying to shut down someone else's RfC?" box for that purpose. Chaotic Enby (talk · contribs) 20:39, 27 March 2026 (UTC)[]

though they are not required to accept any advice they receive or to reach a consensus on what wording to use before starting the RfC

In my opinion, this phrase from WAID is essential. The editor for this airports RfC put in more work than should be expected of anyone. Dw31415 (talk) 12:58, 28 March 2026 (UTC)[]
Yes, he did. He deserves a Barnstar of Perseverance. WhatamIdoing (talk) 21:37, 28 March 2026 (UTC)[]
I have not read much of the long discussion in this section; I just browsed it very rapidly. The following are comments extracted under duress to avoid trouting. My suggestion of improved wording at WP:RFCBEFORE is to include in the hatnote something along the lines of For advice on preparing a proposal that will be proposed in an RfC, see WP:PROPOSAL. But I also think that at WP:PROPOSAL, between the Brainstorming and Creating a request for comment, it would probably be useful to have a section describing the in-between steps, such as using {{draft RfC}}. (Feel to copy/paste this or link to it over there.) Boud (talk) 21:03, 4 April 2026 (UTC)[]

RfC tag

[edit]

I just learned that there's a tag now for the addition/removal of the {{rfc}} template. It displays as "Tag: RfC discussion" in the edit summary. Did this tag exist before March 5? Some1 (talk) 23:08, 25 March 2026 (UTC)[]

I think Polyg added that. There was some discussion about it but I can’t remember if that was here. Dw31415 (talk) 00:05, 26 March 2026 (UTC)[]
@Polygnotus: mentioned here Wikipedia talk:Requests for comment#c-Polygnotus-20260305003300-Dw31415-20260222110400. I can’t remember the exact context but I think it was around doing some research into how well formed the new RfC questions are. Dw31415 (talk) 03:00, 26 March 2026 (UTC)[]
@Some1 Did this tag exist before March 5? The filter did. It was created at 23:32, 4 March 2026 after my request here. I think the tag did not exist before March 5. Polygnotus (talk) 03:08, 26 March 2026 (UTC)[]
This RecentChanges filter will show all recent RFC creations, in date order. WhatamIdoing (talk) 04:14, 26 March 2026 (UTC)[]
Are we sure that works properly? It doesn't seem to show nearly enough RfCs for it to be accurate. Katzrockso (talk) 23:55, 4 April 2026 (UTC)[]
How many were you expecting it to find? WhatamIdoing (talk) 04:17, 5 April 2026 (UTC)[]
I don't have as much RfC experience as you, but I'm seeing about 1 per day and that seems fairly low for how many I get bot requested to participate in (which I did admittedly set fairly high) Katzrockso (talk) 04:30, 5 April 2026 (UTC)[]
Averaged out over the last month, it's about three flagged edits per day, and maybe two actual pages per day on average (Talk:Daghaghra, for example, appears in the list nine times). This is what I expected.
As another practical way to check, all the RFCs you were notified about are in the list, and all the RFCs in Wikipedia:Requests for comment/Politics, government, and law are in the list. WhatamIdoing (talk) 05:12, 5 April 2026 (UTC)[]

How to find previous RFCs at an article?

[edit]

Is there a quick way to find a list of the previous RFC's at an article? If not, maybe such a list should be included at Template:Talk header? Anythingyouwant (talk) 21:47, 29 March 2026 (UTC)[]

No, but if you search for "RFC" or "Request for comment" in the talk page archives, you'll usually be able to find them. We've been trying to get people to include that in the section heading for some years now.
Alternatively, as a one-off thing, you could look at https://quarry.wmcloud.org/query/100675#, sort by the page name, and see how many times a page turns up in the list. For example, I count exactly 100 entries for Talk:Donald Trump. WhatamIdoing (talk) 00:20, 30 March 2026 (UTC)[]
I collected all the historic RfC’s here: User:DwAlphaBot/RfcHistory please try the search and let me know if it works. Dw31415 (talk) 01:31, 30 March 2026 (UTC)[]
Thanks for the info, it looks like a very handy tool. Anythingyouwant (talk) 03:40, 30 March 2026 (UTC)[]

Disabling an RfC

[edit]

I expanded the example given for how to disable (not remove) RfC: Wikipedia:Requests for comment#Reasons and ways to end RfCs.

Please review this so I did not make a mistake, and feel free to further improve.

Please also add reasons for why or when it is appropriate to disable the RfC instead of removing it.

CapnZapp (talk) 13:14, 30 March 2026 (UTC)[]

Well... there are basically no reasons to do that, which is why we never bothered to add those (complicated) directions before. WhatamIdoing (talk) 18:19, 30 March 2026 (UTC)[]

Restrictions on who can respond to certain RfCs

[edit]

WP:RFCRESPOND says "All editors (including temporary account users) are welcome to respond to any RfC." This isn't accurate. For example, non-extended confirmed accounts are not allowed to respond to RfCs about WP:PIA content. In some cases, a talk page will be page protected to prevent their participation, but not always, and they're not allowed to participate even when it isn't. I don't know enough about the various WP:CTOPs to know whether there are other CTOPs that have XC restrictions. Should this text be modified along the lines of "All editors (including temporary account users) are welcome to respond to any RfC, unless that RfC falls under a contentious topics restriction on participation"? FactOrOpinion (talk) 17:08, 31 March 2026 (UTC)[]

  • Closers won't give weight to accounts that don't have much editing history, particularly in contentious topic areas. But those accounts might make points that persuade established editors and thereby affect the course of the debate. Sysops have the community's authority to hat or remove unhelpful contributions in CTOPs. Where no sysop has chosen to do that, then as a closer, I wouldn't give the brand new account's !vote any weight in the close, but I also wouldn't try to subtract any effect their words had on editors with standing to vote.—S Marshall T/C 17:32, 31 March 2026 (UTC)[]
    That comes very close to caring about the contributor rather than the content. I hope that newbies with a good explanation get more weight in your summaries than experienced editors who place a bare vote.
    FOO, I think your suggested sentence could be usefully generalized, e.g., "unless there are specific behavioral restrictions in place, including page protection, partial blocks, or Arbitration Committee restrictions". WhatamIdoing (talk) 19:55, 31 March 2026 (UTC)[]
    The question assumes a CTOP where non-extended-confirmed accounts aren't allowed to participate, and my answer above assumes that context.—S Marshall T/C 22:05, 31 March 2026 (UTC)[]
    WAID, that's better than what I suggested and works for me. S Marshall, I've seen editors strike !votes from people who are restricted from participating in an RfC, with a note about why. FactOrOpinion (talk) 20:53, 31 March 2026 (UTC)[]
    Elected sysops have authority to do that. Others maybe shouldn't, although they often do. When non-admins strike a !vote I do just look to see why; I want to know if they're striking all the temporary accounts or if striking selectively to favour a particular position.—S Marshall T/C 22:05, 31 March 2026 (UTC)[]
    I wasn't always such a suspicious and cynical man. A dozen years and several hundred RfC closes have ground me down!—S Marshall T/C 22:09, 31 March 2026 (UTC)[]
    I’m surprised by they're not allowed to participate even when [the talk page] isn't [protected], so I prefer WAID’s construction. If the participation restriction exists outside page protection, FOO’s edit would benefit from a more specific reference to that restriction. Dw31415 (talk) 11:02, 1 April 2026 (UTC)[]
    I think it depends for contentious topic area with ECR areas absolutely disallowing any nonXC editors. For newbies in other contentious topic areas, it depends, but generally WAID would make most sense. Having XC status does not make sense as a filter unless there is some clear extenuating situation i.e. the topic is particularly in the news and is attracting folks who are voting based on their opinions or there is obviosu sockpuppetry happening. Of note, though newbies can and often do have novel and useful arguments like WAID suggests, it really does seem like CTOPs are more likely to attract folks who fail to realize an RFC is WP:NOTAVOTE. Im fine with filtering votes that arent based on policy (i.e. naked votes with no explanations). User:Bluethricecreamman (Talk·Contribs) 16:54, 1 April 2026 (UTC)[]
Since no one objects to WAID's proposed text and most of us have expressed support for it, I'm going to add that text to WP:RFCRESPOND. FactOrOpinion (talk) 13:54, 3 April 2026 (UTC)[]

Freezing a page during a proposed guideline RfC

[edit]

WP:GENOCIDE is likely to be proposed in an RfC as a possible guideline very soon. If any non-trivial edits to WP:GENOCIDE are made between the RfC opening and closure, then the closer may be concerned that many of the !votes are about significantly different versions of the text, making it difficult to summarise. Is there a hatnote template to stick at the top of the page after opening the RfC along the lines of "An RfC is ongoing; please do not make any non-trivial edits until closure"? Or is it enough to assume that common sense will prevail and any non-trivial edits will only be edits that clearly gain consensus while the RfC is open? Or maybe just ECP both WP:GENOCIDE and the talk page, as suggested by Robertsky, would be better than a hatnote? Or should a particular {{oldid}} be written into the RfC question? Boud (talk) 23:34, 2 April 2026 (UTC)[]

@Boud, we've been pretty successful in the "common sense prevailing" department. The tag you're looking for is Template:Proposal. Have you read the WP:PROPOSAL policy yet? WhatamIdoing (talk) 01:09, 3 April 2026 (UTC) (minor fix Boud (talk) 15:33, 3 April 2026 (UTC))[]
"Common sense prevailing" OK :). Yes, I browsed that, and we already have the draft-level template, currently with |section = Draft proposal, just needing to be switched to = proposal. Boud (talk) 09:31, 3 April 2026 (UTC)[]
I see that {{draft proposal}} != {{proposal}}, and that "section" means the talk page section for a link, so it's the template name that mainly needs switching, although the section parameter will need updating too. Boud (talk) 15:33, 3 April 2026 (UTC)[]
Use whichever template gives the message that you want. The templates exist solely to help you communicate. If they do not seem helpful, then do not use them. WhatamIdoing (talk) 18:53, 4 April 2026 (UTC)[]

Main proposal contributor as RfC proposer

[edit]

At WP:GENOCIDE, I'm the main contributor to both the content and the talk page. I've suggested that someone else than me close the WP:RFCBEFORE and launch the RfC, but given that waiting for that might lead to nothing happening, I guess it's OK if I'm the one who loses patience and launches the RfC myself. Would this be OK? Boud (talk) 11:12, 4 April 2026 (UTC)[]

I’m confident that you are well positioned to post the RfC yourself but I’m not familiar enough with policy ones to give you complete advice on some other aspects. I recommend:
thanks for all your contributions on this! Dw31415 (talk) 12:34, 4 April 2026 (UTC)[]
Thanks for the response. The {{draft RfC}} template looks useful. I've posted Wikipedia talk:Genocide#Draft RfC on WP:GENOCIDE. Boud (talk) 16:57, 4 April 2026 (UTC)[]
@Boud, please read Wikipedia:Requests for comment#Before starting the process and tell me why you think RFCBEFORE is relevant to what's happening on that talk page. Do you have a dispute there that could be resolved through a different, non-RFC method? (NB: RFCBEFORE says nothing about polishing up a WP:PROPOSAL or discussing how to word an RFC question.) WhatamIdoing (talk) 18:51, 4 April 2026 (UTC)[]
I agree that the text of WP:RFCBEFORE is not about polishing up a WP:PROPOSAL. Buidhe did actually allude to WP:RFCBEFORE on the proposal talk page. But I admit that my intended meaning was the-stuff-to-do-before-an-RfC-for-a-proposed-guideline-becomes-an-RfC, and not literally WP:RFCBEFORE. You may WP:TROUT me for my violation. I've adjusted the section title. Boud (talk) 20:16, 4 April 2026 (UTC)[]
Instead of trouting you, I'd rather sentence you to telling us in Wikipedia talk:Requests for comment#RFCBEFORE wording what would be useful to editors like you. (I know, it's a much worse sanction. But it really would be helpful, so I hope you'll at least consider it.) WhatamIdoing (talk) 20:24, 4 April 2026 (UTC)[]
Boud, you should just go ahead and open the RfC if you feel it is the time :) (t · c) buIdhe 20:28, 4 April 2026 (UTC)[]

No other responses on my RfC - where to go from here?

[edit]

I started an RfC at the MOS for novels as a result of a dispute between myself and a single other editor. I decided on an RfC rather than 3O because I thought the wider community might have input. The RfC was started on March 23 and so far, only myself and the other editor have commented. Would it be appropriate to ask an uninvolved editor here close the RfC? Would it be appropriate to ask for an editor at 3O to chime in? Or is there any other suggestion for moving forward? Many thanks. Michelangelo1992 (talk) 12:23, 6 April 2026 (UTC)[]

I don't think that 3O will take it, but I'll post a few announcements for you. I've added the two versions so people can see what they look like, if they want. WhatamIdoing (talk) 18:33, 6 April 2026 (UTC)[]
Thank you! I did not think to advertise on the Hugo Award talk page, but in hindsight it makes perfect sense. I also appreciate you adding the templates directly to the RfC. Michelangelo1992 (talk) 18:52, 6 April 2026 (UTC)[]
You're welcome. WhatamIdoing (talk) 23:13, 6 April 2026 (UTC)[]

"BADRFC" or WP:BADRFC

[edit]

I don't know how many exactly, but there are probably dozens, if not hundreds of RfCs which might be called "BADRFC" or that at least have others chiming in saying "WP:BADRFC". This was at one time a redirect at least to Wikipedia:Requests_for_comment#Statement_should_be_neutral_and_brief. I think it is time for that redirect to be restored, or for there to be a section on the article which outlines and shortcuts to WP:BADRFC that the community may benefit from. Does anyone else feel strongly about this? Iljhgtn (they/them · talk) 22:34, 8 April 2026 (UTC)[]

personal thoughts: closing as a badrfc is still a close. If folks vote for badrfc, and the closer takes that into account, the close can be such that there was no consensus drawn.
there is no specific guideline that mandates an RFC as so flawed it fails automatically, someone needs to argue that the RFC isn't the proper tool for generating consensus at that specific moment.failing to follow guidelines like a neutral brief statement, or WP:RFCBEFORE just make it more likely for folks to think the RFC isn't worth using as a tool at that instance, but they aren't disqualifying, and a closer can choose to consider the votes or other factors when determining consensus. User:Bluethricecreamman (Talk·Contribs) 22:51, 8 April 2026 (UTC)[]
Very good comments @Bluethricecreamman, but would you say that we would not benefit from having WP:BADRFC link to something stating much of this at least? Seems time for a subsection which discusses the flaws of bad rfc's which lacked adequate discussion or options before launching. Iljhgtn (they/them · talk) 23:19, 8 April 2026 (UTC)[]
there is significant disagreement, and interpretation. feel free to make one WP:BOLDly, but for it to graduate from a WP:ESSAY it would need some form of consensus User:Bluethricecreamman (Talk·Contribs) 02:13, 9 April 2026 (UTC)[]
Oppose adding WP:BADRFC, but favor adding something. I think it's better to have more specific links to the aspects of a good RfC. I was hoping the last discussion I raised § Ways to handle Bad RfC would result in something. I even started to play with a template that we could create: User:Dw31415/RfC_Change_Templates. The discussions tend to get bogged down on whether and when editors (or admins?) can "shut down" an RfC without anyone taking the time to work out a concrete proposal. Dw31415 (talk) 23:44, 8 April 2026 (UTC)[]
A few points:
  • The "too wordy" problem should get fixed with an editing button. The person clicking the editing button should not be perceived by the OP as an opponent.
  • "Should this article be deleted?" is not a common enough RFC question that a template is worthwhile. If it's an ordinary deletion request, an uninvolved editor should pull the RFC tag and make a procedural nomination at AFD. If you do this, please ping at least the OP. (I specify "ordinary" because every now and again an RFC is used for complex deletion/blanking requests, e.g., WP:LUGSTUBS.)
  • The "horrible" problem should be evaluated for whether it's a significant/substantial problem. If there are already editors lining up to say "No, this beautiful thing should be kept, and you shouldn't post questions that violate WP:RFCNEUTRAL", then it's often okay to leave it alone. (Remember: The goal is to resolve the dispute, and not to follow the bureaucratic process.) If it does seem to be a problem, then the solution and the constraints are the same as the "too wordy" problem.
WhatamIdoing (talk) 23:53, 8 April 2026 (UTC)[]
problem should get fixed with an editing button
I haven't seen this approach discussed on this page recently and I note that the FAQ above says If you believe that a question is non-neutral, you are better off simply participating in the RFC to present arguments about the underlying dispute. I wonder if we should edit the FAQ above and see if there is acceptance of this. I worry a little bit about an edit war developing on the RfC question. Dw31415 (talk) 01:05, 9 April 2026 (UTC)[]
I'm open to any such improvements. Iljhgtn (they/them · talk) 01:08, 9 April 2026 (UTC)[]
Iljghtn, what are the criteria by which editors will be able to agree on whether a given RFC is a "bad" one?
Or do you mean to have WP:BADRFC point to a sentence that says something like "An editor's opinion that a given RFC is 'bad' is not disqualifying. There is no guideline anywhere that says just because you believe the RFC is fatally flawed that it fails automatically, or that you personally are allowed to shut it down"? (This is approximately what I see in Bluethricecreamman's comment, which you have called "very good".)
For example, I see you have objected to an RFC at Talk:Republican Party (United States) whose question is "Should the V-DEM Institute classification of the Republican Party be mentioned in this article?". This is brief. This is neutral. AFAICT the only actual problem with it is that you find it irritating to be asked the same thing again. (I would, too.)
Just for reference, there are only about two new RFCs per day on average, so unless the majority of them are "bad", then "hundreds" sounds like an exaggeration. WhatamIdoing (talk) 23:46, 8 April 2026 (UTC)[]
I think we should discuss this more, I am not claiming I have all the answers. Iljhgtn (they/them · talk) 00:32, 9 April 2026 (UTC)[]

Bold WP:BADRFC essay

[edit]

At this point, I've just WP:BOLDly made this essay. As its an essay, it does not claim to have consensus, and accordingly, I also attempted to make no overwhelming statements of fact. I've instead summarized what I've sometimes read on this page. Feel free to edit please? User:Bluethricecreamman (Talk·Contribs) 19:06, 9 April 2026 (UTC)[]

I think that was a really solid start, and thank you for doing that @Bluethricecreamman. I made some copyedits and what I feel are clarifying commentary and changes. Also updated the shortcut. This was a long time coming and will really help a lot I think. It would be good perhaps to add a detail linking to this essay in the WP:RFCBEFORE section too so that people know about it and can contribute their thoughts and feedback. Iljhgtn (they/them · talk) 22:30, 9 April 2026 (UTC)[]
Bits such as "Editors can always !vote for..." and "Choosing "BADRFC" is still a !vote" make me wonder how many editors believe that RFCs are a vote.
This bit: "A closer can always end an RFC as a "BADRFC" if there is consensus for the RFC to be closed under BADRFC" is wrong. "Closers" (who are they?) don't decide when to end an RFC, and they can't really close a discussion "under BADRFC" because BADRFC is not a reason to end an RFC. I would be interested in seeing examples of closing editors writing something like "The consensus was BADRFC".
I'm going to go re-write the page, and I'd be interested in hearing what you think of the differences. WhatamIdoing (talk) 23:40, 9 April 2026 (UTC)[]
usage of the word "vote" was wrong on my part, agreed. I think it may also be worth explaining that if you just say "BADRFC" without giving a good explanation, that should be thrown out by a competent closer.closers, by closing, are definitionally deciding when to end. if they end too early, you just go through the process of asking them to wait thirty days if the result wasn't obvious, or barring that, doing a close review.agree "under BADRFC" is wrong language, wasn't my language and seemed to be added by @Iljhgtn. think its more of, the "Closer decided the consensus was BADRFC", there is no specifically defined policy meaning to BADRFC, the closer needs to make sure to explain what the consensus was when they close as BADRFC. User:Bluethricecreamman (Talk·Contribs) 23:50, 9 April 2026 (UTC)[]
WP:RFCEND is how we decide when to end. Closers come into the process only if we ask them to.
Have you actually seen an RFC that ended with words like "the consensus was BADRFC"? These search results say that this doesn't actually happen.
I've just finished the re-write. WhatamIdoing (talk) 00:36, 10 April 2026 (UTC)[]
  • An RfC should last until enough comment has been received that consensus is reached, or until it is apparent that it won't be. There is no required minimum or maximum duration; typically 7 days is a minimum, and after 30 days the discussion is ripe for closure. definitionally, closer is calling the consensus including when appropriate for RFC to close. they use the community's args to make the close summary and decide if an RFC is snowing, or if there is need for broader community input across a longer time, and are informed by community, but the words they spell out, and the decision to answer the eventual call to close are definitionally theirs. If it happens the wording doesn't reflect the community or the close was inappropriately timed, we go to user talk to ask to unclose, then do close review, etc. etc.
  • Examples seem to suggest closers don't use the term bad rfc, but do close for malformed RFCs, or if nominator withdraws: [3], [4], [5] [6] [7]
  • Many also that seem to be no consensus.
In general, its probably a bad close if the close is just "BADRFC" without additional explanation. User:Bluethricecreamman (Talk·Contribs) 00:51, 10 April 2026 (UTC)[]
That search showed just 9 results.
Of the examples, the first three are the OP withdrawing, which is an explicitly authorized WP:RFCEND option and unrelated to someone else claiming that it's "bad". The fourth was one of the RFC regulars doing routine clerking. The fifth one seems weird to me: This isn't the German-language Wikipedia, where RFC voters are expected to vote on whether the RFC is properly presented before deciding how they're going to vote. WhatamIdoing (talk) 02:38, 10 April 2026 (UTC)[]
Again, you can do permutations of bad rfc (52 hits), badrfc (9 hits), malformed rfc (50 hits) and get more results though it would take time to review and filter for possible applicable closes. Arguably, folks yell "Procedural close (102 hits)", though there is a bit less signal there.agree i was wrong, nobody closes with the exact term “BADRFC”. That proposers are withdrawing rfcs early after many folks yell BADRFC is likely worth studying alongside the other closes. User:Bluethricecreamman (Talk·Contribs) 13:56, 10 April 2026 (UTC)[]
If i have time, it may be interesting to search and filter and ask for feedback of closes where BADRFC was a major part of the vote User:Bluethricecreamman (Talk·Contribs) 13:59, 10 April 2026 (UTC)[]
some close examples that seem interesting to look at.
Talk:A Discovery of Witches (TV series)#c-FormalDude-2022-02-25T02:52:00.000Z-RFC, this is technically a good procedural close actually, but the close description could have had more details added on why.
Talk:True North Centre for Public Policy#c-Maddy_from_Celeste-20240926070900-Request_for_comment_on_opening_sentence .No consensus and bad RFC
Talk:IPod Touch#c-Mathglot-2022-03-14T19:55:00.000Z-"iPod_Touch"_or_"iPod_touch"? ... rfcbefore being cited as reason to close early
Talk:Islamism#c-SmittenGalaxy-20250707181500-Request_for_Comment:_Lead_sentence_wording_and_definition - Procedural close due to lack of WP:RFCBEFORE.
Talk:Giovanni Gentile#c-Galobtter-2018-02-24T19:30:00.000Z-RfC_re:_sourcing_of_socialist_claim - Premature Rfc... well technically closer quotes a participant wrt User:Bluethricecreamman (Talk·Contribs) 15:16, 10 April 2026 (UTC)[]
would it be worth courtesy pinging folks whose closes we are looking at btw? User:Bluethricecreamman (Talk·Contribs) 16:26, 10 April 2026 (UTC)[]
If you do, someone will complain about canvassing. If you don't, someone will complain that you're talking about people behind their backs. I don't think it is possible to please everyone. WhatamIdoing (talk) 18:29, 10 April 2026 (UTC)[]
Here are my thoughts on this list:
  • Talk:A Discovery of Witches (TV series): It's #1 and #2 on the list of ordinary ways to end an RFC.
  • Talk:True North Centre for Public Policy: There was a complaint about WP:RFCNEUTRAL but it wasn't a problem that interfered with having a productive conversation. In fact, I think that I'll put a version of that question in the new essay as an example of what we don't stop an RFC over.
  • Talk:iPod Touch: This is primarily interesting to me because it didn't get any responses in the week before it was closed. It was probably the editor's first attempt at an RFC. Ideally, this would have been handled a little differently, by asking the OP if they're willing to withdraw the question/end the RFC themselves. Many people are satisfied with any solid answer.
  • Talk:Islamism: IMO this was wrong. The RFC should have been allowed to proceed. The rationale is self-contradictory (closed because of insufficient prior discussion, when both the OP and the closer are pointing at a discussion on the same point). If I'd been asked, I'd probably have suggested merging the RFC into the existing discussion.
  • Talk:Giovanni Gentile: IMO this was also wrong, but less so. The thought was that an RFC was unnecessary. However, that was in 2018, and in the entire calendar year, only 7 comments were posted on that talk page outside of the RFC. Sometimes editors start an RFC because they reasonably expect that it's the only way to get a response. Editors shouldn't have to spend weeks shopping your question around to various pages in the search of a response; they should be able to start an RFC if they think that's what's necessary to get an answer.
I appreciate you taking the time and effort to find a list of interesting examples. WhatamIdoing (talk) 18:57, 10 April 2026 (UTC)[]
Possibly philosophical thought experiment, If a close is wrong, but nobody cares to appeal or follow up, is it really wrong?
it’s technically a tenuous consensus until the next discussion or someone follows up on it User:Bluethricecreamman (Talk·Contribs) 19:02, 10 April 2026 (UTC)[]
  • Quick comment: Every time I see someone use “BADRFC”, I think we are chastising a puppy that has peed on the carpet, or a toddler that crayoned on the wall … “bad, BAD RFC! Naughty RFC! Go sit in the time out chair!”
could we perhaps change it to “FLAWED RFC”? Blueboar (talk) 00:33, 10 April 2026 (UTC)[]
Probably not. mw:Naming things is hard, but I think there are a few editors who specifically want to use that chastising tone. If we're going to keep this essay, it should probably have a section about WP:CIVILITY added. WhatamIdoing (talk) 00:37, 10 April 2026 (UTC)[]
There is no way to avoid chastising an editor wrt this, im afraid. and as Bad RFC really isn't any standardized term, there is nothing to change. Agree it is worth suggesting that voting BADRFC can be WP:BITEY in the essay. User:Bluethricecreamman (Talk·Contribs) 00:54, 10 April 2026 (UTC)[]
I think the essay should take a position on “procedural” close comments and closes like in the last example you provided Talk:H. P. Lovecraft/Archive 6#Request for comment . What’s your position on them? Dw31415 (talk) 11:45, 10 April 2026 (UTC)[]
There is no procedural close category for that HPLovecraft rfc. Like waid suggests, there are some procedural closes that exist like if OP withdraws early, though its debatable if that belongs in same category as BADRFC. User:Bluethricecreamman (Talk·Contribs) 13:58, 10 April 2026 (UTC)[]
The Lovecraft RFC wasn't a procedural close. There are 33 days between the start and the summary being posted. WhatamIdoing (talk) 18:28, 10 April 2026 (UTC)[]
Category: