Wikipedia talk:Requests for comment

From Wikipedia, the free encyclopedia
WikiProject Dispute Resolution    (Inactive)
WikiProject icon This page is within the scope of WikiProject Dispute Resolution, a project which is currently considered to be inactive.
          A Wikipedia ad has been created for this project page. Click [show] to view it.

How soon after a closed Rfc may one open a new one on the same topic

Should the Rfc project page say anything about timeliness, in particular, how soon after closing an Rfc is it reasonable to open another on essentially the same topic?

I find myself feeling somewhat annoyed that one week after closure of this page move Rfc at which I commented (and this move review), another page move Rfc has been opened for the same page. I don't doubt either the good faith or the cogency of the new arguments made in the new Rfc, but imho either they should have been made earlier, or they should just give it a rest for a while, and take it up again at a later time.

Will someone dissatisfied with the outcome of this one, create a third Rfc in a few weeks? At some point, this becomes disruptive of volunteer editor time. One could always just say to oneself, "Okay, I'm not wasting my time on this again," but that seems like it might play into the hands of those with an axe to grind about the results of a previous Rfc. I suppose this is a subset of the more general question of how soon can you reasonably request editor time to try to overturn consensus on any subject after it has been previously obtained.

Should the project page make any recommendation about Rfc timing? Even if it should, I wouldn't name any specific time period in a reco, but just say something about "discouraging opening a new Rfc soon after a previous one has closed," without defining it too exactly, in order to give some support to those who don't want to be whipsawed by a series of competing Rfc's. Mathglot (talk) 02:02, 10 March 2018 (UTC)

@Mathglot: These are not RfCs, they are RMs. --Redrose64 🌹 (talk) 09:15, 10 March 2018 (UTC)
Mathglot, we don't have hard rules on this. There are too many varied circumstances. Here's my cursory review of the situation. A second move request in just a week is generally inappropriate. It looks like the new proposal was started by someone uninvolved in the previous discussions... I'm not sure if they even knew there was a previous move discussion. At the moment there appears to be significant input by people on both sides of the issue, and you seem to acknowledge a reasonable case is being presented. At this point trying to close down the discussion would only create a mess. Let it play out.
If the situation were to become disruptively repetitive, anyone can apply a closure. However that person is taking responsibility for any ensuing mess if the closure is disputed. It's an extremely bad idea for someone previously involved in the debate to make that kind of closure, unless you're dealing with obvious sockpuppets or other blatantly abusive situation you're confident of overwhelming community endorsement. If you're involved in that kind of situation you can try posting to Requests For Closure:WP:AN/RFC asking for an uninvolved party to close. Be sure to give a very clear reason, like "third move request in one month". The reason has to be good enough that a closer considers the cost of leaving the discussion open outweighs the risk of personal-and-community-cost of an argument over the closure. Alsee (talk) 08:58, 11 March 2018 (UTC)
Mathglot, the problem with vague discouragement is that different people will interpret it differently, so the rule will multiply disputes ("See? It says not to do it 'too soon', and I waited a whole month!" "Yeah, but I think it means you have to wait a whole year!"). When people have proposed specific times for asking the same question, they usually suggest three to six months (but perhaps only one month under some circumstances). RM has always seen the occasional "Now move it back!" discussion on the heels of a discussion that ended with the "wrong" answer. I don't think that RFC has seen as much difficulty with that. WhatamIdoing (talk) 06:24, 17 March 2018 (UTC)
Thanks, that's helpful. Mathglot (talk) 06:07, 18 March 2018 (UTC)

RfC about adding instructions for starting RfCs

There was no consensus to implement this proposal as written. I will take the collective advice given by those opposing and reformulate a proposal that presents this as a suggestion given outside of the instructions. I thank all who responded to this RfC.--John Cline (talk) 00:37, 26 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should the instructions for starting RfCs be modified to include telling the filer to link any previous discussion pertaining to the request being started, that may have occurred?--John Cline (talk) 14:30, 26 March 2018 (UTC)


I have participated in RfCs where preliminary discussion had taken place but was not mentioned or linked in the request/proposal. In such cases, the omission invariably had a negative impact on the discussion. I have come to believe that we should add instructions to include the links; to remind the RfC's filer at the opportune moment when they need most not to forget! And since it's an iteration favoring openness, and inclusiveness as the best practice, I do not see a down side in doing so. I hope that others will agree.


This RfC was published with a demonstration of the proposal itself included. Directly between the {{rfc|policy|prop}} template box and the "brief, neutral statement" time-stamping the RfC, is a rectangular box titled "Prior discussion pertaining to this RfC" that will display the links to prior discussion if provided (if no links are given no part of the rectangular box will appear).

The two links given in the demonstration are tangentially relevant to this request in that one is to a recent RfC that I think would have benefited by linking its prior discussion and the other is a talk page comment where I mentioned this to the RfC filer. The demonstration accurately reflects implementing this proposal, if adopted.

The template controlling the "prior discussion" <division> will be embedded inside of the {{rfc}} template and passed through a parameter called |prior discussion=. The parameter will go just after the categories. For example:{{rfc|hist|prior discussion= [URL_links] and/or [[wiki|links]]}}Since the parameter goes just after the categories, the parameter instructions should correspond and be right after the category instructions. Therefor, where it currently says:


  • If the RfC is relevant to two categories, include them both. For example: {{rfc|econ|bio}}
3. Include a brief, neutral statement of or question about the issue in the talk page section, immediately below the RfC template. ...
It could instead say:


  • If the RfC is relevant to two categories, include them both. For example: {{rfc|econ|bio}}

3. If you are aware of prior discussion pertaining to the RfC, best practice is to ensure it is linked through the template's |prior discussion= parameter placed just after the categories. For example: {{rfc|econ|bio|prior discussion="links go here"}} If prior discussion is linked, do not truncate the RfC expecting the links to be read. See the template's documentation for more information.

4. Include a brief, neutral statement of or question about the issue in the talk page section, immediately below the RfC template. ...
I look forward to reading the ensuing replies, and learning if the community supports this proposal. Thank you.--John Cline (talk) 14:30, 26 March 2018 (UTC)


  • Yes but the instructions should also say that the RfC statement and initial comment should not assume the reader has read the prior discussion - An RfC should stand on its own. Bryan Henderson (giraffedata) (talk) 15:41, 27 March 2018 (UTC)
  • I think linking prior RFCs is a good idea... but I am concerned that a failure to link not be wikilawyered as “invalidating” a current RFC. It is quite possible for an editor (or editors) to simply be UNAWARE of prior discussions and neglect to link (for example, the previous RFC might have been held years ago, and may now be buried deep in the archives). So... Any instructions encouraging editors to link needs to be worded as being “best practice”... not as a “rule” that must be followed to make any current RFC valid. Blueboar (talk) 16:38, 27 March 2018 (UTC)
  • Yes It forces people not to reinvent the wheel, and makes people think 'do we really need this discussion?' talk to !dave 16:53, 27 March 2018 (UTC)
  • Yes Maybe it'll trigger posters to realize that they need to have had prior discussions before initiating. Chris Troutman (talk) 17:00, 27 March 2018 (UTC)
  • No even if we make it a policy/guideline, I doubt people will remember to do it. Practicality being the basis of all of our policies and guidelines, I'm opposing this as instruction creep. Good idea that will never actually be followed in the case of most RfCs. TonyBallioni (talk) 17:35, 27 March 2018 (UTC)
  • Yes, but I agree with giraffedata that the instructions should include a note that RFCs should stand on their own. timawesomenesstalk⟩ 07:01, 28 March 2018 (UTC)
  • Yes also we should note something about relative strength of outcomes - an RfC with a strong consensus among a large group of editors should not be able to be superseded by a weak consensus among a smaller group of editors for example. It is a problem that RfC outcomes are very vulnerable to changing compositions of editors. ·maunus · snunɐɯ· 10:40, 3 April 2018 (UTC)
  • Yes While some users will doubtlessly not follow it, it is a net positive. -- Iazyges Consermonor Opus meum 04:23, 5 April 2018 (UTC)
  • No: as long as context is provided, I don't really see the point. RFC's are for getting fresh eyes on the subject matter. If we putting lots of links to previous discussions we run the risk of having less people respond to RFCs in general. --Deathawk (talk) 23:02, 7 April 2018 (UTC)
  • No - Doing an RfC "correctly" is already beyond many editors, including some who have years of experience. RfCs are never set in stone, editors who are better at it make improvements usually within two or three days of inception, and they are sometimes improvements that aren't in the instructions. This can remain in that category. The more "nice-to-haves" in the instructions, the harder it becomes to see the really important stuff, notably the part about neutrality. I think a "nice-to-have" is a list of links to pages where the RfC has been advertised, but I'm not going to propose adding that to the instructions. It will catch on if the community feels it's worth the effort, or it won't because the community does not, and it won't be a really big deal when it's not done. Another "nice-to-have" would be standard headings. And so on.

    Now, if there were a practical way to create an "RfC wizard" where folks could just fill in the blanks or choose from drop-down lists, with easy access to instructions for each field, that would be a whole different matter. But that's not on the table, and I suspect the reason we don't have such a thing for other processes is because it isn't practical. ―Mandruss  12:19, 9 April 2018 (UTC)

  • Somewhat torn, but this RfC really should be published at WP:VPP. My first reactions to the proposal are similar to those of Mandruss. I agree that this is usually best practice, but I can think of many scenarios in which it would be highly impracticable. Certainly an RfC author should not be trying to re-argue issues recently settled through expansive consensus, but we already have policies which set out the threshold for when that behaviour crosses from legitimate effort to seek broader input to the point at which it becomes abuse of process and refusal to WP:DROPTHESTICK. Adding a second layer of control here would lead to an inflexible process that would compel authors to link to discussions which may be meandering, repetitive, off-point, the product of abuses by socks or banned users, or any number of other things which would not help the respondents of the RfC nor the consensus-seeking process generally. And if they do not link to just the right content from a past discussion that another editor wants "entered into the record", the RfC OP can be accused of lack of neutrality, setting the RfC on a collusion course with conflict before it has even started. I already see a lot more stonewalling and accusations at the beginning of RfCs lately than I have in the past, and I fear this would become just one more stretch of territory for a turf war.

    That said, the proposed wording does make this more a strong suggestion than an outright rule, and perhaps in those terms its overall effect will be more beneficial than harmful, by encouraging those in conversations that have not turned toxic yet to include more background information, while still allowing OPs to avoid reference to past discussions if necessary. I think I'd still like to see the wording finessed a little more towards something that emphasizes the optional nature of this step though. Regardless, given the broad import of this discussion to a policy relied upon by a major portion of this project every day, I think this qualifies as necessitating listing at WP:VPP and/or WP:CD, if we want the resulting consensus to have proper legitimacy. Snow let's rap 04:20, 10 April 2018 (UTC)

    Advertised at VPP.[1]Mandruss  05:02, 10 April 2018 (UTC)
  • No, but I think that we could improve the instructions in this direction. So the problems with saying "Do this" are that it absolutely will be interpreted as a requirement, and the "if you are aware of" will be used to bludgeon the filer ("I am shocked, shocked that this obviously bad-faith editor did not link to the archived prior discussion that happened two years ago!") and claim that the result is illegitimate (only if it disagrees with my vote, naturally). There are also times when dredging up prior discussions is not actually helpful. Also, lengthening the instructions makes the process seem more daunting and difficult. As an alternative to complicating the instructions here, I suggest expanding Wikipedia:Writing requests for comment to contain more detailed advice. WhatamIdoing (talk) 05:06, 12 April 2018 (UTC)
  • No per WP:CREEP. RfCs are a request for comments, they are not all or even majority on very important things discussed numerous times, it shouldn't be as a requirement; anything with previous rfcs will have have enough people to point it out, generally. Also per Mandruss, the important stuff shouldn't be overshadowed by minor stuff. Another thing, is it purely about discussions directly pertaining (e.g, discussion that led to the RfC wording, spurred the rfc) as mostly mentioned as the basis for this, or any relevant discussion (e.g previous rfcs on the same subject)Galobtter (pingó mió) 05:15, 12 April 2018 (UTC)
  • No although I support the template parameter being made available. RfC's should be able to function independently. If linking to other discussions is required/mandated, there is a risk that flaws in those previous discussions will undermine the new RfC, akin to 'cumulative poisoning'. In addition, as others have said, an RfC proposer may not be aware of previous discussions and this shouldn't give cause for others to claim invalidation of an RfC; as consensus pertains directly to the wording of a specific RfC proposal.

    That being said maybe there should be a policy to deal with the creation of purposefully ambiguous (bad faith) proposals that are geared towards achieving a certain outcome. For ambiguity by good-faith, the solution is simply asking the proposer for extra clarification. Cesdeva (talk) 15:12, 16 April 2018 (UTC)


  • Thank you Giraffedata for your support and your suggestion. I have added a brief statement per your recommendation and will elaborate the matter more fully in the template documentation if the proposal is adopted. Thank you again.--John Cline (talk) 17:31, 27 March 2018 (UTC)
  • I understand your concern TonyBallioni. I am endeavoring to frame this as a reminder and not a creepy rule. It's OK if it is missed, a bit more OK if it's not, and the links can be added after the RfC is published as well. The parameter's functionality will not go away for not being used upon publishing the RfC.--John Cline (talk) 18:30, 27 March 2018 (UTC)
    • I'd be fine with adding a parameter, but I think making this part of the instructions would open up more WikiLawyering about whether an RfC was valid, etc. I'd just go ahead and create the parameter and make a note about it somewhere on the page. I get what you're trying to do, but I think that it won't be done more times than not. TonyBallioni (talk) 18:37, 27 March 2018 (UTC)
  • By "prior discussion", do we mean one that is in the section above the RfC proper, or one that is now in the archive pages? Or could it be both? At this RfC we have "As promised in the section above" which doesn't refer to the section immediately above, but to the one above that. Some RfCs get started for matters that were resolved years ago, simply because some newbie didn't know about talk page archives. --Redrose64 🌹 (talk) 19:20, 27 March 2018 (UTC)

    Thank you for your interest Redrose64, and your interesting question. I had considered this, and couldn't find any reason to preclude any relevant links, even if they were two threads up on the same page. At the same time, I couldn't find any reason to prescribe the links beyond their being relevant, and link-able by single or double bracket methods.

    In trying to fashion an instruction that was proportionate to the other steps, I couldn't escape the constraints of the small area for text. Of the many things I would like to have stated but simply could not, prescribing and restricting certain, otherwise relevant, links simply had to go unsaid.

    At best I could have scattered bits of instruction across the page and probably would have had to on at least a few instances. Or brought it out in the documentation page.

    I will say that there is a certain beauty in TonyBallioni's suggestion that it not be given as an instruction at all, but instead as a parameter based functionality that is mentioned outside of the actual instructions. I certainly do not object to that approach at all and might have proposed it that way had I thought of it myself.--John Cline (talk) 00:10, 28 March 2018 (UTC)

  • Thank you Deathawk for your perspective. I agree that a large amount of links could be off putting. The RfC certainly does not endeavor for that outcome. I don't think it's a given that it will become polluted with links and if it does, I suspect we will insert measures to throttle it down. If the proposal is adopted, your concern will not be disregarded. Thank you again.--John Cline (talk) 00:59, 8 April 2018 (UTC)
    • Also, I find the whole idea counter-intuitive. In many cases an RFC is started simply because fresh eyes who are not part of the drama are wanted. This is useful as sometimes we, as editors, can not see the Forrest from the trees per say. In other words an issue in the talk pages might be brought up, that really would not be significant to your run of the mill reader. By informing the new eyes of these prior discussions, you are preventing a fresh view of the situation from happening. --Deathawk (talk) 05:59, 9 April 2018 (UTC)
  • I don't believe having a parameter in {{rfc}} would work well with the bot Galobtter (pingó mió) 05:19, 12 April 2018 (UTC)
    I've done a fair amount of testing and while there were problems in several interim configurations, everything I encountered or could foresee was favorably resolved. I am curious to hear of the things concerning you, so they can be more fully considered.--John Cline (talk) 05:54, 12 April 2018 (UTC)
    Well if you've done the testing with the bot that's good :) Didn't figure actually that the bot would handle that actually Galobtter (pingó mió) 06:11, 12 April 2018 (UTC)
    @John Cline: Where was this "fair amount of testing" that you did? --Redrose64 🌹 (talk) 07:36, 12 April 2018 (UTC)
    My editing history from March 12 to March 26 shows changes spread across User:John Cline/Outhouse, Template:Discussion interlink/sandbox, and Template:Discussion interlink/testcases although much of the results are discernible without requiring the page to be saved, and also much was tested via Special:ExpandTemplates where publishing the results is not even an option. For the most part, when a problem was overcome or the result was in accord, I would save that result, in some fashion, for later reference and use. I do believe I did a fair amount of testing, and I believe there are things I failed to consider as well, in spite of good intentions. When and if these were to come about problematically, and I could not mitigate the problem, I would then approach users much more technically proficient than me, which literally includes you Redrose64, and I am confident we could resolve those as well. Thanks for asking, and for the help you've already given.[2]--John Cline (talk) 08:33, 12 April 2018 (UTC)
  • Thank you WhatamIdoing, I agree with you and mentioned so above. You advocate your perspective very well. Galobtter, The original drafts of this RfC were focused on "discussion directly informing the RfC" with an example given where specific wording in the RfC was the result of compromise achieved in the prior discussion. It seemed to border on tl:dr when it was finished and much was lost in my efforts to reduce the RfC to a more concise presentation. The RfC's main question is nevertheless being answered quite well; to that end, I am pleased.--John Cline (talk) 07:07, 12 April 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Somebody remind me how this works?

If I add a new and current timestamp after the {{rfc}}, will the RfC maintenance bot automatically 1) re-list the RfC in the current day's directory and, 2) trigger a new wave of random RfC notices to user talk pages of volunteers on the relevant responder's list? Snow let's rap 03:34, 10 April 2018 (UTC)

@Snow Rise: The "RfC maintenance bot" is Legobot (talk · contribs) and it has a number of bugs and other quirks, such as the inability to respect <nowiki>...</nowiki> tags, as here, with this result. More to follow. --Redrose64 🌹 (talk) 12:20, 10 April 2018 (UTC)
Thanks for the fix--I was unaware of that quirk! Snow let's rap 21:47, 10 April 2018 (UTC)
As I have explained many times, Legobot looks for two opening braces followed by the three letters "rfc" (case-insensitive). These five characters "{{rfc" mark the start of the RfC opening statement, and the first valid timestamp that occurs after that point marks the end of the RfC opening statement. It is the RfC opening statement (including the timestamp but excluding the {{rfc}} template) that is copied to the RfC listing pages. The timestamp has other purposes:
  • it marks the end of the RfC opening statement
  • it is used to determine the correct position on pages like WP:RFC/BIO which are in reverse chronological order
  • it is used to determine when thirty days have elapsed, and hence when the {{rfc}} template should be removed and the RfC delisted
Regarding the "random RfC notices to user talk pages of volunteers on the relevant responder's list", this is WP:FRS. The timestamp is not used to decide if a given user has already received a "Please comment on ..." FRS message - it is the value of the |rfcid= parameter that is used for that. Hence, if the timestamp is altered, the FRS won't re-message a given user; but if the |rfcid= is altered, a user may well be messaged a second time.
I do not know what this "current day's directory" is - please provide a link to it. --Redrose64 🌹 (talk) 12:38, 10 April 2018 (UTC)
Thank you for the info, Redrose. Re: "current day's directory" I misspoke; I must have momentarily been thinking of the AfD listings, which aggregate the indexes per date, rather than by topic. I guess what I should have asked, if anything, was whether the replacement of the timestamp will move the discussion to the top of the topic-specific indexes--and it's clear from your response that it does in fact do so. As to my main inquiry, thank you for that info as well: the mechanic I was inquiring after was the means of triggering a second wave of invites if there had been no initial responses in the first thirty days (repeated invites to previous invitees seems less useful in these circumstances). It would seem (if I am reading you correctly) that the means to accomplish this is by triggering Legobot to issue a new rfcid, rather than by manually altering the timestamp. Thank you for clarifying that matter! Snow let's rap 21:47, 10 April 2018 (UTC)
Forcing Legobot to issue a fresh rfcid is as simple as removing the existing |rfcid=xxxxxxx parameter; but some users don't wish to be re-messaged about an RfC that they have already been messaged about. --Redrose64 🌹 (talk) 22:20, 10 April 2018 (UTC)
I'd venture to guess that most users who have previously ignored an RfC would rather not be pestered about it again—especially if it is instead of getting notified of some new RfC.
Do you know how FRS distributes notifications? Does it notify everyone it can as soon as the RfC is listed and never again, or does it notify additional people later as their limits permit, or does it spread out notifications over every day the RfC is listed? Bryan Henderson (giraffedata) (talk) 03:09, 11 April 2018 (UTC)
I've often wondered about those algorithms myself and tried to deduce them from observations about the distributed notices. I can tell you this much by way of providing one clue to the puzzle: I do not usually get anywhere near the limit of monthly notices in a given category that I am signed up for. I have very high limits in seven or eight categories, but only once or twice have I received enough notices to fill the qouta for a given category in a given month. That still allows for a lot of possible variations in how the bot chooses to distribute and time notices though. Perhaps Legoktm can clarify or point us towards the appropriate documentation. Snow let's rap 04:29, 11 April 2018 (UTC)
Yes, and more so than that, if a volunteer did not respond to the first invite, it is unlikely they will respond to another. That is why I was curious about the mechanism for re-listing in a fashion that specifically triggers the requesting additional randomly chosen respondents. Of course, sometimes when an RfC is re-listed, Legobot re-selects someone to whom it previously sent an invitation in the first instance--that is unfortunately unavoidable at present, but rare enough to not normally present a problem.
The FRS messages are spread over the whole of the thirty-day period. Maproom (talk · contribs) has been keeping careful record at their talk page (also in archives from March 2017) - at the bottom of each "Please comment on ..." message is a short annotation like "15 days"; this is the interval between the discussion being initiated and the message being sent out. If you analyse these, it should tell you the spread. Caveat: in some cases the {{rfc}} template was added after the discussion began, so Maproom's measurements are from the start of discussion, not necessarily from the moment that Legobot listed the RfC. --Redrose64 🌹 (talk) 07:55, 11 April 2018 (UTC)
Given that there is no mandatory length of time, it might make more sense to spread out notifications over a shorter period (e.g., twice as many per day, half as many days). WhatamIdoing (talk) 05:12, 12 April 2018 (UTC)
@WhatamIdoing: The problem with that is getting Legobot changed. If you have been following User talk:Legobot for two or three years, you'll realise that nothing, not even clear and detrimental bugs, is being amended. The only feasible route is for another bot to take over the RfC portion of Legobot's several functions. --Redrose64 🌹 (talk) 07:39, 12 April 2018 (UTC)
Well, I have proposed cloning Lego, and nobody's objected (doesn't everyone want a copy or two? ;-)), but there seems to be some sort of delay in the development process. There seemed to be some sort of geophysical problem with granting him 28 hours a day, so that he'd have time to do a few more things, so I've abandoned that idea. But you're right: this might be nice, but I don't think we're going to hold our breaths over it. WhatamIdoing (talk) 19:20, 12 April 2018 (UTC)

Philosophy template?

What's the deal with the template at Wikipedia:Requests for comment/Religion and philosophy? It's absolutely colossal (seriously, it takes up two yards of screen space) and is being transcluded into RFC/A, which doesn't really seem like a great combination. - (talk) 16:48, 8 May 2018 (UTC)

The bot includes it, but I don't know why. I don't think that it should be there. It looks like the old User:RFC bot started adding it in June 2009, shortly after this edit, but I can't find any on-wiki discussions that link to that template. WhatamIdoing (talk) 03:29, 10 May 2018 (UTC)

Two categories for RFC

User:John Cline, I see that you recently created Category:RFC, and that you have tagged it as "The main RFC category". I was under the impression that Category:Wikipedia requests for comment was "The main RFC category". What is your goal in creating the new cat?

Also, I believe that cat naming rules encouraged explicitly labeling back-room cats with "Wikipedia" (so that editors can easily tell which pages belong in this RFC cat and which belong in this other RFC cat) and discouraged the use of intials that most new people won't recognize. So if it's useful/non-duplicative, we should probably come up with a different name for it. WhatamIdoing (talk) 03:34, 10 May 2018 (UTC)

I appreciate your question and comments, and admit that categorization is a sharp curve in my overall route of wiki learning. I apologize if this situation is the result of my own misunderstandings. In saying that, I am open to the likes of this critique and the learning that invariably comes of its insight, and its replies.

After creating the shortcut: WP:RFCST (targeting the instructions for starting an RfC) I searched for, and could not find an existing category that seemed appropriate for its categorization. I first searched Category:RFC (red at the time) hoping, at least, to find the tree leading to it. Being a red link, I next looked at the target page, for its categorization, and noticed Category:Wikipedia requests for comment. Objectively, it wasn't the category I was seeking; wanting an administrative container, exclusive to the RfC process, that did not commingle itself within content categories, nor its members among non-RFC-specific pages.

I then looked at WP:DYK, to scrutinize its model, and pattern a category by its example. While I appreciate the need not to alienate new users by titling pages with jargon or other types of specialized terminology, I also believe we should endeavor to supply results for search plausibilities reasonably anticipated among veteran users as well. I would have, therefore, converted the red linked category into a soft redirect to the proper title, however, upon seeing the DYK Project's manner, and use of Category:DYK, I created Category:RFC instead (as you see it now used).

I am keen to see this answered; best practice applied, and remain.--John Cline (talk) 09:04, 10 May 2018 (UTC)

So the goal is to have a cat that is RFC-specific, but does not contain pages where RFCs are currently happening. That seems reasonable to me. I think it just needs a new name. How do you feel about a title such as "Wikimedia requests for comment coordination pages"? (That's just my first idea, and perhaps someone else will think of a better one.) WhatamIdoing (talk) 17:43, 18 May 2018 (UTC)
How about "Wikipedia requests for comment process"? That would cover everything related to RfCs except actual RfCs (though the category of actual RfCs ought to be a subcategory, meaning it covers those too). Bryan Henderson (giraffedata) (talk) 21:22, 18 May 2018 (UTC)
I am not averse to a new name, nor to Category:Wikipedia requests for comment being the main category. In saying that, I'd like to ask: what is the functional difference between Category:Wikipedia requests for comment project administration and Category:Wikipedia requests for comment/project administration?--John Cline (talk) 05:28, 20 May 2018 (UTC)
I don't think that subpages are very commonly used in the category namespace, but I think the pages work the same as any other subpage. If we want to find out, we could send it to WP:CFD; it's probably the best place for finding someone who knows how categories work. (I think we might need to do that anyway, as I'm not sure there mere mortals like us can move categories.) WhatamIdoing (talk) 05:45, 22 May 2018 (UTC)

Wow, this raises an entirely new question aside. If ever an editor, without an admin flag, was whole hardheartedly thought of as an administrator, I believe you are the quintessential "textbook example". I have posted related comments on your talk page since discussion in this thread is off topic. I am nevertheless very interested in seeing that discussion unfold.

I think WP:CFD can be useful in this situation but I'd like to ask for the indulgence of a bit more wp:before time, to ensure the nomination is published in the best possible form. To help with our considerations, I am confident in BrownHairedGirl's category knowledge, If she will share it here, with us. In fact, she is so full of insight, that consensus suggests she isn't a girl at all, but a guy. Shocked-tpvgames.gif

I'm sorry, I couldn't resist inserting that joke, for levity. Face-devil-grin.svg I absolutely do not ascribe to such notions, and no such consensus exists. Cheers.--John Cline (talk) 09:20, 22 May 2018 (UTC)

"Mere mortals" with the ability to move pages (e.g. articles) can certainly move category pages as well; but unless they are willing to take on the ancillary cleanup, anybody (admins included) who wishes to rename a category should file a request at WP:CFDS and let Cydebot (talk · contribs) make all the moves and other necessary edits. --Redrose64 🌹 (talk) 09:55, 22 May 2018 (UTC)
@Redrose64: the only applicable speedy criterion would be WP:C2E (if @John Cline chose a new name and made the nomination). But there are several options, so a speedy might be opposed ... so I think this would be be better to go directly to a full discussion. --BrownHairedGirl (talk) • (contribs) 10:52, 22 May 2018 (UTC)
(ec) @John Cline: I'm sure that when the goddesses convict you of sexist humour and sentence you to a few centuries pushing boulders uphill, you'll enjoy their joke Face-grin.svg Face-wink.svg
Seriously, tho: tks for the compliment. Here's my thoughts.
WP:Subpages is clear that subpages (i.e. with a slash) are used only in limited circumstances. They are rarely (if ever) used for categories. I can't think of any such uses at all. That's because they are not needed: a sub-category is linked to its parent in other ways, and doesn't need the slash.
I agree with those who dislike the current name: it doesn't clarify the category's purpose. Something like Category:Wikipedia requests for comment process or Category:Wikipedia requests for comment administration would be much better.
Best way to proceed is simply to make a CfD nomination, listing a few options for the new name, and link to this discussion. Its not unusual for a CfD nomination to be some variant of "rename to something better than this", and let consensus emerge in discussion. --BrownHairedGirl (talk) • (contribs) 10:47, 22 May 2018 (UTC)
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia talk:Requests for comment"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA