Wikipedia talk:RFC

☆ Save On Wikipedia ↗

Multi-faceted RfC - any advice?

I am hoping to creating an RfC to build consensus for how band timelines are organized. Because there are many different aspects to align on (band member order, bar colors, inclusion/exclusion of touring members, etc. etc.), prior discussions (1, 2) have lost focus and not resulted in much.

To avoid this, I'm contemplating two approaches:

  1. Using a set of RfCs - one for each aspect.
  2. Starting with a proposal, based on prior conversations, of what I think consensus will be.

Has anyone done something like this before? Any sage words of wisdom to share? WidgetKid Converse 04:37, 24 May 2026 (UTC)

First draft here: User:Widgetkid/sandbox/Band timeline RFC. WidgetKid Converse 06:07, 24 May 2026 (UTC)
  • Procedural recommendation: That kind of complex change often benefits from finding a few partners. Grab a friend or five and see whether your small group can agree on a recommendation for each of several areas. Then try it out on some articles and see how well it works. That will help you figure out things like whether your suggested instrument order (Vocals – Guitar – Bass guitar – Keys – Drums) would work for the Miles Davis Quintet (trumpet – saxophone – piano – double bass – drums) and how you would handle bands with large numbers of past members, such as The Dillards#Past members.
  • General concept: You're assuming that there needs to be a single approach applied to all bands. That may not be a valid assumption. People might actually prefer using different styles for different bands. Not really wanting most articles to be the same may be why previous discussions have fizzled out. Consider, too, whether we need "rules", or if something like a help page would be sufficient. It would be normal to add such advice to a page such as Wikipedia:WikiProject Musicians/Article guidance. Doing so requires the acquiescence of the WikiProject, but it does not require community-wide support (and therefore you don't need an RFC).
  • Draft: If you decide to have an RFC, then you need to add some examples. People responding to RFCs aren't going to know that you're talking about things like DragonForce#Timeline, so you need to show them the equivalent of before-and-after pictures. It might be best to take an RFC (if any) in two stages: Ask one key question, get the answer, and then ask one/two/the rest the next month in a separate RFC. (Also, you're not actually making a WP:PROPOSAL for a {{guideline}}.)
WhatamIdoing (talk) 20:58, 24 May 2026 (UTC)
Thank you, @WhatamIdoing. This is very helpful!
I was thinking of this as documenting a common practice instead of blazing any real new trails. (WP:PROPOSAL: Most commonly, new policies or guidelines document established practices, rather than proposing a change to what experienced editors already choose to do.) I have a slew of FA/GA examples, but good call on putting one with the RFC to illustrate what's being discussed:
My sense of prior discussions is that most everyone agrees there should be some kind of standard, but then discussion gets caught-up in the minutia and stalled. I was hoping to avoid that by intentionally not including every single aspect, but just the core ones for which there already appears to be consensus, both in discussion and common practices. It feels like the perfect has been the enemy of the good here.
Wikipedia:WikiProject Musicians/Article guidance definitely seems like the right home for this sort of info. I was thinking about putting the RFC on it's talk page and advertising it to other relevant projects. Maybe an RFC/set of RFCs isn't the way to go. Do I just document the approach, seek feedback on the talk page, and then add it once there's some consensus? Or boldly add it straight-away (doesn't feel right, but I'm still very much learning here ). WidgetKid Converse 19:13, 25 May 2026 (UTC)
Wikipedia:WikiProject Musicians can put whatever they want on that page (within reason; copyvios would still result in {{db-copyvio}}). They don't need an RFC to give them permission to provide their advice there.
If you're a regular participant in that group, then you probably know whether the page is more contested or forgotten or somewhere in between. If there is any local protocol, you should follow it. I'm not familiar with that group, so I can only tell you that for most WikiProjects, the ordinary procedure is: (a) boldly add it straight into the page, and (b) promptly drop a note on the group's main talk page to say something llike "Hey, guys, I'm working on this and would love your feedback on my bold addition to Wikipedia:WikiProject Musicians/Article guidance#Timelines." And then expect either bold improvements, or someone saying thanks. WhatamIdoing (talk) 03:14, 26 May 2026 (UTC)

Here's a less-blues-rock-and-guitar-pop-centric instrument table, which needs checking by someone who understands the accessibility of RGB colour blindness.

Instrument colours table
Instruments Vocals Strings Brass Woodwind Percussion
Treble, e.g. Soprano  Violin  Trumpet  Piccolo  
Alto, e.g. Baritone  Guitar  Trombone  Flute  (Generally)  
Bass, e.g. Bass  Bass guitar  Tuba  Bassoon  

Hope this helps—S Marshall T/C 16:59, 25 May 2026 (UTC)

That's pretty. I notice that piano isn't in there. Nominally, piano is a percussion instrument (the hammer strikes the string), but I think that a fifth category might be appropriate. WhatamIdoing (talk) 18:16, 25 May 2026 (UTC)

Such percussion could also fit xylophones, glockenspiels, bells, etc. The treble/alto/bass distinction isn't needed. Let's make it mauve.

Instrument colours table
Instruments Vocals Strings Brass Woodwind Keyboard Percussion
Treble, e.g. Soprano  Violin  Trumpet  Piccolo  
Alto, e.g. Baritone  Guitar  Trombone  Flute  (Generally)(Generally)  
Bass, e.g. Bass  Bass guitar  Tuba  Bassoon  

There you go.—S Marshall T/C 19:38, 25 May 2026 (UTC)

@S Marshall, do you have some example articles where this color scheme is already in use? I am not very familiar with non-pop/rock articles' member timelines. Thanks! WidgetKid Converse 19:45, 25 May 2026 (UTC)
No, I'm afraid that I just made it up in response to WhatamIdoing and the Miles Davis Quintet. It's not in use.—S Marshall T/C 20:26, 25 May 2026 (UTC)

Complex RFC draft looking for advice

Please see Wikipedia:Administrator elections/May 2026/RFC workshop and give your advice on the many sub-questions. WhatamIdoing (talk) 01:57, 8 June 2026 (UTC)

Advice requested: clarifying implementation questions from a closed RfC

I am seeking advice about process regarding the closed Wikipedia:Requests for comment/Archive.is RFC 5 (the NOMOREARCHIVETODAY RfC).

There’s pushback on most of the proposals I’ve made to implement the consensus. Specifically, there appears to be disagreement over whether the consensus to “remove” archive.today links contemplated deterministic implementation based on the presence of archive.today links themselves, or whether individual editorial review of each link was expected before any removal could occur.

I am not seeking to reopen the RfC or relitigate its outcome. Rather, I am looking for guidance on the appropriate venue and process for obtaining clarification when reasonable editors disagree about what a closed RfC authorized in practice.

Would the preferred approach be to:

  • ask for advice on the original RfC talk page;
  • seek input from the closer and/or participants in the original discussion;
  • continue the implementation discussion in the venue where the question arose; or
  • initiate a new RfC specifically addressing the implementation question?

Thanks! Dw31415 (talk) 16:42, 18 June 2026 (UTC)

p.s. The latest pushback came as I proposed a bot. I won’t link the discussion because I’m looking for process advice rather than trying to advertise the BFRA. A real challenge in this one is the large number of editors who were in the minority position of the RfC. Understandably, they oppose moves to implement the “removal” that was decided. Dw31415 (talk) 16:48, 18 June 2026 (UTC)
Does "whether editorial review of each link was expected before any removal could occur" mean some editors believe editorial review is expected to determine whether removal could occur, or just that review is expected for some other reason before the removal happens? And does "any removal" mean removal of the reviewed link or removal of any link? It makes a difference as to what kind of clarification is needed. Bryan Henderson (giraffedata) (talk) 15:28, 19 June 2026 (UTC)
Thanks for responding. There is opposition to removing links without replacing them. Or removing them now versus waiting months (or years) for replacement to occur. Maybe even some dispute about what removal means. Dw31415 (talk) 15:36, 19 June 2026 (UTC)
Let me ask you this: what makes you so confident that the archive will continue to serve Wikipedia for months and years to come? Do you know that the prices of equipment—including hard drives—have increased tenfold? They’ll simply wipe the Wikipedia dataset and sell the hard drives on eBay, and you’ll be to blame—those of you who clamored for the removal of harmful links. Don’t forget that the Archive pays for this every day, and from a financial standpoint, it’s in their interest to stop—especially since the situation here is such that it wasn’t them who cut costs, but Wikipedia itself, which loudly and publicly refused the free service and expressed its willingness to build and maintain its own. ~2026-35838-21 (talk) 21:55, 19 June 2026 (UTC)
Obviously, they’ll make the service more and more inconvenient until Wikipedia finally removes all the links. And if you keep putting up with it, and pretending not to get the hints—you’ll just end up seeing a 404 error one day. ~2026-35838-21 (talk) 22:03, 19 June 2026 (UTC)
I was reluctant to share the BFRA because I want to avoid forum shopping but it’s probably hard to respond without context so here it is Wikipedia:Bots/Requests for approval/CutlassBot Dw31415 (talk) 15:40, 19 June 2026 (UTC)
  • Definitely make sure to seek the closer's input here.—S Marshall T/C 16:00, 19 June 2026 (UTC)
    Voorts responded in the BFRA discussion. Should I add him here? Dw31415 (talk) 16:05, 19 June 2026 (UTC)
    Voorts’ comment Wikipedia:Bots/Requests for approval/CutlassBot#c-Voorts-20260616182000-Tazerdadog-20260616180500 Dw31415 (talk) 16:07, 19 June 2026 (UTC)
    And indeed my earlier comment would have pinged him, so we can be sure he knows.—S Marshall T/C 18:01, 19 June 2026 (UTC)
    Hi @Voorts, I created this thread to find ways to show BAG that there is sufficient consensus to proceed. Dw31415 (talk) 18:11, 19 June 2026 (UTC)
    I've shared my views in the BRFA thread. voorts (talk/contributions) 18:24, 19 June 2026 (UTC)
    Since the closer believes at least some of the current dispute is covered by the consensus of the RfC discussion, I think it would be valuable for the closer to update the closing summary with the specifics he has mentioned, like what preconditions to removing a link the consensus in the RfC discussion allowed for and how much of the sentence the modifier "as soon as practicable" is supposed to modify. Bryan Henderson (giraffedata) (talk) 21:04, 19 June 2026 (UTC)
    This is such a big project that I suspect another RFC (or other widely advertised discussion) will eventually be necessary. Ideally, I'd like to see us make some progress on things like adding maintenance tags before that happens. I think we're making progress at the BRFA discussion today. WhatamIdoing (talk) 04:02, 20 June 2026 (UTC)

Bad close at Wikipedia talk:WikiProject Classical music#RfC: amending project guidelines on infoboxes

I am very much concerned with the close done by Beland at this RFC. Not only do I not perceive there to be a clear consensus to endorse the proposed change, but I have serious concerns about the ethics of allowing RFCs to dictate a WikiProject's opinions. WikiProjects are organized groups of editor with collective editing interests. They are mini-organizations within the community that have a right to form opinions and collectively act on those opinions provided they are within the bounds of wider guidelines. The issue I see here is that external editors not members of that WikiProject chose to force a change in that WikiProject's editorial opinion in an area not conflicting with wider policy. That is tantamount to suppressing a minority view which violates WP:FREESPEECH policy. External editors don't have the right to suppress opposing opinions, which is what in effect this RFC close did. That is unethical. If the WikiProject wants to change their own guideline, they can do so internally with its active project members having an internal WP:CONSENSUS discussion. Non-members don't get a say in setting a WikiProject's guidelines because WikiProjects are organizations within wikipedia that have a right to their opinions. This would be like an employer coming in and telling a union what its policies are. It's not ethical. This gets down to a fundamental freedom of speech issue. WikiProjects as a group have protected speech.4meter4 (talk) 16:40, 19 June 2026 (UTC)

Have you raised your objections in Beland’s talk page? That’s the next step Dw31415 (talk) 16:58, 19 June 2026 (UTC)
I left a note on their talk page about this discussion at the time I posted here. I think this warrants a wider view though, because this issue could come up again at a future RFC. I think the RFC page itself could say outright that RFCs can't be used to change WikiProject guidelines or opinions because WikiProjects are protected under WP:FREESPEECH policy and have a right to make their own recommended guidelines providing they don't conflict with wider policy pages. Outside editors who are not project members shouldn't be allowed to come in and suppress the editorial viewpoints of wikiprojects they are not involved with.4meter4 (talk) 17:16, 19 June 2026 (UTC)
I suggest that you go read the "free speech" essay (not policy) that you just linked to. I do not think it says what you think it says. WhatamIdoing (talk) 17:22, 19 June 2026 (UTC)
A discussion is already happening at Wikipedia talk:WikiProject Classical music#Close clarification. BTW, you can't have a "WikiProject guideline", because the policy on WP:Guidelines does not accept the idea that there can be a guideline that belongs to a group of editors, rather than to the whole community. It's a {{WikiProject advice page}}. This classification both defends the group's right to share their opinion (within the usual limits that we would apply to an essay) and prevents the group from enforcing their opinion (because it's "just an essay").
@4meter4, you may be interested in seeing Wikipedia:WikiProject Council/Guide#Advice pages, but one interpretation of the proposal is a minor change:
Infoboxes are neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.
+
Infoboxes are neither required nor prohibited for any article. If there is a dispute over whether to include an infobox, which infobox to include, or which parts of the infobox to use, it should be resolved through discussion and consensus among the editors at each individual article.
It's not clear to me whether the main point of the RFC was to remove the rest of the paragraph, but I don't see any significant difference between these two versions. WhatamIdoing (talk) 17:20, 19 June 2026 (UTC)
Well advice page then. The semantics matter little here. The point is that outside editors don't get to change WikiProject Advice pages, and this was an abuse of RFC process. WikiProjects have a right to author their own advice pages. Note that WikiProject advice pages are totally not enforceable and are basically an essay space for WikiProjects. If an editor wants to change the advice page then they should join the wikiproject and get involved internally. If an advice page is supposed to represent the opinions of a group that advice page better reflect the actual opinions of the editors in that group. You don't get to dictate the official position of a WikiProject. Advice pages are supposed to be a measure of what the editors in that project think, not what editors outside the project think.4meter4 (talk) 17:28, 19 June 2026 (UTC)
And the OP for the RFC was banned by ArbCom last month over infoboxes, so there's an endless supply of problems with this particular RFC. You may have noticed that I made the same points myself during the RFC (though the OP wasn't banned at that point)
But there are circumstances in which an RFC would be welcomed by a WikiProject, or could be helpful. Additionally, just like some essays aren't acceptable to the community, some sorts of advice pages wouldn't be acceptable, and an RFC is one of the ways to address that. The end result is that I think we can't actually say in the RFC page itself that RFCs can't be used to change WikiProject pages, because they can be, under certain circumstances.
One thing you could do to defend the WikiProject against future incursions is to rename Wikipedia:WikiProject Classical music/Guidelines to something that doesn't use the word guidelines. Editors might be less interested in the contents of a page that doesn't use the same language as the Wikipedia:Policies and guidelines. WhatamIdoing (talk) 17:41, 19 June 2026 (UTC)
I'd be fine with "recommendations". Regardless, I stand by my standpoint that RFCs can't change WikiProject pages with the intent of viewpoint suppression. This was a clear case of a viewpoint suppression RFC. WP:FREESPEECH matters, and this RFC should have been closed rapidly as a BADRFC.4meter4 (talk) 17:47, 19 June 2026 (UTC)
You haven't read WP:FREESPEECH yet, have you? It's an essay explaining why the Wikipedia community can suppress your view any time we want without violating the US Constitution. WhatamIdoing (talk) 17:51, 19 June 2026 (UTC)
Lol. Got me there. It's been a while since I looked at that page. Then let's get down to basic fairness. If an advice page is supposed to relfect the viewpoints of the members of a given project, but the viewpoints expressed have been suppressed and forcibly changed is that fair? I don't think it is. Maybe you are ok with that, I'm not. If this were a policy page or an official guideline page have at it (everyone gets a say in those spaces), but in this case we have editors collectively forming an editorial opinion reflecting the viewpoint of a specifically defined group. I can't see how forcing that group to profess advice they didn't willingly agree to is ethically a good choice to foster a community that is compliant with the spirit of WP:5P4. 4meter4 (talk) 18:01, 19 June 2026 (UTC)
I believe that if you read my comments in the RFC ("Oppose on principle because a {{WikiProject advice}} page should be treated like a user essay, and that means that other editors shouldn't mess with it (but are free to write their own essays to disagree with it)"), you would see that I agree with you on that point.
But: Just because this one RFC looks like a misuse to me doesn't mean that all uses of RFCs are misuses. You are asking us to ban all RFCs because there was just one (1) problem.
(Also, I don't think that this is a case of "forcing that group to profess advice they didn't willingly agree to". Isn't the main concern removing words?) WhatamIdoing (talk) 19:09, 19 June 2026 (UTC)
Removal of words changes emphasis, tone, meaning, etc. That should be done by the members of the project. Regardless, I am asking for the RFC page to recognize its limits (or at least discourage its application) when it comes to altering opinion pages at WikiProjects. Its one thing to start an RFC to formulate a WP:CONSENSUS on a wider policy page or even any page in article space. It's another thing to change opinion pages meant to represent the opinions of a specific group of editors. It sort of like how its discouraged to edit another editor's user space. In general, I think the RFC tool shouldn't be used on opinion pages at all if they are published by a specific group that isn't reflective of the wikipedia public at large (unlike general essays, wikiproject adivce pages are opinions tied to a specific group). I can't think of a scenario, or example of an RFC where that has been necessary and appropriate. Can you? If so link that RFC here.4meter4 (talk) 19:22, 19 June 2026 (UTC)
It is "discouraged" to edit in another editor's user space, but an RFC can be used to force a change to someone's User: page, or to a user essay, just like Wikipedia:Miscellany for deletion can be used to force the deletion of such a page. Why should a group of self-selected editors be exempt from a process that applies to everyone and everything else? (And do you really want to leave the community with no option except deletion?)
The most relevant RFC in this context is 2010 Wikipedia talk:WikiProject Composers/Infoboxes RfC, in which the WikiProject was forced to change their advice so that it didn't directly conflict with MOS:INFOBOXUSE and assert WP:OWNERSHIP of "their" articles.
Note that there's no requirement for the group to say anything at all about infoboxes. If the group hates it, they can remove the whole thing. The outcome that's not available is contradicting the ordinary rules. We don't ever want editors to find "WikiProject Example/Advice" and read "do X" when the official community-wide guidelines say "don't do X".
If you would like to look for past RFCs, then you might find the long list of RFCs in User:BilledMammal/List of RFCs to be useful. (Note that the links take you to the page where it happened, but almost never to the RFC itself.) WhatamIdoing (talk) 20:14, 19 June 2026 (UTC)
I fear that this complaint is based on multiple misunderstandings:
1. There is no such thing as "protected speech under WP:FREESPEECH policy". 'Protected Speech' sounds like something one might find under the US Constitution, whereas WP:FREESPEECH is merely a user essay, the personal opinion of the editor who wrote it, and has no formal status within Wikipedia. In any event, it argues against your position.
2. Wikiprojects do not have "members", in the sense of a defined closed group of editors who have the exclusive power to set up and enforce private rules that you call "info box policy". Wikiprojects are by design open, and any editor who has an interest and wishes to consider themself to be a 'member' is perfectly entitled to express a view, whether or not they have left their name on the project page. I would consider myself to be an informal member of a number of Wikiprojects, including that one, although I typically don't bother to put my name down.
3. Wikiprojects are at perfect liberty to create pages of recommendations, and many of them do. What they are not permitted to do is to draft instructional pages that conflict with formal Wikipedia policies and guidelines. You may say that the wording that has now been brought into line with the Wikipedia guideline was only an advice page and was, therefore, never in conflict. However, as a matter of practice, certain highly active editors in this area systematically treated that wording as taking precedence over the official guidelines, including immediately reverting any infobox that was added by an unsuspecting editor, and enforcing a private rule set out in hidden text within articles which explicitly required editors to seek permission in advance before making certain edits. MichaelMaggs (talk) 21:18, 19 June 2026 (UTC)

RFCALT

Based on previous discussion, I’ve added a little bit on RFCALT (but keep stuffing up the shortcut/anchor :)). Feel free to revert or make any improvements Kowal2701 (talk, contribs) 16:28, 23 June 2026 (UTC)

I’d like to add something like RfCs are better suited for disputes that naturally have clear discrete options. Complex disputes may benefit more from notifying noticeboards and WikiProjects for outside input to consensus build with, or filing a report at Wikipedia:Dispute resolution noticeboard. Kowal2701 (talk, contribs) 16:33, 23 June 2026 (UTC)
I oppose adding that, because it's not true.
An RFC is an advertising mechanism for a discussion. It doesn't matter what kind of discussion it is. "Complex disputes" need advertising just as much as simplistic ones. WhatamIdoing (talk) 19:02, 23 June 2026 (UTC)
I think it makes sense to simplify for rfcs that will attract a large number of commenters, which i think is rhe only real advice on the oage right? User:Bluethricecreamman (Talk·Contribs) 19:47, 23 June 2026 (UTC)
We recommend adding more structure (e.g., ===Survey=== and ===Discussion=== sub-sections) to RFCs that will attract a large number of commenters. That could be considered complicating them instead of simplifying them. WhatamIdoing (talk) 21:55, 24 June 2026 (UTC)
RfCs are usually strawpolls despite our wish for them not to be, I think there either needs to be prominent advice for how and when to have a wider discussion more conducive to consensus building, or refer editors to a different process Kowal2701 (talk, contribs) 19:58, 23 June 2026 (UTC)

Considering opening an RfC

I am seeking outside input regarding what I believe is a longstanding pattern of conduct on this article that may be inconsistent with collaborative editing though I am not sure if it is worth creating an RfC for.

My concern is not based on a single revert or content dispute. Rather, it is a recurring pattern in which User:SheriffIsInTown has repeatedly reverted good-faith, sourced edits from multiple contributors, resisted substantial changes, and often failed to build consensus before restoring their preferred version.

For example, after reverting one of my edits he said:

"Start the discussion, follow WP:BRD.... I brought this article from 17000 words to 10000 words, you cannot add just too long ass paragraphs after that"

While referring to WP is appropriate, I am concerned that invoking the amount of work they previously invested in the article as a reason others cannot expand it suggests a level of control over the article and WP:Ownership.

There have been other examples as well. During a talk page discussion in which another editor suggested additional trimming of the article, Sheriff responded that "no further trimming is needed at this time", without addressing the concerns that had been raised by the GAN reviewer.

Sheriff also reverted my edit regarding a military appointment by Khan as "inconsequential" despite the office being a four-star rank appointment and the highest ranking military official.

Another edit where Khan successfully defended himself in a libel case brought forward by Ian Botham and Allan Lamb, which was described as the most expensive libel actions in cricket history at the time, was reverted by Sheriff who said "the lawsuit was filed and in return was inconsequential".

Sheriff also promotes the incumbent Pakistani government's official propaganda narrative (an example), accusing journalist Ryan Grim, on more than one occasion, of not being an independent source and colluding with the PTI.

My understanding is that these concerns are not mine alone. Other contributors to this article, including @Burrobert have also experienced similar difficulties with Sheriff. I encourage them to comment directly if they wish, instead of me speaking on their behalf.

Resisting changes from multiple editors and treating prior work on the article as carrying special authority screams WP:Ownership to me. I would appreciate if anyone could give me advice regarding this. Thanks in advance. WikiEnthusiast1001 (talk) 19:04, 29 June 2026 (UTC)

An RfC might be appropriate for a specific dispute. If there was a pattern of disruptive editing that would be a different venue. In a quick skim, I don’t see disruptive editing, just normal content disputes. Dw31415 (talk) 19:27, 29 June 2026 (UTC)