Wikipedia talk:Requests for comment: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎Why is nobody participating in this RfC: let the Muslims fight it out
Line 192: Line 192:
::@[[User:BilledMammal|BilledMammal]], this all happened about a decade before your first edit, but the problems with local consensus came to a head in 2009 and early 2010. We had an RFC that ultimately resulted in both clarifying the Consensus policy and [https://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Council/Guide&diff=prev&oldid=352646221 creating] [[WP:ADVICEPAGE]]. The key discussion that affirmed the undesirability of small groups of editors exempting their content from the general rules was [[Wikipedia talk:WikiProject Composers/Infoboxes RfC]] – an RFC that [https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Composers&diff=prev&oldid=345732398 started] on the WikiProject's talk page.
::@[[User:BilledMammal|BilledMammal]], this all happened about a decade before your first edit, but the problems with local consensus came to a head in 2009 and early 2010. We had an RFC that ultimately resulted in both clarifying the Consensus policy and [https://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Council/Guide&diff=prev&oldid=352646221 creating] [[WP:ADVICEPAGE]]. The key discussion that affirmed the undesirability of small groups of editors exempting their content from the general rules was [[Wikipedia talk:WikiProject Composers/Infoboxes RfC]] – an RFC that [https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Composers&diff=prev&oldid=345732398 started] on the WikiProject's talk page.
::@[[User:Super ninja2|Super ninja2]], have you followed the steps for publicizing the discussion at [[Wikipedia:Requests for comment#Publicizing an RfC]]? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:53, 10 March 2024 (UTC)
::@[[User:Super ninja2|Super ninja2]], have you followed the steps for publicizing the discussion at [[Wikipedia:Requests for comment#Publicizing an RfC]]? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 19:53, 10 March 2024 (UTC)
:::I'm guessing editors are staying away because it's a Muslim issue and religious crazies are unappealing to everyone else. Why would I posit my opinion in that RfC when I see you and others arguing about it? I only provide my 2 cents when the bar to entry is zero. <span class="nowrap"><span style="font-family:copperplate gothic;">[[User:Chris troutman|<span style="color:#345">Chris Troutman</span>]] ([[User talk:Chris troutman|<span style="color:#345">talk</span>]])</span></span> 20:00, 10 March 2024 (UTC)


== Would this be appropriate? ==
== Would this be appropriate? ==

Revision as of 20:00, 10 March 2024

WikiProject iconDispute Resolution (inactive)
WikiProject iconThis article is within the scope of WikiProject Dispute Resolution, a project which is currently considered to be inactive.

Previous discussion

There needs to be stronger wording to emphasize that before an RfC is initiated (except for proposed policy/sitewide changes), there must have been extensive discussion with multiple participants, a reasonable timespan, and no consensus. WP:RFCBEFORE currently says Editors should try to resolve their issues before starting an RfC. Try discussing the matter with any other parties on the related talk page, which comes across as more of a suggestion than a requirement. WP:ANI has a large red box emphasizing that notifying involved editors is required; WP:MR says in bold that editors must discuss with the closer before a move review. I feel like a similar level of emphasis is warranted here. InfiniteNexus (talk) 06:45, 4 February 2024 (UTC)[reply]

Hi, @InfiniteNexus. I mostly agree with you in the general case, but RFCs cover a lot of discussion types. There are a few things that pretty much have to be handled as an RFC (e.g., if you're making a WP:PROPOSAL), and in some situations, editors are starting an RFC because they have no realistic hope of getting responses otherwise (e.g., on a new or under-watched page). Starting a discussion on the talk page before starting an RFC might not be particularly helpful in some cases.
The goal behind the RFCBEFORE language is mostly to discourage the kind of editor who jumps to an RFC over every little thing. If an ordinary, un-advertised chat on the talk page can answer a question or resolve a problem, then that's best. I think it's the same motivation at MR: don't bother everyone else with a "heavy" process when a quick little chat might be able to take care of it all.
(BTW, since the Wikipedia:Feedback request service has been broken for weeks, I'm not sure that starting an RFC is a particularly effective way to get other people involved in a discussion right now. If there are any RFCs that particularly interest you, I recommend looking at Wikipedia:Requests for comment#Publicizing an RfC.) WhatamIdoing (talk) 07:19, 4 February 2024 (UTC)[reply]
I specifically wrote above except for proposed policy/sitewide changes. I am well aware that in those cases, it is perfectly acceptable to just go for it, but in most cases, it is not appropriate for editors to jump the gun and treat RfCs as a solution to everything. I say that because many times when I see an RfC pop up, there has only been a preceding one-day-old discussion with two participants and three comments. Also, if editors wish to solicit feedback because they have no realistic hope of getting responses otherwise, an RfC is not appropriate; they should either be BOLD, try WP:3O, or ask a WikiProject. InfiniteNexus (talk) 07:52, 4 February 2024 (UTC)[reply]
It's not always possible. Look at Wikipedia talk:Independent sources/Archive 1#What is an independent source?, which is an RFC I started in 2016. I needed information before editing any further, so I couldn't be bold; there was no dispute or even anyone else talking to me, so 3O is irrelevant; there's no WikiProject to ask. Now what? WhatamIdoing (talk) 23:01, 7 February 2024 (UTC)[reply]
Are you saying that was an RfC? Because it sure doesn't look like it. What I would have done, and looks like what you ended up doing, was leave a message on a relevant project-namespace page, such as Wikipedia talk:Independent sources. No reply from anyone? Leave messages elsewhere, like relevant policy pages. Or, as a last resort, a Village pump. An RfC would have definitely been not appropriate in that scenario. InfiniteNexus (talk) 07:19, 12 February 2024 (UTC)[reply]
Yes, it was an RFC; you can see the RFC tag in the page history.
I'm not sure why you think that an RFC is an inappropriate thing to do when an editor is "requesting" actual "comments". WhatamIdoing (talk) 00:16, 13 February 2024 (UTC)[reply]
Example: Talk:List of highest-grossing live-action/animated films#RFC on what the criteria for being on this list is. --Redrose64 🌹 (talk) 22:54, 6 February 2024 (UTC)[reply]
Yeah, this happens a lot. InfiniteNexus (talk) 03:48, 7 February 2024 (UTC)[reply]
Perhaps something stronger like: Editors are expected to discuss the matter with any other parties on the related talk page. Make a reasonable attempt to resolve issues prior to starting an RfC. --GoneIn60 (talk) 12:43, 12 February 2024 (UTC)[reply]
I've mocked up the following to replace the text before the bulleted list at WP:RFCBEFORE:

RfCs are time-consuming, high-profile, and only used as a last resort when all other means have failed to reach a consensus. Editors must thoroughly discuss a matter on a talk page before initiating an RfC, except for policy or community-wide proposals. If a discussion has not lasted for a significant period of time and received input from multiple editors, it has not fully run its course and an RfC is premature. Always try to reach a consensus through normal discussion first, and then consider the following options before deciding to start an RfC:

I would also like to add "if an RfC is initiated prematurely without adequate prior discussion, it will be speedily closed", but that doesn't describe the current practice, so I don't know if others would support that. InfiniteNexus (talk) 23:58, 12 February 2024 (UTC)[reply]
Basically, I don't think this is true. This isn't how RFC works. More importantly, this isn't how humans work. Sometimes it's not appropriate to wait "for a significant period of time" before starting an RFC, because you're letting a serious problem get worse while you wait for the inevitable. Sometimes the main problem is that you have been unable to get that "input from multiple editors" (or at least from more than two others). Sometimes you look at a problem and realize that what's needed is to talk to the broader community instead of chatting with the fanboys who hang out on that particular talk page. Sometimes, in fact, what we need is to get the RFC started as soon as possible.
If you wanted a rule that I think would reflect reality, it would probably say something like "Every editor is entitled to screw up one RFC a year. If you make a habit of it, though, someone will come talk to you, and there's a teeny tiny chance that you'll end up with a TBAN." WhatamIdoing (talk) 00:27, 13 February 2024 (UTC)[reply]
All of your "sometimes" scenarios can be answered with this: WP:IAR. If there is a situation where a special exception is warranted, then ignore RFCBEFORE. But in the vast majority of cases, it is not appropriate for an editor to disagree with another editor, complain about it on the talk page, receive a response they don't like, and then jump straight to an RfC. Or, using the RfC Redrose64 linked as an example, have a question about an article and jump straight to an RfC rather than making a regular post or asking a WikiProject/Village pump (which is what should have happened). InfiniteNexus (talk) 03:54, 13 February 2024 (UTC)[reply]
The stronger the wording, the harder it is to get people (especially newer editors) to accept IAR. WhatamIdoing (talk) 01:16, 27 February 2024 (UTC)[reply]
Does anybody else have any thoughts on this proposed wording? InfiniteNexus (talk) 19:34, 27 February 2024 (UTC)[reply]

RfC for using Module:Sports_table for Rugby Union tables

Hi, I was going to open an RfC to get community input on using Module:Sports table with the rugby style for Rugby Union tables, but thought I should check here first. I started a thread at WikiProject Rugby, but got limited response, with a few editors expressing a desire for "sports table" and one editor disagreeing. Should I open an RfC, or do I already have enough input to decide the issue with the editors who have already commented. I don't want to waste time with an RfC if there is no reason for one. Thank you. Frietjes (talk) 00:18, 27 February 2024 (UTC)[reply]

@Frietjes, the conversation there suggests that the problem is primarily with one user's behavior, and that you should try ANI first. However, I understand that you might be reluctant to approach that noticeboard without a quick and easy way for busy folks at ANI to determine what the consensus was.
To my way of thinking, the bottom line is that you have a dispute (even if you think it shouldn't be happening), and you therefore need Wikipedia:Dispute resolution (or which an RFC is a valid and relevant option). Have you thought about how you'd like to word the RFC question? For example, about a single page, a small group, or in general? WhatamIdoing (talk) 01:14, 27 February 2024 (UTC)[reply]

Is RfC necessary here?

Is RfCs for this discussion? ☆SuperNinja2☆ 17:33, 27 February 2024 (UTC)[reply]

  • Not at this stage. It's a dispute between two editors and you've only just asked for a third opinion.—S Marshall T/C 17:56, 27 February 2024 (UTC)[reply]
User:S Marshall, I'm sorry, I fixed the link, I meant about this discussion. ☆SuperNinja2☆ 19:25, 27 February 2024 (UTC)[reply]
There are actually two questions there:
  • Should we have a unified symbol for Islam that is used on all relevant pages/templates across Wikipedia?
  • If so, should that unified symbol be the Star and crescent symbol, or should it be the Allah word in Arabic script, or something else (e.g., the Shahada)?
I suggest that you limit the first to content spaces (e.g., articles and portals, but not Wikipedia:WikiProject Islam). WhatamIdoing (talk) 19:51, 27 February 2024 (UTC)[reply]

Text added to RFCNOT

I've added the following text to WP:RFCNOT, posting it here for transparency. I believe it accurately describes current practice, and clarifies what that section was originally intended for:

Ordinarily, the types of routine discussions below have their own processes which should be followed. In cases where the normal process has failed to produce a consensus, has been especially contentious, or may have a widespread impact, it might be suited for an RfC to attract wider input. RfC tags should also not be added to a discussion that is already taking place in one of these venues.

Editors should note that filing an RfC without first attempting to use the routine processes, or as an attempt to subvert a consensus they don't like, might be seen as gaming the system. Similarly, attempts to force an RfC to be shut down early (or persuade the creator to withdraw) without strong evidence that it is invalid or defective is also strongly discouraged, and can be seen as disruptive.

The WordsmithTalk to me 19:15, 27 February 2024 (UTC)[reply]

This seems like a lot of words to be adding. The more words we put on the page, the less people will read. What problem are you trying to solve? WhatamIdoing (talk) 19:52, 27 February 2024 (UTC)[reply]
The issue that prompted this was the absolute mess over the legitimacy of an RfC for Wikipedia:Requests for comment/Capitalization of NFL draft article titles, as well as the close challenge at WP:AN#Close review of Wikipedia:Requests for comment/Capitalization of NFL draft article titles. The WordsmithTalk to me 20:03, 27 February 2024 (UTC)[reply]
I think the sense is correct. If no one beats me to it, I'll get the chance to revise it to say the same thing in about half as many words tomorrow.—S Marshall T/C 20:46, 27 February 2024 (UTC)[reply]
Thanks. I think it needs to be much shorter, but I think there is some value in saying that RFCs aren't actually banned from these discussions. (Our original point was more like "Look, there's a purpose-built process ideally suited for your routine WP:RM"; the idea that editors are banned from using RFCs when they really need widespread input from the community has never cross my mind.)
@The Wordsmith, thank you for being willing to read through 1.8 tomats of text to summarize that discussion. WhatamIdoing (talk) 22:54, 27 February 2024 (UTC)[reply]
I'm partial to 0.39 EEngs as a measurement of discussion page size. But yes, the original thread that created WP:RFCNOT was a little different from the text that ended up being written, so I'm trying to clarify. The WordsmithTalk to me 23:23, 27 February 2024 (UTC)[reply]
I've reverted the good faith addition until language is decided, it seems the explanation which was added is outside the bounds of the RfC closes as well as saying that other requirements need to be fulfilled (remember, the RfC was undertaken after one 2023 RM at NFL Draft that ended as no-consensus with no move review following). So we can jump from "no consensus" anywhere straight to an RfC which, without the requirement of notifying the pages, would move titles up-to-now reserved for 1) an RM, then 2) a move review. In the newest case, scores of unnotified-but-then-changed pages occurred without an RM or a move review of the 2023 RM. Seems like any added language should be worked out before the wording is included and not before or during a discussion. Randy Kryn (talk) 23:32, 27 February 2024 (UTC)[reply]
So we can jump from "no consensus" anywhere straight to an RfC: Yes, that's how RFCs work. If you can't get consensus with a local discussion, then start an RFC and see if adding some uninvolved editors would help.
An Appeal to consequences (i.e., that if editors are able to reach a consensus, some pages will get moved) is kind of the point of finding consensus, no? WhatamIdoing (talk) 00:24, 28 February 2024 (UTC)[reply]

It's out my hands. But, I think any changes made here, that (even remotely) suggests an RFC can overturn or bypass an RM, would render the RM process ineffective. GoodDay (talk) 23:54, 27 February 2024 (UTC)[reply]

I don't think that's either true or intended. I don't think that editors should be banned from adding an RFC tag in addition to following the RM discussion.
Also, it'd be self-contradictory to say that editors can use the RFC process to change policies and guidelines, including the Wikipedia:Article titles policy and any of the naming convention guidelines – and thus set in motion a change to the titles of thousands of pages – but they can't use an RFC to discuss changing page titles, because changing page titles is exclusively WP:OWNED by the RM process. There are rare circumstances in which doing both may be appropriate.
In the meantime, I note that WP:RM says "Occasionally the discussions for significant multi-move requests may be hosted on WikiProject talk pages or other pages in Project namespace." Wikipedia:Requests for comment/Capitalization of NFL draft article titles certainly counts as "other pages in Project namespace". WhatamIdoing (talk) 00:21, 28 February 2024 (UTC)[reply]
I haven't checked the history. Was the NFL Draft RM result (held in 2023) challenged at WP:AN? GoodDay (talk) 00:26, 28 February 2024 (UTC)[reply]
I doubt that it's worth you checking, because it doesn't matter. If a prior discussion (of any kind, on any page, using any process) didn't reach consensus, or if any editor believes that consensus has changed since then, then any editor is entitled to start a new discussion. Neither RFCs nor RMs result in binding decisions (except in those rare occasions when ArbCom puts a temporary moratorium on re-discussing it). WhatamIdoing (talk) 00:46, 28 February 2024 (UTC)[reply]
Either an RM review should occur, if one opposes an RM result or (after at least twelve months) another RM on the same page should be opened. Otherwise, the RM process is potentially rendered ineffective or irrelevant. GoodDay (talk) 00:53, 28 February 2024 (UTC)[reply]
Where do you get the "after at least twelve months" bit? I've never seen such a rule.
Also, when was the last time you saw RM used for a decision that could affect more than a hundred articles? WhatamIdoing (talk) 02:43, 28 February 2024 (UTC)[reply]
RMs should occur with as few as possible pages involved. PS - We're not going to agree on this & circular discussions lead to nowhere. So, best to let other give their input. GoodDay (talk) 03:01, 28 February 2024 (UTC)[reply]
I agree that RM is best suited for small numbers of pages. The obvious obverse of that believe is that I agree that RM is not best suited for discussions affecting hundreds of pages. WhatamIdoing (talk) 03:31, 28 February 2024 (UTC)[reply]
Belt-and-suspenders is not an improvement. RFCNOT processes like requested moves are formalized and publicized, not just random local talk page threads. They have well-known centralized noticeboards (i.e. WP:RM, WP:AFD, WP:RFD, etc. themselves), automated article alerts with subscriptions by just about every WikiProject, and banners visible on affected pages. RFC tagging on top of this does not improve it; more is not better. Adumbrativus (talk) 01:43, 28 February 2024 (UTC)[reply]

PS - I've contacted WP:RM about this discussion. GoodDay (talk) 00:07, 28 February 2024 (UTC)[reply]

Thank you. WhatamIdoing (talk) 00:21, 28 February 2024 (UTC)[reply]

AFD, RFD, RM, and other RFCNOT processes are complementary to RfCs in their proper roles, not merely an overlapping pair of channels for litigation and relitigation. Centralized RfCs give generalized guidance on a broad question, and other processes decide ultimate outcomes of articles taking individualized circumstances into account.

No-consensus and contentiousness are not sufficient to turn the ordinary into the extraordinary. No consensus is a normal outcome of AFD, RFD, RM, and other discussions, not a failure. Controversy is a dime a dozen. Widespread impact, beyond the practical limits of RFCNOT's structured processes, is required. At a minimum, a question is broad enough only if a large bundled discussion about the same question is impossible due to WP:TRAINWRECK, yet one-by-one discussions would flood the venue. (WP:LUGSTUBS is an example.) It's an and between all these conditions, not an or. Adumbrativus (talk) 01:43, 28 February 2024 (UTC)[reply]

I don't think that trainwrecks are the only possibility. Consider:
  • You can have an RFC to change the WP:LOWERCASE policy to give an example of NFL drafts as an example of correct use of your preferred case. Result: Potentially, several hundred pages get moved.
  • But allegedly: You can't have an RFC to decide to move those same pages, unless some of them would get moved and others wouldn't (a "trainwreck")?
That doesn't make any sense. I suggest that when you are already doing something extraordinary (discussing whether to change the capitalization on hundreds of pages at once), then using an extraordinary process is permissible. A move that could affect hundreds of pages, and that has already been discussed multiple times in the past, is a good candidate for an RFC that got comments from 50 editors, rather than the five or ten that RM normally elicits. WhatamIdoing (talk) 02:41, 28 February 2024 (UTC)[reply]
The 2023 2024 NFL Draft discussion had approx. 25 participants (on an unscientific count), was closed as no consensus, and no move review was held. Before that there was a much less attended 2016 RM at a little-read page. Those were the only two "multiple times in the past", and the no consensus RM was not poorly attended. None of your arguments take WP:RFCNOT into account, which has been the determinative wording. It directs that the issue could hold a third RM but that the titling could not be done by an RfC. Yet it was, two closers have moved the goalposts (to coin a phrase), and if WP:RFCNOT's language is allowed to be changed per those discussions then it is a WP:IAR decision. So let's call it what it is and ascertain if this entire episode improves and maintains Wikipedia, the criteria for an IAR. Randy Kryn (talk) 03:53, 28 February 2024 (UTC)[reply]
Talk:2024 NFL draft#Requested move 27 April 2023 has 82 comments from 24 accounts, including the closing summary. If you turn on "Discussion tools" in Special:Preferences#mw-prefsection-betafeatures then it'll count everyone for you.  :-)
We are talking about what RFCNOT ought to say. It is therefore not especially helpful to treat the current wording of RFCNOT as some sort of statute that needs to be carefully adhered to. The real policy (and this page isn't even a guideline) is what editors actually do and accept, not what words we wrote down in an attempt to describe our usual practices and best advice. WhatamIdoing (talk) 05:13, 28 February 2024 (UTC)[reply]

The recent NFL draft RfC was an exception and not the norm. Editors should not get WP:POINTY and start RfCing any and every failed RM. The question is whether it's worthwhile to update this WP:INFOPAGE at WP:RFCNOT and provide future guidance for other similar—but rare—cases? Or do we leave it to common sense for the community to apply the existing policies WP:NOTBURO amd WP:CONSENSUS § Consensus-building, as was the consensus at this recent RfC?—Bagumba (talk) 04:39, 28 February 2024 (UTC)[reply]

I agree: Editors should not...start RfCing any and every failed RM – or even 10% of them. WhatamIdoing (talk) 05:16, 28 February 2024 (UTC)[reply]

Redraft

RFCs don't replace other community processes. If there's a relevant specialist process, such as AfD, use that instead. A table of specialist processes is set out below.

On rare occasions, when Wikipedians reach consensus that a specialist process isn't the right approach, they might decide to use RFC instead. When this happens, open a full RFC in the normal way. Please do not add RFC tags to a pre-existing discussion that uses a different process.

How's that?—S Marshall T/C 11:00, 28 February 2024 (UTC)[reply]
I'm not so sure on the requirement to first have consensus to hold an RfC to establish consensus; that doesn't seem to be how things typically happen. RfCs generally have a presumption of legitimacy, unless there's a strong consensus otherwise. The WordsmithTalk to me 14:33, 28 February 2024 (UTC)[reply]
I intended to prevent a lone editor from deciding to start a RFC instead of an RM.—S Marshall T/C 16:21, 28 February 2024 (UTC)[reply]
I think The Wordsmith is right. We don't generally have a problem with this, so creating rules about it is WP:CREEPY, and it may obstruct reasonable solutions.
I'm also not sure that we should prohibit RFC tags in combination. This is rare, but I think it happens about once a year or so, and it's not always a bad idea. For example, if a question can't be resolved during a GA review, it might be suitable for an RFC, and it might make more sense to "physically" place it in the GA subpage. Similarly, there's an RFC at Wikipedia talk:Featured lists right now. It's simultaneously "about" a single page, and 367 pages, and FL criteria. It would be easy for an editor to lodge procedural objections by claiming it's "using a different process". Even though (in this particular instance) it's not intended to be covered (because this is a pre-nomination discussion, rather than a discussion while a nom is pending), this introduces the opportunity to wikilawyer over whether or not the discussion can be advertised. At best, it will be a distraction; at worst, we'll have to first find consensus to determine whether the discussion is allowed to happen.
(Also, "full RFC" may be confusing, by making people wonder what a "partial" one is.) WhatamIdoing (talk) 18:14, 28 February 2024 (UTC)[reply]
Maybe it could be shortened to On rare occasions, a specialist process isn't the right approach and editors might decide to use RFC instead. When this happens, open an RFC in the normal way. I do think keeping the last sentence about not adding tags to an existing discussion is good, that's within the spirit of the original reason RFCNOT was written. In your GA review example, an RFC might be better off on the article talkpage or subpage rather than directly added to the GAR itself. The WordsmithTalk to me 18:33, 28 February 2024 (UTC)[reply]
Whether to add an RFC tag to an existing discussion vs to start a new section is something that should be decided case-by-case.
I wonder whether it would be sufficient to just say "On rare occasions, a specialist process isn't the right approach and editors might decide to start an RFC". WhatamIdoing (talk) 19:02, 28 February 2024 (UTC)[reply]
IMHO, it's regrettable that the community has chosen to accept the move of NFL Draft (and related pages) to NFL draft (and related pages) via RFC, bypassing the RM process & overturning the last RM result on that page. But they have & so be it. My only concern here, is that it doesn't become a precedent (i.e. using an RFC to bypass the RM process or overturn an RM result) for other editors to follow. GoodDay (talk) 16:18, 28 February 2024 (UTC)[reply]
Meh… I don’t see much difference between RM and RFC… the RM process is useful, but ultimately it is simply a version of RFC specifically focused on page moves. Same with AFD… that is just a version of RFC specifically focused on whether to delete. The point is to have community input on the question. What bureaucracy we use to ASK the question is secondary. Blueboar (talk) 17:06, 28 February 2024 (UTC)[reply]
Agreed with this. JoelleJay (talk) 06:09, 29 February 2024 (UTC)[reply]
  • Tightened:

RFCs don't replace other community processes. Where there's a relevant specialist process, such as AfD, use that instead. A table of specialist processes is set out below.

Occasionally, a specialist process isn't the right approach and editors decide to use RFC. When this happens, start a RFC in the normal way. Please do not add RFC tags to a pre-existing discussion that uses a different process.

Better?—S Marshall T/C 19:05, 28 February 2024 (UTC)[reply]
Looks good to me. The WordsmithTalk to me 20:03, 28 February 2024 (UTC)[reply]
I'm concerned that this may be (mis)understood as encouraging discussion forks. It would be better to have an RM with an RFC tag inside it (or the other way around) than to have an RM in one section and an RFC in the next section – or, worse, on a different page. WhatamIdoing (talk) 02:39, 29 February 2024 (UTC)[reply]
I'm concerned that this may be (mis)understood as encouraging discussion fork: The WP:FORUMSHOP policy already discourages simulataneous discussions on the same topic. —Bagumba (talk) 04:00, 29 February 2024 (UTC)[reply]
See also Wikipedia:Content forks/Internal#Discussion forks.
The problem is that if WP:RFC directly tells editors that when they "decide to use RFC", they should "start an RFC in the normal way" and definitely "do not add RFC tags to a pre-existing discussion", some of them are going to think that the official directions are telling them that they really ought to abandon the existing discussion in favor of a brand-new RFC, no matter what other pages may or may not say about that behavior as a general practice for everyday, non-RFC-related editing. WhatamIdoing (talk) 04:24, 29 February 2024 (UTC)[reply]
WP:DISCUSSFORK says:

It is sometimes useful to relocate a discussion to a more appropriate page; this is usually effectively done by posting a pointer to the new discussion from the old one, though if discussion continues in the original location, it may be appropriate to close it...

WP:RFCBEFORE expects that other options have already been tried:

Editors should try to resolve their issues before starting an RfC.

They shouldn't "abandon" an ongoing discussion, but an RfC is fair if it has reached an impasse. —Bagumba (talk) 05:06, 29 February 2024 (UTC)[reply]
Right, and the question here is whether, if you start with (e.g.):
==Requested move: Foo to bar==
and you decide that an RFC would be helpful, should you choose
===RFC about how to make this consistent across hundreds of pages=== (as part of the original ==Requested move: Foo to bar==)
or
==RFC about hundreds of article titles== (separated, perhaps on a different page).
I believe that "Please do not add RFC tags to a pre-existing discussion that uses a different process" will be interpreted (especially by, but not exclusively by, editors who believe that their side will "lose") as "You aren't allowed to have an RFC as part of the original discussion". Of course, the reason the present discussion exists is because some editors were upset because someone started a separate discussion at the Village Pump. The net result would be that editors would believe you can have an RFC neither as part of the original discussion, nor separated from it. This is not a desirable outcome. The rules should never be written in ways that would lead editors to believe that any content-related subject is excluded from the RFC advertising process. WhatamIdoing (talk) 16:29, 29 February 2024 (UTC)[reply]
The rules should never be written in ways that would lead editors to believe that any content-related subject is excluded from the RFC advertising process This is the issue that landed us here in the first place. I agree that editors might interpret this language like that. Maybe changing it to inside a pre-existing discussion would clarify that. The WordsmithTalk to me 16:42, 29 February 2024 (UTC)[reply]
Do you want to ban editors from starting a ===RFC about how to make this consistent across hundreds of pages=== (as part of the original ==Requested move: Foo to bar==)? We could, but we can predict that it will produce complaints about FORUMSHOPPING, especially when the separated, context-hiding subsequent RFC is started by someone who thinks he's "losing" the original discussion. WhatamIdoing (talk) 17:03, 29 February 2024 (UTC)[reply]
RM generally stays open for a week or so, RfC usually for 30 days. When this section was originally created, it was because a few editors misunderstood and tried adding an RfC inside of an AFD, which disrupts the process. I don't think we have the power here to ban editors from doing anything, we're just trying to describe the current practice as accurately as we can. The WordsmithTalk to me 17:32, 29 February 2024 (UTC)[reply]

Another redraft

RFCs consume a lot of volunteer time. Where there's a specialist community process, try to use that instead. A table of specialist processes is set out below.

Rarely, a specialist process isn't the right approach and editors decide to use RFC. When this happens, start a RFC in the normal way. It's seldom, but not never, a good idea to add RFC tags to a discussion that uses a different process.

  • How's this?—S Marshall T/C 17:58, 29 February 2024 (UTC)[reply]
    As the person who first responded at Wikipedia talk:Requests for comment/Archive 16#Specifying that RfCs should not be listed on AfDs - and indeed, the person who made the revert mentioned in the original post there, I'd like to say that the original point of RFCNOT was not to discourage but to forbid the use of RfCs where an established process exists. So I oppose the text seldom, but not. --Redrose64 🌹 (talk) 21:57, 29 February 2024 (UTC)[reply]
    Oh, okay. I can see no way to reconcile your position with WAID's then.  :(—S Marshall T/C 23:22, 29 February 2024 (UTC)[reply]
    I wouldn't want to see an RFC inside an AFD page, either. But if it's a discussion that you could reasonably have at a Village pump or noticeboard (e.g., "Do you think I have enough sources to turn this {{r with possibilities}} redirect into a decent article?" or "I'm thinking about re-organizing some articles to align with the division of this multinational company. This could involve re-structuring the category tree, and...") then I think it should be possible to have an RFC on it. WhatamIdoing (talk) 00:09, 1 March 2024 (UTC)[reply]
    There may well be something I'm missing. You seem to be in favour of allowing RFCs in RMs, but disallowing them in AfD. Have I understood you right?—S Marshall T/C 00:27, 1 March 2024 (UTC)[reply]
    Yes, I think so. In practice, an individual AFD won't expand to dozens or hundreds of articles. An RM could (and has done). An RM, like an RFC, is a normal, consensus-driven talk-page discussion with some additional mechanisms to support advertising and summarizing the discussion. The results are not constrained to specific options. An RFC should be a possibility in any ordinary, consensus-driven discussion.
    Other processes (e.g., peer review) are not. Peer review is kind of "one person's opinion"; their comments might inspire an RFC, but "Please change Joe's mind because I don't like his advice" isn't really a sensible RFC question . AFDs aren't normal talk-page discussions; the result will be keep/merge/delete. The other XFDs have more scope for creative compromise as a result of discussion, but we haven't needed RFC for them, and when the scope expands to an RFC-level question, we usually close the XFD and start a new discussion (e.g., at the Village pump) instead. WhatamIdoing (talk) 02:57, 1 March 2024 (UTC)[reply]
  • I think the main situations we would permit RfCs in place of specialized processes are when a proposal affects a large number of pages--including future pages in some category--but isn't intended to add to/change the text of P&Gs per se (such as when establishing a convention for a particular topic), when the normal processes have repeatedly resulted in no consensus (and consensus for something is desired), and when it's clear broader community input is needed to reach a P&G-compliant outcome. There's plenty of precedent for each of these scenarios, so I prefer this wording acknowledging that our recommendation to use specialized processes isn't absolute. JoelleJay (talk) 03:24, 1 March 2024 (UTC)[reply]
    Yes. A discussion about renaming multiple pages according to a common theme isn't really an RM matter (and I've never seen one that was carried out as an RM), it's a matter of agreeing a naming convention. Once that is agreed (which may well be an RfC matter), you then proceed to moving pages within its scope but whose names don't fit the agreed convention. --Redrose64 🌹 (talk) 10:28, 3 March 2024 (UTC)[reply]
    Another thing that led up to the original RFCNOT proposal was the use of {{rfc}} as an alternative to {{fyi}} or {{subst:please see}} - as a notice placed on another page directing people to the real discussion that was occurring elsewhere. On that note, this RfC at VPT must be the oddest RfC that I've seen in some years. --Redrose64 🌹 (talk) 09:12, 5 March 2024 (UTC)[reply]
    Well, he's requesting comments, so I guess it's a request for comments. ¯\_(ツ)_/¯ WhatamIdoing (talk) 17:43, 5 March 2024 (UTC)[reply]
    It's one of those things where we clearly didn't intend for it to be used that way, but reading the text plainly without the Wiki-cultural context I can see how someone would interpret it that way (much like this current thread). The WordsmithTalk to me 18:03, 5 March 2024 (UTC)[reply]
    The original intent probably did include this (soliciting comments on a technical question). A similar request for technical feedback was posted a month after RFC was created (i.e., in 2004). WhatamIdoing (talk) 19:20, 5 March 2024 (UTC)[reply]

Why is nobody participating in this RfC

Why is nobody participating in this RfC? Is something wrong with it? ☆SuperNinja2☆ 11:03, 10 March 2024 (UTC)[reply]

Generally, an RfC held at a WikiProject forum isn't ideal - it lends itself to lower participation and a WP:LOCALCONSENSUS. A Village Pump might be better for that in the future - although it's not too late to move it now. BilledMammal (talk) 11:46, 10 March 2024 (UTC)[reply]
I don't think that any of that is true. A local consensus is what happens when a group of editors declare "their" articles exempt from some community-wide rule. RFCs are the antidote to a local consensus, because an RFC advertises the local discussion to the whole community. People getting those messages don't care (or necessarily even notice) what page it's on.
@BilledMammal, this all happened about a decade before your first edit, but the problems with local consensus came to a head in 2009 and early 2010. We had an RFC that ultimately resulted in both clarifying the Consensus policy and creating WP:ADVICEPAGE. The key discussion that affirmed the undesirability of small groups of editors exempting their content from the general rules was Wikipedia talk:WikiProject Composers/Infoboxes RfC – an RFC that started on the WikiProject's talk page.
@Super ninja2, have you followed the steps for publicizing the discussion at Wikipedia:Requests for comment#Publicizing an RfC? WhatamIdoing (talk) 19:53, 10 March 2024 (UTC)[reply]
I'm guessing editors are staying away because it's a Muslim issue and religious crazies are unappealing to everyone else. Why would I posit my opinion in that RfC when I see you and others arguing about it? I only provide my 2 cents when the bar to entry is zero. Chris Troutman (talk) 20:00, 10 March 2024 (UTC)[reply]

Would this be appropriate?

The discussion at Talk:Vasa (ship)#rfc_F2210DD now has closely related discussion going on at Wikipedia talk:Citing sources#Splitting notes is an arbitrary Wikipedia-made standard with unknown consequences for readers. The editor who made that post has not mentioned the Vasa (ship) RfC. I am not clear whether or not it would be appropriate to mention the RfC at the discussion at the Citing sources talk page. With the growing body of support at Citing sources for my own point of view, I wish to avoid any suggestion of canvassing or other improper behaviour. Yet it seems to be unhelpful for the discussion to be going on in two places. ThoughtIdRetired (talk) 19:49, 10 March 2024 (UTC)[reply]

We try very hard to avoid a WP:TALKFORK situation. The usual way to do this is to leave a brief note in both discussions to say something like "Editors interested in this might also be interested in the related discussion at [link]." If you are in an argument with someone (in either location), then you may prefer the {{please see}} template (which is "neutral" to the point of being uninformative); if accusations of WP:BLUDGEON have already appeared, then ping me and I'll post them for you. WhatamIdoing (talk) 19:59, 10 March 2024 (UTC)[reply]