Wikipedia:Village pump (policy)

The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.

If you wish to propose something new that is not a policy or guideline, use Village pump (proposals). Alternatively, for drafting with a more focused group, consider starting the discussion on the talk page of a relevant WikiProject, the Manual of Style, or another relevant project page.
For questions about how to apply existing policies or guidelines, refer to one of the many Wikipedia:Noticeboards.
If you want to inquire about what the policy is on a specific topic, visit the Help desk or the Teahouse.
This is not the place to resolve disputes regarding the implementation of policies. For such cases, consult Wikipedia:Dispute resolution.
For proposals for new or amended speedy deletion criteria, use Wikipedia talk:Speedy deletion.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after 7 days of inactivity.

« Archives, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205

MOS: prescriptive, descriptive, or both?

The Manual of Style varies in levels of consensus. In Wikipedia:Arbitration/Requests/Case/Article_titles_and_capitalisation_2 it was alleged for some parts of MOS: some of those guidelines have fewer watchers than my talk page, and are largely written by parties to this case (see discussion). Meanwhile, CONLEVELS states:

Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope.

I don't think it's unreasonable to conclude that while some parts of MOS are the result of consensus with significant participation, there may be other parts that are indeed consensus among a limited group of editors, at one place and time.

Also of note are the proposals by L235 that did not make principles for that case. Specifically,

Policies and guidelines have a combination of prescriptive and descriptive characteristics. Policies and guidelines document community consensus as to "standards [that] all users should normally follow" (Wikipedia:Policies and guidelines), giving them some degree of prescriptive force. Simultaneously, policies and guidelines seek to describe "behaviors practiced by most editors" (Wikipedia:Policies and guidelines), and change with community practice, giving them a descriptive quality. Naturally, disagreements regarding the extent of a policy's consensus or prescriptive effect arise from this combination, and the text of a policy can sometimes diverge from or lag behind community consensus. These disagreements, like all disputes on Wikipedia, should be resolved by discussion and consensus.

Does MOS necessarily indicate community consensus on a wider scale? In other words, should closers examine the specific text for level of consensus before using it to overrule a (potentially larger) group of editors? Good day—RetroCosmos ^talk 01:45, 26 August 2025 (UTC)[reply]

Comment WP:MOS says at the top "Editors should generally follow it, though exceptions may apply." Not sure anything constructive will come of this rfc, but time will tell. Gråbergs Gråa Sång (talk) 07:03, 26 August 2025 (UTC)[reply]
I would agree with L235, and add that, ideally, policies and guidelines describe community consensus and prescribe editors to follow this consensus. Regarding the MoS, as a set of guidelines with various ranges, it is expected that not all of its pages will have the same level of consensus – a very specific topic will attract less interested editors, and thus naturally have a lower CONLEVEL. That in itself is not necessarily problematic. However, if it goes against a wider consensus, or only reflects a subset of the views of editors interested in that topic, then there is indeed a CONLEVEL issue and a broader discussion should be held. Chaotic Enby (talk · contribs) 15:31, 26 August 2025 (UTC)[reply]
As a closer, I would not feel justified in going on an independent fact-finding mission to determine the level of consensus that supports a specific policy or guideline. I would support overturning closures that were based on such an independent mission. If participants in the discussion gave valid arguments based on their own analysis of the level of consensus, I would consider that when making my decision.
To put it another way, I presume that guidelines and policies have a higher level of consensus than any local discussion. A mass of editors who disagree with a guideline should be directed toward venues where guideline change can happen, not a local discussion. Firefangledfeathers (talk / contribs) 15:53, 26 August 2025 (UTC)[reply]
Consensus isn't only found by discussion, but also by use. Maybe four editors discussed a particular piece of policy or guidance, but many editors may follow it because they also support what has been said. If editors disagree with any particular price of guidance then they should start a centralised discussion in whatever forum would be appropriate.
So the answer to the specific question is probably, maybe, but to start discussion on specifics as required. Certainly the MOS in it's entirety has some level of wide scale support, even if it's quite possible that not all of it does. -- LCU ActivelyDisinterested «@» °∆t° 12:42, 27 August 2025 (UTC)[reply]
ActivelyDisinterested is absolutely right. Many long-standing aspects of the MOS have strong consensus not because of the number of editors involved in the original drafting, perhaps decades ago, but because they have been widely followed without significant challenge ever since. It would be quite unworkable for closers to start undertaking historical investigations about the origin of about any particular rule in order to determine how seriously it is to be taken. All MOS rules should generally be followed per WP:MOS, and if a later group of editors think the rule is wrong they always have the option to open a centralised discussion suggesting that it be changed. MichaelMaggs (talk) 13:23, 27 August 2025 (UTC)[reply]
To answer the question Does MOS necessarily indicate community consensus on a wider scale?, I would say the answer is a clear yes. Closers should not try to deep dive the history of how certain parts of the MOS came to be in determining a local consensus on (for example) an article talk page. Instead, those concerned with MOS should go to the MOS talk page and open a discussion there to enact change. And I would say this for any policy/guideline (including notability guidelines, for example, where I've found discussions were limited to 2-3 people for some changes, but those changes have stood for over a decade). —Locke Cole • t • c 19:45, 27 August 2025 (UTC)[reply]
I think this RFC question would have benefited from some additional workshopping. There are two unrelated questions being asked:
1. Is the MOS prescriptive, descriptive, or both?
2. Does the MOS have consensus?
  - My answer to the first requires you to know what prescriptive and descriptive mean. The MOS is both, depending upon the level you analyze it at. It is descriptive in the sense that the community wants to follow the rules of good grammar, punctuation, and other elements of writing style that are relevant to an encyclopedia. We follow these; therefore, a style guideline saying to follow these accurately describes the community's practice. At a more specific level, the MOS is prescriptive: instead of saying 'the community uses good punctuation practices' (descriptive), it says 'the correct punctuation practice to use is this one' (prescriptive).
  - My answer to the second is that you should assume, unless and until you can prove otherwise, that any page with a {{guideline}} tag at the top is exactly that community consensus on a wider scale that is mentioned in CONLEVEL. RetroCosmos, since this was all before your time, let me tell you in very concrete terms what CONLEVEL is actually about: CONLEVEL means that when MOS:INFOBOXUSE says The use of infoboxes is neither required nor prohibited for any article, then a handful of editors at Wikipedia:WikiProject Composers are not allowed to say "Yeah, well, that might be what the official Wikipedia guideline says, but they're prohibited for our articles, because we had a private chat among just our little group of editors, and we decided that the official Wikipedia guidelines don't apply to us". Trying to apply the MOS (or any other policy or guideline) = not a CONLEVEL problem. Declaring "your" articles exempt from the MOS = possibly a CONLEVEL problem. WhatamIdoing (talk) 20:30, 27 August 2025 (UTC)[reply]
This RfC is overly broad. Most of the MOS is supported by strong affirmative consensus. I encourage editors who take issue with a particular part of the MOS to start an RfC asking whether that particular part currently has the support of the community. Such narrow discussions would be far more productive than philosophizing on the nature of the MOS as a whole. Toadspike [Talk] 06:07, 30 August 2025 (UTC)[reply]
This RfC is not helpful because standard procedure acknowledges that no set of rules can apply in every circumstance. The Article_titles_and_capitalisation_2 Arbcom case concerned extreme disruption over an extended period. That can occur with any policy or guideline. A favorite that pops up from time to time is WP:V where people go around deleting chunks of correct and well-written material because no one has added citations. WP:V definitely applies everywhere but dumbly pushing it wll result in blocks. Johnuniq (talk) 06:42, 30 August 2025 (UTC)[reply]

Even if we accept, for the sake of argument, that the topic-interested in an MOS discussion might sometimes result in an MOS issue resulting in a local consensus, the solution certainly wouldn't be to defer to a local consensus, which is far more likely to represent a local consensus. If there are concerns that an MOS consensus was not agreed upon by a sufficiently wide cross-section of editors, then the solution would be to discuss that consensus in a place likely to be seen by a wide cross-section of editors.
CoffeeCrumbs (talk) 19:07, 30 August 2025 (UTC)[reply]
Right. All guidelines, including all MOS pages, are presumed to have full community (i.e., non-local) consensus. However, there are hundreds of guidelines with thousands of pieces of advice, and at any given point in time, some small fraction will be out of date, badly explained, not reflective of current community practices, etc. Whenever those problems are identified, editors should fix them. That can be done through bold editing, through ordinary discussions on the guideline's talk page, through RFCs, etc. And even if the advice is sound in general, there might be reasons to not apply it in a specific instance. But you should not start from a position of assuming the MOS to be a WP:LOCALCON. It might be wrong, and it might need to be changed, but it's not a local consensus. WhatamIdoing (talk) 05:59, 31 August 2025 (UTC)[reply]
I don't know what the status is now, but I remember when the MOS had large parts written by a small group who hung out on the MOS talk pages, fiercely arguing with anyone who came there with an opposing viewpoint to preserve their desired version. Anomie ⚔ 11:35, 31 August 2025 (UTC)[reply]
Sounds like Wikipedia. Gråbergs Gråa Sång (talk) 11:40, 31 August 2025 (UTC)[reply]
As a participant in the arbitration case referenced in the opening, I feel I should point out that the issue there wasn't disagreement with the MOS but disagreement over how a particular section (MOS:CAPS) is interpreted. ~~ Jessintime (talk) 11:53, 31 August 2025 (UTC)[reply]
That was a reckless charge during the arb case. If something, in fact, lacked WP:CONLEVEL, then it should have been changed by a larger consensus. The case failed on that point. —Bagumba (talk) 14:08, 31 August 2025 (UTC)[reply]

The answer to the question "Does MOS necessarily indicate community consensus on a wider scale?" is generally no. The MOS is by and large the result of WP:BOLD editing and even when there is a discussion it usually involves only a very small number of people. It therefore reflects local consensus. Much was written before guidelines became elevated to the status they hold today and at best has implied consensus owing to having been there for years without being changed. In cases where it has proven too burdensome, it has indeed been overridden by a larger consensus. Most editors cannot be bothered. Some parts have never been able to reach a consensus. Mainly, though, we have an ongoing iterative process of improvement. Hawkeye7 (discuss) 03:45, 3 September 2025 (UTC)[reply]
Do you think that any edit without an RFC is a "local consensus"? WhatamIdoing (talk) 04:08, 3 September 2025 (UTC)[reply]
I reject the notion that two editors on an MOS talk page represents community consensus better than fifty editors on Wikipedia:WikiProject Composers. Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. That applies to the MOS talk pages every bit as much as project talk pages. Like most editors, I am happy to follow local consensus. Hawkeye7 (discuss) 23:01, 3 September 2025 (UTC)[reply]
I agree with Hawkeye, what matters is the visibility and scale (number of participants) of a discussion, not the venue. Obviously the venue is not irrelevant - a discussion at VPP is more likely to be accidentally discovered than one at e.g. Wikipedia talk:WikiProject Poetry, but if the latter is well-advertised and attracts 30 editors the consensus it establishes is more likely to reflect community consensus than an un-advertised discussion at Wikipedia talk:Manual of Style/Titles of works with only three participants. This is especially true if the subject of the discussion is specific to poetry and the consensus is to adopt the style that's been consistently used by a significant majority of relevant articles for many years. Obviously there are exceptions to this (e.g. if the de facto standard is inaccessible) but those exceptions need to be supported by evidence of an actual problem and an alternative must not be blindly and rigidly enforced without discussion to see if a compromise can be reached. See Wikipedia talk:WikiProject UK Railways/Archive 48#DLR colours for a semi-relevant example. Thryduulf (talk) 00:23, 4 September 2025 (UTC)[reply]

But do you also reject the notion that two editors on the guideline's page is better than two editors on any other page, when the purpose of the discussion is to improve the guideline?

Or imagine that it's not a guideline. If you and I have a chat on an article's talk page, is that better than you and I having the same chat on your talk page? WhatamIdoing (talk) 02:58, 4 September 2025 (UTC)[reply]
do you also reject the notion that two editors on the guideline's page is better than two editors on any other page all other things being equal, the discussion on the guideline's talk page is slightly better, but its still a weak consensus. A discussion elsewhere that is advertised to multiple places, including the guideline's talk page, is stronger than one with approximately the same number of participants that was held on the guideline's talk page but was not advertised elsewhere. Also, where the elsewhere is can matter - a WikiProject talkpage is probably going to produce a stronger consensus than an article talk page, which in turn is probably' stronger than a discussion on your or my talk page.

Venue, number of participants, amount of advertising, significance of change (from both the de jure and de facto status quo), reason for the change, depth of discussion and degree of unanimity are all relevant considerations and you absolutely cannot look at one factor in isolation and arrive at a reliable answer. Thryduulf (talk) 10:30, 4 September 2025 (UTC)[reply]
Pretty much sums up my thoughts on the matter. Good day—RetroCosmos ^talk 23:38, 5 September 2025 (UTC)[reply]

A WikiProject's talk page is more likely to produce the appearance of unanimity. The people in that group are largely there because they like working with each other, after all, and we expect them to mostly agree with their chosen wiki-friends. It is also, for most subjects, likely to represent the views of editors who know something about the subject matter (e.g., if you have a question about a medical article, drop by Wikipedia talk:WikiProject Medicine, not a village pump).

It is, however, less likely to represent the broader community's POV, especially if the question is:
not a question in which the group's subject-matter expertise is relevant (e.g., WikiProject Composers on infoboxes; WikiProject Infoboxes on composers' genres) or

an interdisciplinary question (e.g., in which WikiProject Medicine and WikiProject History might have different perspectives on what's important to include in the article).

Consequently, occasionally, a discussion at a WikiProject's talk page produces more "appearance of" than "actual" consensus. WhatamIdoing (talk) 22:16, 6 September 2025 (UTC)[reply]
I don't know if this is a good example, but I uploaded an image which (to my understanding) was allowed by policy/guideline. The image replaced an existing fair-use JPEG with a fair-use SVG of a videogame box cover. Upon getting the deletion notification for the old JPEG, the editor that uploaded the JPEG passed on talking to me directly, or opening a discussion at the article talk page, or just taking it through WP:FFD. Instead they opened a discussion at a WikiProject and "unanimously" decided to remove the image there.

In my view, the WikiProject definitely has knowledge about videogames, but the issues being raised by editors there are more technical and/or concern NFC questions, so surely the discussion would have made more sense at the article talk page with pointers at WP:VPT, WT:NFC and WT:VG to this centralized discussion. —Locke Cole • t • c 02:36, 7 September 2025 (UTC)[reply]
I think FFD might have made more sense, but I think the important thing to do right now is for you to post messages to relevant pages (e.g., WT:NFC) to bring in people who know less about what the group usually does, and more about what the Wikipedia:Non-free content criteria policy actually requires. WhatamIdoing (talk) 17:02, 7 September 2025 (UTC)[reply]
So, as I see it, there are a couple of things going on here which could influence how much "binding" consensus we should ascribe to any particular section/verbiage within the MoS. And these absolutely should be given serious consideration when applying any particular rule of thumb found within the manual, but in practice, these considerations are rarely cited, let alone heavily considered in debates that center around particular application in given use cases in article space. It would be nice if we had a more formalistic system for establishing the weight and uniformity to be ascribed to any given style principle, but the ad-hoc nature of the evolution of the MoS, combined with the fact that it was at one time meant to be purely advisory, but over time has taken on a less permissive tone overall, and with particular sections being almost entirely mandatory, that it would be very difficult to reverse engineer the entire body of style recommendations and re-code them in conformity with new and more express scheme for different levels of absoluteness with regard to different provisions. Though goodness knows that would probably save the community a lot of time on disputes if such a clearer system were implemented, so maybe it will be worth the effort at some point.
That lengthy preamble made, here are the primary two factors that I think influence how much weight and certainty a given piece of style guidance should have:
- First, was the discussion which lead to that verbiage the result of a full and appropriately approached WP:PROPOSAL? How many individual discussions were held, and how many community members took part in those discussions? Were the held in the right venue for the proposal in question (the talk page of the MoS subsection itself or the village pump, typically) and were they well advertised in other fora if the resulting rule was likely to effect a non-trivial number of articles? For example, on a significant number of occasions, small cadres of editors operating out of WikiProjects have tried to create rules (some of which were added to MoS pages without further authorizing discussion among the larger community. This of course is expressly forbidden by WP:Advice pages and a number of ArbCom rulings. On the other end of the spectrum, we have something like MoS:GENDERID, which is the result of a lot of community negotiation in some of the most massively-attended and assiduously-argued discussions in the history of the project. Some of argued that the resulting rules should have been codified in WP:PAG as a result, but for good or ill, it was placed in the MoS.
  But while there is some wiggle-room for most provisions in the MoS, there is a fairly absolute consensus at this point that no part of GENDERID is optional--though we continue to have arguments about how to apply it in particular cases. However, most provisions of MoS exist in a grey area between these two extremes. And unfortunately, because there are no handy labels to easily distinguish which are the result of more trivial or robust previous consensus discussion, it is often incumbent upon those arguing over a particular piece of guidance and its application to a given article or set of uses to either accept that they have to make pragmatic arguments for that use case, or else demonstrate that the history of debate for that provision shows previous and broad consensus for a universal approach, or that the particular use case in question has already been addressed. Again, suboptimal, but the reality we are left with after the organic and non-formalized growth of this part of our rules ecosystem.
- Second, we can also look to the intrinsic text that was generated by the consensus process described above. Because traditionally (and less so as time went on, but still to some extent) we intentionally left a lot of flex in MoS wording itself, to account for previous disagreement and to allow editors to use their best sense of what was required for the needs of the individual article or other namespace. Rules creep has gobbled up the edges of much of that flexibility, but many sections of the MoS still have vague or expressly permissive language for those purposes. Personally, I think we benefit from keeping those provisions lean for those very pragmatic reasons, but it is a natural consequence of a bureaucratic apparatus such as we work with here that more and more rules will accrue over time. Especially as it has turned out that there is no principle of grammar, formatting, or presentation to trivial or inane that the Wikipedia community at large has proven unable to generate at least two camps of deeply committed proponents willing to regularly and disruptively go to war across hundreds or even thousands of articles/talk pages to enforce their preferred version.
All of which is to say, the MoS is clearly very prescriptive with respect to many considerations, but the degree to which a given prescription (or proscription) is permissive or mandatory is highly variable, and often nothing short of research into and reference back to substantially aged discussions can settle just how strong a given requirement is. And even then, everything is of course subject to WP:CCC. Only the most well known and at one time divisive subjects, like GENDERID, are so absolute that everyone is expected to comport with them in the vast majority of use cases, with failure to do so often being considered highly disruptive. But as time goes on, we have more and more of this body of uniform rules. A better system would re-categorize all style guidance into levels of permissibility in a system which roughly shadows the levels of weight seen as between information pages, guidelines, and policies, but such a re-conceptualization would be a herculean effort that I just doubt we even have the manpower for, even if we could get the broad community buy-in to support such a massive restructuring. SnowRise ^{let's rap} 21:56, 3 September 2025 (UTC)[reply]
One thing I think gets lost here is that the process (where was the discussion? Was there a discussion? How many editors? How many experienced editors who haven't been blocked in the intervening years?) is not really as important as whether the policy/guideline/help/whatever page matches what the community wants now. A perfect process, with dozens or hundreds of people, that arrived at the (now) wrong conclusion is not nearly as important as whether the community agrees with that decision today. WhatamIdoing (talk) 03:02, 4 September 2025 (UTC)[reply]
I don't disagree in principle, but even if there is a new established best practice or general unspoken consensus, it's infeasible to allow editors to just assert it as a given; there needs to be a new formal consensus discussion at some level, as otherwise we will just have people insisting upon their own idiosyncratic views about what the "obvious" or "accepted" rule is--assumptions which are subject to every cognitive bias under the sun.
In any event, you are touching upon another factor I had meant to list with the other two above: independent of the degree of formal consensus behind a given rule, or the certitude/universality of the wording of the rule itself, one can also point to the uniformity with which it has been applied. More than once I have seen wording in an MoS section, or even a guideline that it turns out was added despite no WP:PROPOSAL (or any substantial WP:CONSENSUS) process, but by the time this is caught years later, the community is willing to give it a free pass and basically endorse it despite these usual required checks. Either because it turned out to be the right utilitarian approach, or disentangling it from established best practice is more trouble than it's worth.
All that said, I think the "accepted custom" prong of legitimacy ought to be treated as absolutely the least compelling and reliable factor. Not wholly irrelevant, but definitely to be taken with a grain of salt as arguing for the presumption that a given rule is practical or represents community support, express or tacit. SnowRise ^{let's rap} 04:48, 4 September 2025 (UTC)[reply]
It's not feasible to have "a new formal consensus discussion" every time a policy or guideline is reworded.

Most policies and guidelines had no WP:PROPOSAL. I wrote PROPOSAL in 2008. Before then, exactly two (2) of the guidelines and zero of the policies had followed that process (WP:MEDRS and WP:MEDMOS). The original process was "slap a tag on it, and see if someone reverts you". After a while, the process usually became "have a small chat on the talk page, then slap a tag on it, and if someone reverts you, point them at the discussion on the talk page when you revert them back". And quite a lot of WP:Naming conventions, and some of the WP:MOS pages, achieved guideline status through the WP:MOVE button. But at this point, 17 years after the PROPOSAL process was adopted (its adoption being the third time that process was fully followed), and after the massive MOS cleanup project coordinated through Wikipedia:WikiProject Manual of Style (which delisted and rewrote a number of pages), I think we can safely say that anything that is still tagged as a policy or guideline is actually accepted as a policy or guideline. WhatamIdoing (talk) 21:54, 4 September 2025 (UTC)[reply]
I think there's some conflation of concepts going on here. With regard to "a new formal consensus discussion", I personally do not see that as typically involving a full formal WP:PROPOSAL process, or anything remotely like it, as a per se matter. At least for inline changes to existing PAGs or MOS pages, in the vast, vast majority of cases, much less is called for. PROPOSAL is for creating new guidelines wholecloth, not for iterative additions or amendments to existing policies. Nevertheless, I consider it a bit of a tautology that no change to a PAG (nor any other express community guidance codified in MoS or an info page) which has proven contentious can be argued to have a clear "community consensus" unless a consensus discussion actually took place, at some level and in some way endorsing a particular proposition. I appreciate that things were quite a bit more free-wheeling once upon a time, and respect your role in codifying some of our early standards on formalizing consensus at the PAG level (I did not know you were the original author of PROPOSAL, which is quite the contribution to the project's mechanics), but as you yourself alluded, we've come quite a long way since those seeds were planted, and today we have a much higher burden for formally adopting a rule.
As such, the mere act of being able to point to a rule that just happens to not have been disturbed is never going to be the strongest form of evidence that the community has endorsed that principle (or would, if directly asked). Although I will grant you, the farther back the rule stretches without a formal challenge, or the more central the position of the rule in our most heavily relied-upon policies or processes, the more confident we can be in regarding it as a kind of consensus principle. That said, as to ". . . I think we can safely say that anything that is still tagged as a policy or guideline is actually accepted as a policy or guideline., I'm not sure I'd agree that is likely to be universally true, but let's put that to the side for present purposes. That's still a very different thing from saying "Every bit of verbiage placed within a guideline since it was adopted came about as the result of community consensus." And that's an important distinction when we are talking about the MoS in particular, since MoS changes tend to be for the purpose of ammending or adding to existing sections, rather than creating new ones. SnowRise ^{let's rap} 00:16, 5 September 2025 (UTC)[reply]
The elephant in the room is the large number of changes to the MOS. Look at the number of changes to the main MOS page over the last two weeks alone! Hawkeye7 (discuss) 20:44, 5 September 2025 (UTC)[reply]
My immediate coarse intuition is, of course, if an editor sees a substantive, questionable change to P&G without explicit consensus, they would be encouraged to yank that material from production at any time?

(If the initial RfC needs my own variation on this theme: I hope other editors are actively motivated to remove any material that can't be assumed to possess a clear prescriptive mandate – i.e. material possibly not reflective of consensus, explicit or otherwise.) Remsense 🌈 论 23:59, 5 September 2025 (UTC)[reply]
You should only revert changes that you personally disagree with. It's not exactly that we "encourage" people to revert changes, but if you personally believe that a change is harmful or even probably harmful, then yes, you should probably revert it. If you're only a bit uncertain, it's probably better to take it to the talk page. WhatamIdoing (talk) 02:22, 6 September 2025 (UTC)[reply]
That's what I meant to say—in my mind, one could only discern a change could be against consensus if one directly disagrees with it first. Remsense 🌈 论 02:24, 6 September 2025 (UTC)[reply]

I have been reducing my reverts for any editor with a track record of contributions and opting for Talk-first. For many editors reverting is very aggressive and Talk-first often leads to a better outcome. I try to explain reverts for editors who registered, usually "Sorry,...". IP editors with no edit summaries I just revert full stop. Johnjbarton (talk) 02:28, 6 September 2025 (UTC)[reply]
Often the very best move—though, in terms of policy, I would very much prefer and prioritize my disputed additions not being live parts of the document, and I think most experienced editors woudl agree with that too at least in theory. Remsense 🌈 论 03:05, 6 September 2025 (UTC)[reply]
Precisely. We're talking about two distinct subjects here. On the one hand, the more abstract question of whether an addition to a PAG or style section has community consensus, whether it is subject to being summarily reverted, and how much the benefit or problem caused by that change either militates for its retention or reversion. And then on the other hand, the more idiosyncratic question of how a given editor feels about how to address a problematic change that arguably could or should be reverted. When you layer the two over one another, you get a broad range of responses from different community members, but they are in principle discrete questions; the "What is this change, and can/should it be reverted?" and "Now that I've made that decision in principle, how do I really want to go about it to maximize the chance of the optimal outcome, not just with respect to the a priori issue, but also while being constructive and collaborative, and also while keeping other project priorities in mind.
Now, if we wrap back around to your initial question, and contemplate how much we want policy to encourage reversion in those circumstances, I would say we should at least be making the process relatively painless for them, if the change has proven at all contentious and there was no clear consensus. While WP:BRD is mostly conceptualized in the context of namespace contributions, I would say its even more essential when it comes to the language in guidelines: what is codified and memorialized in those pages should be more conservatively approached and should usually only happen with some degree of consensus discussion. Contributors should be discouraged from being WP:BOLD with PAGS or even the MoS. And if they aren't, we certainly want the standard to be that there is very little noise or drama from and objecting party exercising the R&D part of BRD. But I certainly don't fault anyone who would rather exercise a softer touch. Nobody should feel compelled to actively object if it wouldn't normally be their wont in that situation. SnowRise ^{let's rap} 07:57, 6 September 2025 (UTC)[reply]
In short, being prescriptive in principle, the state of a P&G page over time (clearly) has greater stakes than that of any one article, and it seems healthy for whatever quasi-WP:OWN feelings editors may have while working on an article (i suppose, in the sense of "let me cook, watchlist voyeurs") should by contrast be wholly absent when in P&G-space. That sounds super obvious, but whatever. Remsense 🌈 论 08:10, 6 September 2025 (UTC)[reply]
I agree with what SnowRise says above that it's important to distinguish between "Is this MOS page really a guideline?" (to which the answer is 'yes') and "Does this specific paragraph in this specific MOS page still have community consensus?" (to which the answer is variable, because there are a few bits that probably don't).

But @Remsense, it is possible to treat the policies and guidelines as too much like holy writ. If editors think they can improve them, whether that means making them clearer, less verbose, more reflective of daily practices, more in line with our values and principles, etc., then editors actually should try to do that, and be encouraged to do that. Bold editing of policies and guidelines is officially permitted by policy, and the fact is that a change made today and reverted tomorrow probably has no, or very little, effect on what editors actually do. (Though if you wait long enough, it can become a problem; I now wish I had reverted this dubious addition in 2012.) WhatamIdoing (talk) 22:30, 6 September 2025 (UTC)[reply]

We often have consensus on the wording of policies and guidelines, and we often don't have consensus on applications (one of which applications being, ignore). That's just the nature of the work, and then we have to work it out, in the moment. -- Alanscottwalker (talk) 21:24, 7 September 2025 (UTC)[reply]

I would say that for the most part the MOS should be followed unless there's a compelling reason otherwise; but it can be ignored when a stronger policy-based reason exists. Guidelines in general are not absolute (though they vary in how forcefully they're worded), but in particular even the most forcefully-worded parts of the MOS always lose to WP:NPOV / WP:RS / WP:V when those things come into conflict with it, because those things are core policy and the MOS just governs our, well, style; we're not going to sacrifice NPOV for mere stylistic issues. If there is a consensus on a particular article that we must do something that the MOS forbids in order to preserve NPOV or reflect the sources, then the core policies obviously win - there are very few "you absolutely must do XYZ without exception" from-above policies in Wikipedia, and none of them are part of the MOS. That said, I do think that overriding the MOS on anything of significance would normally be expected to require an argument like that, ie. you need some actual policy-based reason to do so - guidelines are followed unless someone can articulate a policy-based reason otherwise. But once someone has articulated a reasonable policy-based reason why they think other policies are in conflict with the MOS, it's a matter for consensus and discussion on that article, and generally speaking I would expect policies to win out. (Of course, people might disagree over whether there's an actual conflict, but that is something that local consensuses can cover, since it involves how we interpret and apply policies and guidelines in specific cases.) In situations where someone disagrees with following the MOS in a particular article but can't come up with a policy-based reason why (ie. it's basically just disagreement with that part of the MOS), they should probably challenge it directly - the point of the MOS is to give us a consistent style, so you need a better reason to override it than "I just like how this looks better." --Aquillion (talk) 15:58, 18 September 2025 (UTC)[reply]
Fun fact: The MOS uses words like "must" and "do not" more than any legal policy. If someone wanted me to show them an example of "you absolutely must do XYZ without exception", the MOS is the first place I'd look.

There is quite a lot about the MOS that cannot be overridden by a content policy. Whether you put the little blue clicky number before or after a sentence's terminal punctuation is not a matter for NPOV/NOR/WP:V. Additionally, if you get it wrong, a bot or a script-wielding editor will soon come along and "fix" it for you. You actually don't have a choice about whether to comply with most of the MOS. It's no good saying "Well, I think there's a compelling reason not to use proper grammar in this sentence, namely that the version approved by English teachers sounds bad to me"; as soon as someone notices the MOS error, MOS:GRAMMAR will be enforced. WhatamIdoing (talk) 22:49, 23 September 2025 (UTC)[reply]
In general PAGs describe practice. It's a bit messier than that, and there are many internal tensions both within and among our PAGs not necessarily a bad thing IMO but that topic would need an essay unto itself. Even when you get one of those big CENT advertised RfCs that really is trying to change the way we do business the specifics of application will still be worked out in practice.
The first thing to keep in mind here is that the MoS is a guideline, so there is an expectation that it will not be implemented rigidly and that exceptions may apply. Local discussions can and sometimes do determine that an overall consensus should not apply in a specific case. The threshold for so doing is not insignificant, but not as difficult to surmount as when policies are in play. Even where policy is also concerned, PAGs are applied to specific situations in practice by contributors through discussion. If a discussion has been open and advertised for some time and there is insufficient support among the community to implement what you might perceive as the global consensus in a specific circumstance, that indicates there is not in fact consensus despite the PAG wording specifics. As always, an active consensus of editors is required to make changes when an action is controversial.
The above is general, but I'm not convinced this latest bout of MoS fracas is even a good-vehicle for reviewing the level of consensus that individual parts of the MoS may or may not have. My own experience is limited and peripheral, but it seems that much of the disputes centered on interpretation of existing verbiage rather than a desire for exceptions per se. How much is substantial? 70%? 80%? How much weight should sampling from various linguistic corpora carry? What about cases where the term usual is employed instead? All of those are cases where reasonable people can and often do disagree. And RMs, around which much of the acrimony was focused, aren't really local anyway but part of a sitewide process where pages are discussed for a week or more to ascertain how PAGs should apply in a specific circumstance. By no means do these discussions carry the same weight as a widely advertised CENT RfC, but they are broader in scope than most talk page discussion and usually include more points of view and participation from a wider swathe of the community.
There were many assertions mostly from since t-banned editors regarding strength of arguement, but as most are doubtless aware, that is normally merely wikilawyer for the outcome was not what I wanted, please change it to my preferred outcome after all we already know you think your argument was the better one, that's why you made it. Numbers also matter if they didn't supervoting would be the way we decided things closers should not be deciding between reasonable interpretations of and between various PAGs, but to summarize which view has the predominant number of responsible Wikipedians supporting it. If an argument fails to sway participants given reasonable time than maybe it isn't all that strong. So sure SPAs, socks, and yes much as I defend their participation clearly clueless newcomers can be ignored, but when good-faith users with an understanding of PAGs support applying them in one way given a specific circumstance or even not applying them in a specific circumstance the closer can't simply ignore them. I understand this made some people with a particular interest in MoS matters unhappy, discontents of this nature are if anything even more common in deletion discussions, but the project has always been a collaborative effort; we all have to work with people who hold different, sometimes even sharply different views.
To address one more point, guideline really is the best classification for the MoS because as a practical matter it is not applied rigidly or uniformly across the project much to the irritation of some I know, local consensus does have a stronger sway over outcomes and there's nothing really wrong with that.
By way of disclosure though I doubt I'm really unrecognized I never really liked the need for an MoS and have long been a WP:STYLEVAR proponent. I also admit that while I don't think there's any good evidence for Wikipedia's (de)capitalization choices having any non-trivial effect on the outside world, I would not lose the slightest amount of sleep over them even if they did. 184.152.65.118 (talk) 23:11, 21 September 2025 (UTC)[reply]

RfC: Bot to add dark mode compatibility to old AfDs

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Should a bot be used to fix linter errors and fix Vector 2022 dark mode on old Articles for Deletion subpages? 16:46, 9 September 2025 (UTC)

Please read this RfC before commenting here. I (Matrix) am proposing a bot to fix dark mode on old AfDs, please read the proposal at the BRFA and comment here whether you support or oppose it.

Courtesy ping to people from last RfC and current BRFA: @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, Primefac, Jonesey95, Sideswipe9th, Levivich, 0xDeadbeef, Redrose64, Wbm1058, Isaacl, Terasail, LokiTheLiar, Zinnober9, Legoktm, TheresNoTime, GreenC, Bruce1ee, Hawkeye7, Mnair69, HouseBlaster, Afernand74, SmallJarsWithGreenLabels, Gonnym, Headbomb, Alsee, DFlhb, NatGertler, Sheep8144402, Novem Linguae, Folly Mox, Pppery, ProcrastinatingReader, Chipmunkdavis, Scott, Anomie, Izno, Choess, SilverTiger12, SMcCandlish, Jayron32, Scottywong, and Tenshi Hinanawi: —Matrix _{ping me}^{when u reply} (t? - c) 18:49, 8 September 2025 (UTC)[reply]

Oppose The chaos involved in making 200,000 edits greatly exceeds the value of this task. * Pppery * _{it has begun...} 18:51, 8 September 2025 (UTC)[reply]
@Pppery: Chaos? Firstly, unlike the above RfC which made millions of edits, this is limited to the WP namespace, so no "user talk was edited" notifications will go off. Secondly, there's a reason the bot flag was created, which was to help you hide stuff in watchlists and stuff like that. —Matrix _{ping me}^{when u reply} (t? - c) 19:13, 8 September 2025 (UTC)[reply]
(I'm copying this from the BRFA) "The question isn't the number of people who use dark mode, it's the intersection of the number of people who use dark mode and who visit old AfDs, and the latter set is pretty small in the first place. And you surely know already that large bot tasks inevitably cause people to complain as they are happening." (from Pppery) —Matrix _{ping me}^{when u reply} (t? - c) 19:17, 8 September 2025 (UTC)[reply]
@Pppery: People scrolling through AfD archives are more likely to have dark mode on, because they are likely power users and power users want all the new features. Besides, we're fixing lint errors along the way. —Matrix _{ping me}^{when u reply} (t? - c) 19:34, 8 September 2025 (UTC)[reply]
I doubt that claim. And consider the entire concept of fixing lint errors to be pointless busywork anyway. * Pppery * _{it has begun...} 19:35, 8 September 2025 (UTC)[reply]
If you don't agree with linter work at all, there's very little I can do to change your opinion about this topic. —Matrix _{ping me}^{when u reply} (t? - c) 20:33, 8 September 2025 (UTC)[reply]

and power users want all the new features. ^{[citation needed]} Anomie ⚔ 21:08, 8 September 2025 (UTC)[reply]
why wouldn't they —Matrix _{ping me}^{when u reply} (t? - c) 22:02, 8 September 2025 (UTC)[reply]
Well, I'm clearly a "power user", and I still use the 2010 Wikitext editor in legacy vector, so clearly not all power users want all of the new features. * Pppery * _{it has begun...} 22:10, 8 September 2025 (UTC)[reply]
To the contrary, power users want the advanced features of Vector2010 like an obvious link to their talkpage. CMD (talk) 01:11, 9 September 2025 (UTC)[reply]
bro its two clicks —Matrix _{ping me}^{when u reply} (t? - c) 16:26, 9 September 2025 (UTC) [reply]

I'm someone who is often regarded as a "power user". I use Monobook skin in light mode and, when I use the source editor (roughly 50% of my edits) I use the 2010 editor. Most "power users" will use whatever tool is the most powerful which is not necessarily the most recent - indeed in many cases the most recent tool is often less powerful because it has been simplified for the benefit of those who are not power users. Whether someone prefers light or dark mode is likely something that is completely independent of whether they're a power user or not. Thryduulf (talk) 01:02, 9 September 2025 (UTC)[reply]
And many other power users will, like me, keep using what they're used to and already have set up how they like it if they don't need any of the new features, instead of changing and having to relearn how to do all the things in the new interface. Anomie ⚔ 13:52, 9 September 2025 (UTC)[reply]

Perhaps, but turning on the bot flag when there's a large activity in the spaces we edit means we're not only missing less frequent bot edits we might want to see, but also are missing recent living creature edits that were immediately followed by a bot edit, as the watchlist system will sometimes not display the human edit when that happens. As such, it's best to avoid the mass edits unless they are necessary. -- Nat Gertler (talk) 19:44, 8 September 2025 (UTC)[reply]

Gotta agree with Wikipedia:Bots/Requests for approval/MatrixBot 2#c-Pppery-20250908024600-Jonesey95-20250908005500 myself. Izno (talk) 19:01, 8 September 2025 (UTC)[reply]
@Izno: I saw you !voted Support on the other RfC. What made you change your mind with this discussion out of curiousity? —Matrix _{ping me}^{when u reply} (t? - c) 19:11, 8 September 2025 (UTC)[reply]
The lint discussed therein has no workaround except fixing. Dark mode has a trivial workaround. Izno (talk) 19:19, 8 September 2025 (UTC)[reply]
@Izno: we're also fixing lint errors in this task as well, which has no workaround except fixing. And while we're fixing the lint error with color: inherit, we might as well convert the background color to the new dark mode one. —Matrix _{ping me}^{when u reply} (t? - c) 19:36, 8 September 2025 (UTC)[reply]
The lint errors of interest being fixed are the dark mode ones, which as I said before has a trivial workaround. Izno (talk) 20:41, 8 September 2025 (UTC)[reply]
@Izno: A workaround which is actively trying to be phased out by the phab task that I have mentioned on BRFA and you are aware of. —Matrix _{ping me}^{when u reply} (t? - c) 21:51, 8 September 2025 (UTC)[reply]
The relevant workaround being the one that targets [style~=background]? I'm the one who suggested that bit of CSS one fateful day several years ago to a relevant engineer as the dark mode effort was beginning to ramp up. I don't see trying to remove the need for that CSS as useful (at this time, perhaps) as there are many many other places that rely on it besides 500k pages worth of archives.

That phab task has little to do with this concern IMO, so I'm a bit puzzled about why you're citing it here. Izno (talk) 22:05, 8 September 2025 (UTC)[reply]
@Izno: we need to move away from relying on that CSS rule, which is why I am suggesting this. We don't need to remove the rule, but just reduce reliance on it, as it is quite crude. This is one step at that. —Matrix _{ping me}^{when u reply} (t? - c) 22:48, 8 September 2025 (UTC)[reply]
Oppose Peppery nails it. : Headbomb {t · c · p · b} 19:01, 8 September 2025 (UTC)[reply]
Oppose per Pppery and Nat Gertler. Editing archives should only ever be done when the edit makes a substantial improvement to the project in some way. Making nearly half a million edits just so that a bit of form text that appears on >90% of AfDs is slightly more visible to the tiny number of people who read old AfDs while using dark mode is so far below that bar it's ridiculous. Even fixing lint errors fails to reach the bar most of the time and this is significantly less useful than that. Thryduulf (talk) 20:46, 8 September 2025 (UTC)[reply]
@Thryduulf: this is a lint error, read the BRFA. —Matrix _{ping me}^{when u reply} (t? - c) 21:49, 8 September 2025 (UTC)[reply]
A lint error that only appears in dark mode? You really need to do better to explain why this should be "fixed" and why it is worth doing more than 50 edits. —Kusma (talk) 22:19, 8 September 2025 (UTC)[reply]
@Kusma: you seen very very confused. The lint error is also present in light mode, as lint errors don't magically disappear based on client state, please read mw:Help:Lint errors/night-mode-unaware-background-color. Currently all AfDs before 2024 are broken in Vector 2022 dark mode, which is the default skin. —Matrix _{ping me}^{when u reply} (t? - c) 22:38, 8 September 2025 (UTC)[reply]

@Matrix, if this is a lint error worth fixing then there will be consensus for the lint error fixing bots to fix it. You will also note that I said Even fixing lint errors fails to reach the bar [where editing archive pages is beneficial to the project] most of the time and this lint error is especially low value. Thryduulf (talk) 00:57, 9 September 2025 (UTC)[reply]

Also, please stop bludgeoning this discussion. You've made your case already; you don't need to reply to every single comment in opposition. * Pppery * _{it has begun...} 06:28, 9 September 2025 (UTC)[reply]
@Pppery: Considering this is a very technical topic it is necessary to explain a bit more - that is not bludgeoning and is actually constructive towards consensus. I only responded to like 3 comments anyway, and I don't expect to change anyone's view if they are opposed. See Wikipedia:Encourage full discussions. —Matrix _{ping me}^{when u reply} (t? - c) 16:23, 9 September 2025 (UTC)[reply]
You've made 17 comments here, which is only slightly fewer comments than all other editors combined. That's clearly bludgeoning. * Pppery * _{it has begun...} 16:34, 9 September 2025 (UTC)[reply]
I got taught counting in reception. Every comment of mine is distinct, from discussing technical issues with Izno to clearing misconceptions about the lint tool. Again, Wikipedia:Encourage full discussions. —Matrix _{ping me}^{when u reply} (t? - c) 17:06, 9 September 2025 (UTC)[reply]
Support I don't use dark mode myself but looking at the before and after examples linked on the BFRA, it improves things for those using dark mode. Also, doesn't hurt things for anyone not using dark mode, so don't see any reasons not to. If someone is willing to do those changes then why not. -- WOSlinker (talk) 21:28, 8 September 2025 (UTC)[reply]
Support per WOSlinker and what Primefac said on the BRFA. It doesn't really hurt anyone, those concerned about watchlist spam can just configure their settings to ignore bot edits. Tenshi! (Talk page) 22:13, 8 September 2025 (UTC)[reply]
er, what is the improvement being made? It looks pretty much the same to me (at least in Monobook Dark mode) so oppose unless it is clarified what the point is. —Kusma (talk) 22:15, 8 September 2025 (UTC)[reply]
@Kusma: no, vector 2022 dark mode/minerva dark mode, i.e. the default skins. This also fixes lint errors fyi —Matrix _{ping me}^{when u reply} (t? - c) 22:34, 8 September 2025 (UTC)[reply]
If this appears only in some skins, just fix the skins. —Kusma (talk) 02:55, 9 September 2025 (UTC)[reply]
Support: I don't personally think linter errors are a huge priority, but that doesn't mean others should be prevented from fixing them. The set of people who have old AfDs on their watchlist for some reason and could possibly be inconvenienced is probably as small, if not smaller, than the set of people who view old AfDs in dark mode. Gnomingstuff (talk) 23:22, 8 September 2025 (UTC)[reply]
I am in generally in support, but if you're going to make this many edits I'd like to see a deeper investigation of what other kinds of issues can be fixed at the same time. Also seems like it would be more worthwhile to replace it with a template so we don't need to make a second pass if other issues are discovered in the future. Legoktm (talk) 00:08, 9 September 2025 (UTC)[reply]
@Legoktm: that would be a good idea, but if we did that we would also need to do the same thing for all XfD discussions, plus all RMs, most {{atop}}s, etc. Not to mention the massive technical issue of fixing nearly every single anti-vandalism tool. I don't think that's worth it. —Matrix _{ping me}^{when u reply} (t? - c) 16:25, 9 September 2025 (UTC)[reply]
I don't think we need to decide the fate of literally everything now just to improve AfD archives, it can be an iterative process. I also don't see why anti-vandalism tools need to be fixed, why would they even care about this formatting change? Legoktm (talk) 17:55, 9 September 2025 (UTC)[reply]
If we use a template now, don't we have to use the template in the future? I feel it would be inconsistent to sometimes use a template and sometimes subst stuff. —Matrix _{ping me}^{when u reply} (t? - c) 18:27, 9 September 2025 (UTC)[reply]

I was going to make this an RfC from the start to avoid LOCALCONSENSUS issues, but forgot. Also as proposer and the person who made the BRFA, I support obviously. —Matrix _{ping me}^{when u reply} (t? - c) 16:46, 9 September 2025 (UTC)[reply]

Oppose per Pppery and others. Also that this is a lint error doesn't necessitate so many changes to so many archives. -- LCU ActivelyDisinterested «@» °∆t° 21:12, 9 September 2025 (UTC)[reply]
Support. I really don't see any downsides to this. But, as someone who regularly reads old AfDs, sometimes uses dark mode, and generally appreciates that linter issues can be important in the long run, I think there would be significant benefits. Toadspike [Talk] 06:54, 10 September 2025 (UTC)[reply]
Oppose as it would be too much of a hastle Jcoolbro (talk) (c) 13:26, 10 September 2025 (UTC)[reply]
Hassle how? Please explain. Tenshi! (Talk page) 13:32, 10 September 2025 (UTC)[reply]
Oppose: Similar to WP:RAGPICKING: we all have better things to do than make miniscule formating tweaks to old pages for a minority of users. If hundreds of editors were coming forward and saying "I use dark mode and this is a real pain", then I'd support. But I'm not seeing that. I honestly don't understand what a lint error is, but this one seems to be pretty minor (replacing standard inline CSS with something complicated). Cremastra (talk · contribs) 20:21, 10 September 2025 (UTC)[reply]
MFDs time away from other people. This takes time away from the one person who has volunteered to do the work, not the community. House Blaster (talk • he/they) 01:29, 11 September 2025 (UTC)[reply]
Full Support: Accessibility improvements should never rejected on the basis of "it inconveniences my watchlist" or "I don't use this feature", it should pass or fail on the merits and benefits of the task proposed and the proof of the task will address the issue as intended with minimal to no error rate if run. To those complaining about "well, it don't look broken in light mode", this task isn't for fixing something in light mode and will not affect your light mode viewing, this is for fixing a glaring problem in dark mode that makes viewing AFDs in dark mode problematic. The claims of "well, I don't use dark mode, don't run this task" are an injustice to users who do use dark mode who have to endure being blinded on AFD pages from these sections not displaying as they should. If Wikipedia offers different viewing modes, all pages should work and display correctly in all modes.
To highlight the proposed change in a visual manner so that there's no question what this task is changing, This -> https://i.imgur.com/Fch83DD.png is an AFD page in dark mode with no changes and is a prime example of this error. The page should NOT be mostly white in dark mode, it should be uniformly dark and comfortable to view without feeling like you are staring at an approaching car's highbeams at night. After this task runs, it would look like this -> https://i.imgur.com/Gw40Qfc.png for dark mode users and behave as it should. The suggestions of "just use light mode, there's no issues here" are as obnoxious as me stating to you "Dark mode is only a few clicks away, why aren't you using it as it's easier on the eyes"?... We both know we have reasons for picking light mode or dark mode as our mode of choice, and we just want pages to display correctly as much as you do with as minimal bother to you as possible. This is a small step in the equal display direction.
Additionally, ditto WOSlinker, Primefac, and Legotkm's comments about can we fix anything else in this run to minimize the AFD pitchforks, and why isn't this a template we transcribe? Seems problematic that it isn't due to standard "woe is my watchlist" kerfuffle whenever corrective tasks regarding AFDs are mentioned. Zinnober9 (talk) 21:28, 10 September 2025 (UTC)[reply]
Support per Zinnober9. Further to Legoktm's point, I would support adding __NOINDEX__ to all AFDs while we are at it. We discovered that our attempt to do this site-wide is not working last December, but we didn't actually come up with a plan to fix it. I think the idea of transcluding a template (maybe just add {{AFD help}} where it is not already present?) is a great one, so we can easily make updates if needed in the future. Don't want to spend time on this? You don't have to code the bot or worry about what it will do. House Blaster (talk • he/they) 01:29, 11 September 2025 (UTC)[reply]
In case people wonder why robots.txt does not work, from Google themselves: Don't use a robots.txt file as a means to hide your web pages... If other pages point to your page with descriptive text, Google could still index the URL without visiting the page. – robertsky (talk) 03:57, 11 September 2025 (UTC)[reply]

support per Houseblaster. Let's take this opportunity to fix several issues together. – robertsky (talk) 03:58, 11 September 2025 (UTC)[reply]

Support although it should be noted that the only thing that needs to happen is "unblending" i.e. figuring out which color mixed with white in which alpha amount results in the resulting color. These are very minor but important changes to improve legibility in dark mode. Aasim (話す（はなす）) 21:00, 11 September 2025 (UTC)[reply]

Support. I'd probably be considered a "power user", I do peruse old AFDs, and I want to use dark mode. However, I don't use dark mode anymore because too much doesn't work well in it. Anything automated process that can make the dark mode experience better, I'm all for it. ~Anachronist (talk) 01:32, 22 September 2025 (UTC)[reply]

support I like to browse old AFDs for the sake of it, and having dark mode would be useful as otherwise I'd have to use the dark reader extension. 82.32.162.149 (talk) 16:42, 28 September 2025 (UTC)[reply]

Support. I use dark mode for everything, and I'm an admin. Sometimes questions arise about why a page was deleted and I have to go back and read AFD archives. Or often I'm checking back to see the outcome of a discussion I participated in (it's unfortunately not possible to subscribe to these discussions). Whenever I run into a dark mode problem on a page, I feel it's my duty to preserve accessibility for other users (and my sanity) to either figure out how to fix it or file a complaint if it's too complicated. This is not something I'd be able to fix on my own and I'd have to request a bot run and...well, someone has already done that part and that's where we are now. As dark mode becomes more popular, more people will be affected and it would be nice to avoid wasting everyone's time with duplicate complaints, and just fix this now. -- Beland (talk) 19:56, 2 October 2025 (UTC)[reply]

Replacing with a template?

Creating a separate discussion, since a lot of supports seem to be stating that I should replace the whole thing with a template, rather than just changing the CSS values. Any input is appreciated —Matrix _{ping me}^{when u reply} (t? - c) 17:08, 11 September 2025 (UTC)[reply]

Neutral as original proposer. I don't have any strong views on this, and am willing to do whatever the community's view on this is. —Matrix _{ping me}^{when u reply} (t? - c) 17:08, 11 September 2025 (UTC)[reply]

Ok, no one replied to this; there are a few other tasks that can be done on the journey, what's the consensus on doing those as well?

"un-subst" the template, so that future edits can be made at once, rather than on all ~495K pages
add NOINDEX to prevent indexing by search engines (because apparently robots.txt doesn't work)

If you guys have more ideas I can do on the way let me know. @Primefac, Pppery, Jonesey95, Izno, Headbomb, Thryduulf, Kusma, WOSlinker, Tenshi Hinanawi, Gnomingstuff, Legoktm, ActivelyDisinterested, Toadspike, Jcoolbro, Cremastra, Zinnober9, HouseBlaster, Robertsky, and Robertsky: (sorry for the mass ping, but I want a clear consensus on this so I know exactly what to code if this is successful) —Matrix _{ping me}^{when u reply} (t? - c) 20:43, 18 September 2025 (UTC)[reply]

Support unsubst (so we don't have to do this ever again) and support NOINDEX (while we can argue about the efficacy of dark mode fixes, I hope we can agree that NOINDEXing discussions, including those about BLPs, is a worthwhile pursuit). Probably a better idea to just unsubst and then do the dark mode and NOINDEX fixes in the unsubsted template. House Blaster (talk • he/they) 20:47, 18 September 2025 (UTC)[reply]

Support both as generally good ideas. I can see no reason a boilerplate header/footer that could foreseeably need updating should be substed every time, and these pages do not need to be indexed. Toadspike [Talk] 20:52, 18 September 2025 (UTC)[reply]

Support switching to the template in general, I don't have the relevant context on NOINDEX so I'll abstain from commenting on that. In general I disagree with Pppery that doing some cleanup isn't worth it just because the task is significantly large (I appreciate people who are willing to take on such gargantuan tasks!). Legoktm (talk) 00:41, 19 September 2025 (UTC)[reply]

I Support replacing the boilerplate with a template after a sufficient set of demonstration edits on AfDs from many different years. I have found while editing (far too many) AfD and similar pages to fix Linter errors that there are sometimes subtle variants on these bits of text that one presumes would be identical. Also, the boilerplate text sometimes gets edited after it is placed. It might take a few runs to find the variants, and a bot task might only be able to handle 90+% instead of 99+% of them. Ideally, they won't contain elements that need different template variants to replace them. – Jonesey95 (talk) 21:12, 18 September 2025 (UTC)[reply]

I continue to oppose running a bot to make edits to every single AfD, regardless of what specific tasks the bot does. * Pppery * _{it has begun...} 21:43, 18 September 2025 (UTC)[reply]

So are you saying that you support the unsubst that would eliminate future needs to updating AFD pages directly whenever these boilerplates need an update in future years? Or are you rejecting any and all bot tasks on any AFD page? Please clarify your ambiguous statement. Zinnober9 (talk) 22:19, 18 September 2025 (UTC)[reply]

I don't see the ambiguity here; but to restate my position, I reject any and all bot tasks that would require editing all hundreds of thousands of AfDs (or pretty much hundreds of thousands of pages of any kind as a one-time run; note I also opposed the reflist bot above). * Pppery * _{it has begun...} 04:20, 19 September 2025 (UTC)[reply]

If we were going to have a bot editing the ~half million AFD pages (40% of the namespace?), I want it to move them to a different namespace, so I can search in the Wikipedia: namespace and not have the results filled with old AFDs. WhatamIdoing (talk) 22:54, 23 September 2025 (UTC)[reply]

FYI, you should be able to add -prefix:Wikipedia:Articles_for_deletion/ to your search to exclude those pages. Anomie ⚔ 01:12, 24 September 2025 (UTC)[reply]

And I do, but I might prefer not to bother. WhatamIdoing (talk) 04:42, 26 September 2025 (UTC)[reply]

Does anyone know why it has been substed since 2004 in the first place? Anomie ⚔ 21:53, 18 September 2025 (UTC)[reply]

Skimming through some very old discussion archives, I've come across a few mentions that now go against WP:Don't worry about performance and others that are similar to what Thryduulf mentions below in saying opposed to boilerplates not being substed going forwards because care will have to be taken to ensure that changes don't state or imply things that were not true at the time of old AfDs. There may be other discussions I haven't found. Anomie ⚔ 02:21, 19 September 2025 (UTC)[reply]

Personally, so far I'm leaning towards an oppose on the unsubsted template idea based on the "historical record" point. I'm not much caring about fixing versus not-fixing the inline CSS in the archives, since I doubt both that many will care that much about old AfDs while not being able to work around the possible contrast issue and that many will be paying enough attention to the old AfDs that a bot going through them actually matters (as long as we don't get another MalnadachBot situation). Anomie ⚔ 02:21, 19 September 2025 (UTC)[reply]

I get you kind of, but I'm not really sure any historical records would be changed, since the rendered text would be pretty much the same. —Matrix _{ping me}^{when u reply} (t? - c) 15:26, 19 September 2025 (UTC)[reply]

Currently the rendered text might be "pretty much" the same, but with a transcluded template there is no guarantee at all that this will always be the case. Thryduulf (talk) 16:19, 19 September 2025 (UTC)[reply]

@Thryduulf: Well, one very simple solution to that is making maybe something like {{Afd top/old}}, deprecate it for further use, protect that template and never touch it again. —Matrix _{ping me}^{when u reply} (t? - c) 17:34, 19 September 2025 (UTC)[reply]

At that point you might as well just subst it. You'd have to create a new template for every change in the wording, and then get everyone to switch to the new one each time. Thryduulf (talk) 17:40, 19 September 2025 (UTC)[reply]

But if you subst the template you get stupid problems like this later on (what if the WMF decides in 10 years they're gonna make a high contrast mode, for example?) —Matrix _{ping me}^{when u reply} (t? - c) 19:36, 19 September 2025 (UTC)[reply]

I think that is unlikely because many operating systems have their own high contrast mode or something like color filters. Aasim (話す（はなす）) 21:01, 19 September 2025 (UTC)[reply]

It was just an example; no one could have predicted dark mode 10 years ago. We can't predict the future, so a template could be adjusted normally, that was my point. —Matrix _{ping me}^{when u reply} (t? - c) 16:09, 20 September 2025 (UTC)[reply]

Although it's a bit of a side note, dark modes have been implemented long before that (though support for web browsers to automatically follow an OS setting is newer). The problem is on the web design side, where there hasn't been a standard palette established for use on English Wikipedia. To be fair, CSS variables and to some extent template styles make deploying a standard palette that can be adjusted by skins much simpler.

The purpose of substituting a template is to ensure that a specific snapshot of how it appears is captured, which is needed to help trace historical discussion. To facilitate future changes to style, in theory an outer wrapper template could set up styling and then substitute an inner template with the content. But to be honest I think the negatives of making the templates less accessible to potential maintainers outweigh the potential future positives. isaacl (talk) 16:57, 20 September 2025 (UTC)[reply]

If, at some point in the future, this same non-problem arises then we can deal with it the same way we should be dealing with this one: not fixing something when the cost of the fix is many orders of magnitude greater than the cost of the status quo. If, at some point in the future, an actual problem arises where the cost of fixing it is lower than the cost of not fixing it, then at that future time we should fix that actual problem. Until then, let's not base our decision making on vague speculation about future problems that have a low probability of ever existing and an even lower probability of actually justifying costly action. Thryduulf (talk) 23:18, 19 September 2025 (UTC)[reply]

I continue to oppose these essentially cosmetic changes to old AfD pages because the value of them is multiple orders of magnitude lower than the disruption the bot will cause (and regard this discussion following the extensive objections above to be rather tone deaf at best). I don't necessary oppose all future changes to old AfD pages, because I don't know what those changes will be, but will oppose any others that don't provide benefit to the project above and beyond the disruption. I'm weakly opposed to boilerplates not being substed going forwards because care will have to be taken to ensure that changes don't state or imply things that were not true at the time of old AfDs. For example if a new rule required everyone who had contributed to the article being discussed to explicitly disclose that, and this was added to the boilerplate, it would be misleading for that to appear on discussions from before the rule was introduced. Thryduulf (talk) 22:33, 18 September 2025 (UTC)[reply]

@Thryduulf: Well, 10 people supported and 7 opposed, so I find your accusation of being "tone deaf" quite puzzling; clarification on that allegation would be helpful. —Matrix _{ping me}^{when u reply} (t? - c) 15:23, 19 September 2025 (UTC)[reply]

There wasn't any consensus that this was a desirable thing - almost none of the supporters actually engaged with reasons to oppose (which were opposed to the concept not the implementation) - so just continuing on as if doing something like this is self-evidently a good idea is what feels tone deaf. Thryduulf (talk) 16:17, 19 September 2025 (UTC)[reply]

I think the consensus among "support"s is "make an exclusion for MatrixBot" or "don't look at bot edits". I don't use my watchlist anyway so I'm not that familiar with how it works. Also, if there's an alternative solution that doesn't mess up your watchlist but still solves the problem(s) at hand feel free to let me know. —Matrix _{ping me}^{when u reply} (t? - c) 17:38, 19 September 2025 (UTC)[reply]

The solution is don't waste everybody's time with mass trivial changes to fix problems that don't need fixing. Thryduulf (talk) 17:42, 19 September 2025 (UTC)[reply]

I do not support replacing <span style="color:red;">'''Please do not modify it.'''</span> with a template. There isn't much value in trying to make this particular message more legible, and with banner blindness, most people will never pay any attention to it.

I am more ambivalent about changes to specify the background colour, whether that is by introducing a template, or changing the hardcoding. In principle I think it is a good idea to make all pages follow dark mode standards. But I understand that churn to so many pages can be unappreciated by those most involved in the articles for deletion process. The gentler approach is to just continue with new discussions supporting dark mode, and at some point in the future, when the discussions supporting dark mode are the large majority, consider if a change should be made then. isaacl (talk) 23:28, 18 September 2025 (UTC)[reply]

@Isaacl: whilst I understand your first point, if we're going to have a template "afd top", we need an "afc bottom". We might as well do that while we're at it. —Matrix _{ping me}^{when u reply} (t? - c) 15:24, 19 September 2025 (UTC)[reply]

To clarify, I disagree with replacing the text at the top of articles for deletion discussions with {{Afd top}} solely for the purpose of changing how the "Please do not modify it" message appears. With regards to replacing the text in order to change the background colour, I appreciate the concerns of those most involved in the process, including how the text will no longer be a snapshot of what appeared at that time. I'm indifferent about replacing the closing </div> with the {{Afd bottom}} template. isaacl (talk) 15:44, 19 September 2025 (UTC)[reply]

Support transclusions per Jonesey95. Substituting these has never made sense to me, and doubly so in regards to the ubiquitous AFD pitchforking. If someone knows why they were substituted, then I'm open to considering the merits of that reasoning. But converting to transclusion would reduce the future bother to the Afd community from the known knowns at hand so far in this AFC. I agree that variants (if any) should be identified, and any variants' adjustments retained. I'm Indifferent on the Noindexing. I don't have a grasp on the ins and outs of that at this point to have a strong vote, but I don't object. Overall I think we all agree that the AFDs should be left alone as much as possible, but how or to what point looks to be the meat of this discussion. Zinnober9 (talk) 00:13, 19 September 2025 (UTC)[reply]

Oppose per Thryduulf. Templates are generally somewhat problematic in archives, let's not make this worse. —Kusma (talk) 18:36, 19 September 2025 (UTC)[reply]
Support per Jonesey95. Consistency is generally better here, and we wouldn't need to have another bot run to replace the text if another issue comes up with it later. Tenshi! (Talk page) 15:01, 23 September 2025 (UTC)[reply]
Except that consistency would come at the price of accuracy whenever changes are made to the meaning. Do you regard that as an acceptable tradeoff, because I absolutely do not. Thryduulf (talk) 15:07, 23 September 2025 (UTC)[reply]
I would regard that as an acceptable tradeoff, yes. Tenshi! (Talk page) 15:26, 23 September 2025 (UTC)[reply]
Support. Subst:ing templates makes me nervous for exactly this reason. It would be nice to put in a template, even an archived one, to prevent having to make a huge bot run in the future just to keep these archives functional. -- Beland (talk) 19:56, 2 October 2025 (UTC)[reply]
Support per Beland. -sche (talk) 22:12, 2 October 2025 (UTC)[reply]

Directing new users to essays on the top of policy and guideline pages

I see Template:Simple has recently been placed at the top of some policy and guideline pages. Are we sure we want to direct new users to unvetted info pages off the bat like this.... that in my view are leading them to the wrong type of pages in some cases. For example at Wikipedia:Content assessment we link a readers' FAQ page Help:Assessing article quality that is designed for non-editing readers. At Wikipedia:Deletion policy a page about rationale and how to go about the process we link Wikipedia:Why was the page I created deleted? a page about what you can do about a deleted page. Not sure if these links have been well thought out. Wondering if we should have a chat before this is added to more policy and guideline pages? Linking simpler help pages from long-winded help pages make sense... I'm just not sure linking these types of pages from policies and guidelines are appropriate in the fashion that they're presented at the top of the page as if these linked pages have been vetted by the community makes sense. Moxy🍁 22:31, 13 September 2025 (UTC)[reply]

These simplified pages should be merged into the real pages. If the real page is too steep, change it. Johnjbarton (talk) 23:04, 13 September 2025 (UTC)[reply]

Not sure merging simplified essays into policies and guidelines pages would be beneficial or pass muster. My main concern is are we and should we direct new users to loosely related essay pages from policy and guideline pages off the bat that currently stand out in big bold letters.Moxy🍁 23:09, 13 September 2025 (UTC)[reply]

I've not looked at any of the examples yet, but really nobody should be adding prominent links to the top of (especially fundamental) policy pages without at least discussing it first. I don't know that it needs to be a full-on consensus discussion unless there are substantive objections, but there needs to be at least some agreement from talk page watchers that the other page is relevant, appropriate and helpful. Thryduulf (talk) 23:32, 13 September 2025 (UTC)[reply]

I don't love this, but I think this is probably not a bad thing, overall.

First, before anyone panics, this is only on about two dozen pages, and I think that it's only on two official policies:

Wikipedia:Policies and guidelines, where the template points to Help:Introduction to policies and guidelines – hardly some backwater, unvetted page, since it gets 4K page views a month, is in a couple of welcoming templates, and is part of the Wikipedia:Tutorial.
Wikipedia:Deletion policy, where the template points to Wikipedia:Why was the page I created deleted?

Second, most of the uses point towards popular pages. For example, at Wikipedia:Inline citation, it points to the ever-popular WP:REFB. At Wikipedia:Talk page guidelines, it points to Help:Introduction to talk pages. At Wikipedia:Conflict of interest, it points to WP:PSCOI.

The pages it points to are generally community favorites, and there is no reason to believe that any of these links were snuck on to the pages without anybody noticing. And frankly, in the case of pages like Help:Table (5754 words "readable prose size", except most of it is not readable by ordinary humans), most editors actually should be looking at a much simplified page. WhatamIdoing (talk) 02:11, 14 September 2025 (UTC)[reply]

I read your argument as "these linked pages are de-facto approved pages". Under that condition, of course it is fine. Maybe these simple pages should be the main pages and the current main pages need converted to specialized instructions? Johnjbarton (talk) 02:30, 14 September 2025 (UTC)[reply]

We can't really "replace" the pages. They aren't interchangeable. For example, Wikipedia:Inline citation exists to explain what an inline citation is and isn't. WP:REFB exists to help newbies figure out how to format the most popular kind. If you moved REFB at the name "Inline citation", we'd just have to create another page that explains that ref tags aren't the only kind of inline citation ...and a newbie would still end up at that page when they really just need something that says "copy and paste this wikitext", and we'd get another note at the top saying that if you're not really looking for details, then there's a simpler instruction page that you might want to look at instead. WhatamIdoing (talk) 04:16, 14 September 2025 (UTC)[reply]

Specifically regarding Help:Introduction to policies and guidelines, the message box added at the top of Wikipedia:Policies and guidelines is misleading: the help page is not a simplified version of the policies and guidelines page. I didn't raise it for discussion, though, as I felt it was probably useful to have a link to an introduction, and that most people wouldn't care that the description was inaccurate. isaacl (talk) 07:07, 14 September 2025 (UTC)[reply]

This is not a good template idea, agree with Johnjbarton. Our policies and guidelines are, when not simple, not so for a reason. We should not give alternative wording official sanction unless it has this. Simultaneously, if there is an obvious way to simplify the policies and guidelines, it should be done on the actual pages. Perhaps we might link to essays that oversimplify the relevant pages, which could have some use for new users who want the basics that won't land them in trouble, but these should clearly be marked as oversimplifications. CMD (talk) 02:51, 14 September 2025 (UTC)[reply]

Do you think that it's inappropriate for Wikipedia:Inline citation (which is not a guideline or policy) to have a prominent link at the top to Help:Referencing for beginners (which is also not a policy or guideline)?

Relative to most newbies' needs, do you think that WP:REFB should be labeled "an oversimplified version" of anything? I think "a simplified version" is a fairer description, though "Are you new here? Start with WP:REFB" would work for me. WhatamIdoing (talk) 04:20, 14 September 2025 (UTC)[reply]

Yes, that's clearly inappropriate as Help:Referencing for beginners is not a simplified version of Wikipedia:Inline citation. It's a lie right at the top of the page. CMD (talk) 09:13, 14 September 2025 (UTC)[reply]

So you wouldn't want us to apply your advice that "these should clearly be marked as oversimplifications" to this instance. WhatamIdoing (talk) 21:13, 14 September 2025 (UTC)[reply]

Well no, because that would also be a misleading lie? What is the purpose of this question? CMD (talk) 02:36, 15 September 2025 (UTC)[reply]

You said these should clearly be marked as oversimplifications. But you don't want us to label a link to REFB as being an oversimplification, because calling REFB an oversimplification would be a misleading lie. These statements are superficially self-contradictory, but I think you're right.

I think we have two separate questions to answer:

Do we want to have links/hatnotes/banners/templates that direct inexperienced editors away from complicated pages, towards simpler/more relevant pages?
If so, how should we describe those links? You dislike the "simplified version" language (for understandable reasons). "Oversimplified" is IMO even worse. Maybe something like "If you're new to editing Wikipedia, you may want to start at _____" would be better.

WhatamIdoing (talk) 16:15, 15 September 2025 (UTC)[reply]

The statements are not contradictory. The first statement was a general one premised on the good faith assumption that the items under discussion being presented as simplified versions are simplified versions. The second statement relates to a specific example raised after that first statement where the item presented as a summary was not a summary but rather a general guide of a related topic. CMD (talk) 16:19, 15 September 2025 (UTC)[reply]

Would I be right in thinking that many of these were added by FaviFake? The one at Wikipedia:Content assessment certainly was. --Redrose64 🌹 (talk) 16:19, 14 September 2025 (UTC)[reply]

[1], [2], [3], [4], [5], [6], [7], [8], [9]. —Fortuna, imperatrix 16:36, 14 September 2025 (UTC)[reply]

See User talk:Redrose64#Time sink, which involved Primefac and Jonesey95. --Redrose64 🌹 (talk) 17:11, 14 September 2025 (UTC)[reply]

Ah, and which links to that ANI. I see a WP-space TB somewhere around the corner, as they don't seem to have learned from it. —Fortuna, imperatrix 17:20, 14 September 2025 (UTC)[reply]

Just since I was pinged, yes, I do disagree with Favi doing this, but since I did not see much in the way of reverts, and they're not terrible additions, I have mostly left them be. Primefac (talk) 17:32, 14 September 2025 (UTC)[reply]

By the way, we do have a mechanism to differentiate between a random essay and a broadly accepted consensus supplement for policy/guideline pages - WP:SUPPLEMENTAL with the pages that are broadly agreed upon by the community being tagged with it and are part of Category:Wikipedia supplemental pages.

So maybe the question is whether any how-to pages that are linked at the very top of a policy guide using the {{Simple}} template should also mandatorily have been evaluated to qualify similarly for supplemental status (over just being a regular info/how-to page), since that seems to be kind of the bar for such articles that are tagged with {{Supplement}} and linked at the policy section, e.g. WP:LOWPROFILE supplement being the supplement to WP:BLP - WP:NPF - Non-public figure policy - the supplement has broad consensus and is de-facto policy on how we assess whether someone qualifies as public figure or not. Raladic (talk) 02:29, 19 September 2025 (UTC)[reply]

But surely anyone can anytime declare that a favoured essay is an info page? Peter Gulutzan (talk) 18:47, 22 September 2025 (UTC)[reply]

Yes, but in practice, that isn't done often, and only 'sticks' if the page is low traffic. Otherwise, someone who disagrees will revert it. WhatamIdoing (talk) 23:05, 23 September 2025 (UTC)[reply]

Also: Being 'an info page' or 'a how-to page' doesn't provide the page with any special status. It's supposed to signal that the page has practical value. Read some essays if you want to know some opinions about why we add sources; go to a how-to page if you need to know what wikitext code to type to get the little blue clicky numbers to show up in the article. WhatamIdoing (talk) 23:12, 23 September 2025 (UTC)[reply]

I don't know you know how often it's done, and don't see the point of reverting since the people who watch the essay will include people who think the essay is worthwhile, and will therefore be likely to revert the reverter. However, I missed that the argument is not that info pages have special status but that supplement pages do. I guess. Peter Gulutzan (talk) 16:11, 29 September 2025 (UTC)[reply]

Nominally, supplement pages have same status as an essay. In practice, many of them have "the same status as an essay such as WP:BRD", rather than "the same status as the average essay". WhatamIdoing (talk) 21:07, 29 September 2025 (UTC)[reply]

There is no shortcut to user page

Not a matter of policy or for this noticeboard. Star Mississippi 01:51, 16 September 2025 (UTC)[reply]

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.

On the top-right, there is a button where you can quickly go to your homepage, talk, sandbox, and others. Why is there no option for a user page? ~Rafael (He, him) • talk • guestbook • projects 23:07, 15 September 2025 (UTC)[reply]

For accounts that were created before the deployment of the newcomer home page, the target destination when clicking on your user name on the top right is your user page. The WMF decided that to repurpose the link to access the newcomer home page, and your user page can be accessed from there. The behaviour can be configured on the preferences page: Preferences → User profile → Newcomer editor features →

Display newcomer homepage. However disabling it also disables your homepage. isaacl (talk) 00:08, 16 September 2025 (UTC)[reply]

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.

Is the WMF being paid to come up with stupid things to do? Because something this idiotic should have gotten someone fired.--User:Khajidha (talk) (contributions) 17:21, 21 September 2025 (UTC)[reply]

@Khajidha: what? I don't understand... ~Rafael (He, him) • talk • guestbook • projects 23:07, 21 September 2025 (UTC)[reply]

@Khajidha: you don't want a useful feature that actively helps newcomers join this website? —Matrix _{ping me}^{when u reply} (t? - c) 17:28, 26 September 2025 (UTC)[reply]

Help joining the website should not introduce differences from how the site is experienced by established users. --User:Khajidha (talk) (contributions) 10:44, 27 September 2025 (UTC)[reply]

Agreed on both points. ―Mandruss ☎ IMO. 12:55, 27 September 2025 (UTC)[reply]

@Mandruss and @Khajidha so uh... are we going to do something? ~Rafael (He, him) • talk • guestbook • projects 12:56, 27 September 2025 (UTC)[reply]

Like what? Try to get WMF to reverse the change? Not I. ―Mandruss ☎ IMO. 12:58, 27 September 2025 (UTC)[reply]

@Mandruss i don't know! It seems you were going to do something... ~Rafael (He, him) • talk • guestbook • projects 13:00, 27 September 2025 (UTC)[reply]

It does? Because I said Agreed on both points? The only thing I'm planning to do is return to causing trouble at Donald Trump lol. If someone wants to spearhead a move for reversal, and I'm aware of that, I'll be there to support them. ―Mandruss ☎ IMO. 13:03, 27 September 2025 (UTC)[reply]

Yeah... oh wait you once reverted my edit at Donald Trump lol... ~Rafael (He, him) • talk • guestbook • projects 13:05, 27 September 2025 (UTC)[reply]

RFC: Alphabetical listing of all Olympians

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There was a clear consensus here that an alphabetical listing of all Olympic competitors does not meet the criteria for inclusion for a list and was contrary to the idea that Wikipedia isn't a directory. —Matrix _{ping me}^{when u reply} (t? - c) 16:38, 3 October 2025 (UTC)[reply]

According to the Olympstats blog, one possible estimate for the total number of people to have participated in the Olympics as of 2015 was 128,420, though as it notes other estimates could be created. It has been proposed to create a complete alphabetical listing of all participants of the Olympics, spread across a number of articles. An example of one of these lists can be seen here. FOARP (talk) 11:16, 17 September 2025 (UTC)[reply]

Previous discussions

Discussion on the Olympics project.
AFD discussion (nb. this RFC was recommended in the close here).

Survey

Do you:

Oppose creation of these articles
Support creation of these articles

Responses

Oppose - The possible number of entrants makes this essentially a phonebook, something which Wikipedia is clearly WP:NOT. It would not be useful for navigation because of its length - a figure that is not even fixed but grows by thousands with each edition of the summer and winter games. FOARP (talk) 11:16, 17 September 2025 (UTC)[reply]
Oppose - It seems like the only logical choice is to oppose this RfC as written because the articles already exist, and any duplicates would have to be deleted under WP:CSD A10. This says "this RFC was recommended in the close here". Where was this RfC recommended in the admin's close? The only time an RfC was mentioned by the closing admin was as as an aside "...and I believe the intersection of lists of sportspeople with NOTDB is ripe for a community-wide RfC". Creating an RfC focused on one specific list to exist or not, as this is, feels like circumventing the AfD process just one day after an AfD on this list was closed.
I wouldn't oppose a broader RfC on "the intersection of lists of sportspeople with NOTDB", but it can't be phrased in this way about one specific list that both you and I were WP:INVOLVED in the AfD for. (also, why wouldn't you use the first page as an example of the list contents?) --Habst (talk) 12:07, 17 September 2025 (UTC), added !vote --Habst (talk) 15:14, 19 September 2025 (UTC)[reply]
So that this isn't just an exact re-hashing of the AfD closed one day ago, I proposed adding additional options:

Oppose lists:
Oppose having any list of Olympians

Oppose specifically an alphabetic list, open to others

Support having a list in some form:
Support keeping existing Olympic list (alphabetic)

Support a list in another format (e.g. by sport)

Support a list, neutral on format

Neutral

At least one editor then !voted on one of these new options. However, it was reverted in ~~Special:Diff/1311887797~~ Special:Diff/1311888941 and a message was posted on my talk page about it. If other RfC participants agree that more nuanced choices would be helpful so that this isn't narrowly re-hashing the AfD, I think they should be added to #Survey above. --Habst (talk) 13:55, 17 September 2025 (UTC)[reply]
@Habst the diff of the reversion is actually Special:Diff/1311888941. I think the additional nuance is useful and won't overwhelm the discussion - indeed I think it's likely to aid the finding of a consensus and avoid the need for more future discussions. Thryduulf (talk) 14:26, 17 September 2025 (UTC)[reply]
Thanks, looks like I copied the wrong diff ID. Fixed. --Habst (talk) 14:31, 17 September 2025 (UTC)[reply]
Oppose A full alphabet listing of Olympians is not a natural sorting order for them, so it doesn't make sense to make such a list. (Olympians by country or by sport are far more natural). This is also where categorization is already set up to do that. Masem (t) 12:11, 17 September 2025 (UTC)[reply]
Neutral. At AfD I said that these clearly meet NLIST, and they do. But whether they are worth having around is a separate question, hence why this RfC is a good idea. I think arguments on both sides are sensible, so I land at a neutral or weak support. These lists technically fall within policy, but I'm not fully convinced that they're useful to readers. Toadspike [Talk] 12:59, 17 September 2025 (UTC)[reply]
Support a list of all Olympic competitors is very clearly useful and satisfies NLIST as they are discussed as a group and the inclusion criteria is not indiscriminate. Such a list would be impossible to navigate for size reasons though, so it needs to be split and alphabetic is self-evidently one logical method of doing so. Wikipedia is not paper so we don't need to worry about the number of articles, and the existence of these listings does not preclude the existence of other splits (e.g. by games or by nationality). Thryduulf (talk) 13:24, 17 September 2025 (UTC)[reply]
To clarify now additional nuance has been requested above, I support the existence of lists organised alphabetically, by nationality, by games and by sport. I'm presently neutral on other lists. Thryduulf (talk) 13:27, 17 September 2025 (UTC)[reply]
The maintenance burden for these lists would be pretty high. Every Olympics, someone would have to go add them all in alphabetical order, interspersed. Perhaps grouping by Summer/Winter Olympics Of Year XXXX would make more sense, instead of a massive alphabetical list? –Novem Linguae (talk) 15:00, 17 September 2025 (UTC)[reply]
(It's for things like this that I wish we could do Wikibase-generated listings in mainspace...) Perryprog (talk) 15:50, 17 September 2025 (UTC)[reply]
As Perryprog alludes to, there are so many different ways to organize the data and the data is constantly being updated, so a database sorting/filtering interface is more suitable than creating snapshot lists of all possible organization methods. Even if the snapshot process were automated, the length of the lists makes them unwieldy for convenient use. I think better search tools (either based on Wikipedia or Wikidata) would be a more extensible, manageable solution. isaacl (talk) 16:06, 17 September 2025 (UTC)[reply]
In my AfD closure I recommended that the community discuss the intersection of lists of sportspeople and WP:NOTDATABASE, or possibly the interpretation of NOTDB as it applies to large groups with well-defined inclusion criteria more broadly. There is a clear divide in the community as to the interpretation of NOTDB in this context. I didn't intend to recommend an RfC about this list specifically. I cannot preclude one, of course, and as I closed the discussion, and am genuinely undecided, I won't be commenting on the merits. Vanamonde93 (talk) 16:21, 17 September 2025 (UTC)[reply]
Oppose creating database-like lists in the mainspace. Sapphaline (talk) 17:15, 17 September 2025 (UTC)[reply]
Oppose As User:FOARP said this is essentially a phonebook, not something worth listing. Categorisation based on other parameters is fine, which, I'm guessing, already exists. — Preceding unsigned comment added by Kingsacrificer (talk • contribs) 18:35, 17 September 2025 (UTC)[reply]
Oppose Also agree with User:FOARP that this is basically a phonebook given the sheer length. It's not useful for navigation particularly: who knows only the first letter of an olympians name, and nothing else, and needs to find them? What about "List of olympians in snowboarding" or topic-based lists? Those might be more useful. Mrfoogles (talk) 01:10, 18 September 2025 (UTC)[reply]
Oppose This list is fundamentally a bad idea for several reasons. WP:NOTEVERYTHING shows an existing consensus that databases and phone lists are not appopriate on Wikipedia. Secondly, discussion at AfD revealed that the collation was manuallyy sourced and created from wikidata. But if that is so, then we already have the collection in wikidata. This is just bad information management, to create two copies of the data that require manual intervention to prevent them falling out of step with each other. And thirdly, that workload is excessive and the reason that wikipedia lists, in general, are not useful if they claim to be exhaustive: because they are not. They rely on diligent and continual editor resource, that they cannot ever achieve. As FOARP points out, the enormous size of this list, and the speed at which it accrues new entries will guaranty that the list will be incomplete, and bad data is worse than no data. Fourthly, in this format, the data is unusable. If you know the name of someone you want, search is faster, as is querying wikidata. If you don't, then this list is not a suitable taxonomy. Fifthly, we already have the means for creating taxonomies, and those taxonomies already exist in the form of existing categories. So no, we shouldn't do this. We should use the existing wikidata and categories, and if anyone is interested in some kind of searchable list - dynamically generate it from wikidata. Sirfurboy🏄 (talk) 07:33, 18 September 2025 (UTC)[reply]
Oppose the creation of these lists. This information would be better sorted by year, nationality, and discipline rather than alphabetically, and the articles in Category:Nations at the Summer Olympics by year and Category:Nations at the Winter Olympics by year already include every Olympian that represented the nation at the Games in question. While making lists that contain the same information ~~are~~ is acceptable, and I do think these lists would pass WP:INDISCRIMINATE and WP:PHONEBOOK, it feels like the existing articles are a better way to organize the information. md m.b la 16:47, 18 September 2025 (UTC)[reply]
- Actually, those categories do not contain every Olympian. There is no other place (whether categories, wikidata, or even other websites) for anyone to find a complete listing of Olympians. BeanieFan11 (talk) 16:50, 18 September 2025 (UTC)[reply]
  Even if it did, a relevant editing guideline on this is Wikipedia:Categories, lists, and navigation templates#Overlapping categories, lists and navigation templates are not considered duplicative. --Habst (talk) Habst (talk) 16:59, 18 September 2025 (UTC)[reply]
  
  To clarify, I support having this information, I just think there is probably some better way of organizing the data that would make it more accessible to readers than an arbitrary number of alphabetized lists. md m.b la 17:18, 18 September 2025 (UTC)[reply]
Oppose These articles are too long and have too little information to be useful. They also clearly violate the spirit and probably the letter of the law that Wikipedia is not to be a directory. Some have argued that there is sourcing about Olympic competitors as a group. This sourcing is on the general trends of who has been Olympic competitors, but with an unclear number somewhere around 150,000 or 160,000, it is not possible to create a comprehensive list and sources do not do this, just cherry picking some sub-group, or what they find interesting or excited cases. We maybe could have an article Olympic competitors or the like that says things about Olympic competitors as a group, maybe subdivided in some ways, but sourcing does not justify creating a directory of every single Olympic competitor whose name we know, especially one that really does not tell us much about the individuals. I do not think creating such a massive directory of Olympic competitors is within the listed things Wikipedia is, and I do not think there are sufficient reliable sources to support such a directory in Wikipedia.John Pack Lambert (talk) 21:37, 18 September 2025 (UTC)[reply]
Oppose creating these types of lists in mainspace, which are effectively databases. Considering that the cited AfD had many participants calling for a RFC on this subject, I see no issue with how this was brought up here, and I have no opposition to possibly having lists in a different format, with a very careful curation process, but this isn't it. Lists that exist now can be moved to draftspace or deleted. Let'srun (talk) 16:11, 21 September 2025 (UTC)[reply]
Oppose. This is what category pages are for. ~Anachronist (talk) 01:49, 22 September 2025 (UTC)[reply]
- There's no categories listing everyone on these lists. BeanieFan11 (talk) 02:12, 22 September 2025 (UTC)[reply]
  But categories could be created with that in mind, perhaps by having one for each games or something similar. Let'srun (talk) 19:56, 23 September 2025 (UTC)[reply]
  Except that the categories will be missing those without articles, and currently those categories do not exist. It makes no sense to delete quality lists we have on the basis that "well, we could create a category that could have some of the entries on the list, though we almost certainly won't". BeanieFan11 (talk) 20:00, 23 September 2025 (UTC)[reply]
  Redirects are allowed to be in categories. Let'srun (talk) 17:56, 27 September 2025 (UTC)[reply]
  With great respect intended, you !voted against keeping such a redirect at Wikipedia:Redirects for discussion/Log/2025 August 11#Ajit Singh (race walker). I think it's great to propose other solutions like this, but I don't think it's fair to then also be against your own proposed solution without noting that. --Habst (talk) 18:03, 27 September 2025 (UTC)[reply]
Soft Support I think I prefer Olympians by sport as more manageable lists, but I do think a list of Olympians clearly meet NLIST (per Toadspike and Thryduulf). --Enos733 (talk) 02:50, 22 September 2025 (UTC)[reply]
Opposed - per WP:NOTDIRECTORY. I could certainly see a list of medalists (by year and sport), and perhaps this could be expanded to include those who were in serious contention for a medal (as indicated by sources)… but a list of everyone who participated in an Olympics is just too much. The simple fact is that many participants have no shot at winning a medal, and are there simply so their country can claim they participated. These are not noteworthy. Blueboar (talk) 11:57, 22 September 2025 (UTC)[reply]
I oppose creating such a list.—S Marshall T/C 13:36, 22 September 2025 (UTC)[reply]
Why? Thryduulf (talk) 15:40, 22 September 2025 (UTC)[reply]
Because these are biographies, and policy says I'm to be very firm about insisting on the most reliable sources for them. Unfortunately we don't have impeccable sources. What we have is online databases compiled by, err, who, exactly? Making a completionist list of everyone who's ever competed in the Olympics isn't a good move. If you asked me, "Shall we make a list of everyone who's ever won an Olympic medal?" then I would not object because I think the content would be so much easier to verify.—S Marshall T/C 17:24, 22 September 2025 (UTC)[reply]
Oppose per above. >^CreativeLibrary460 /^{access the library} ^revision\ 05:53, 23 September 2025 (UTC)[reply]
Support a list of Olympians by country. It's subcategory being the 'Sports' they participated in.
Oppose a list encompassing all Olympians of all the countries. Hardly anyone would require such marathon of an extensive list, thus it would barely add any value to Wikipedia.
Cdr. Erwin Smith (talk) 12:13, 23 September 2025 (UTC)[reply]
I support having lots of Category:Olympics-related lists, including a variety of Category:Lists of Olympic competitors. I'm not sure about an enormous list of every single athlete's name, though. I'd rather have lists by year, by country, by sport, by number of medals, by number of games competed in, etc. It's not clear to me what the benefit of a huge list is. WhatamIdoing (talk) 23:20, 23 September 2025 (UTC)[reply]

Oppose. Such lists would be almost paradigmatic examples of what is advised against in WP:NOTDIR. While I wouldn't say that the information is completely WP:INDISCRIMINATE, the lists would have close to zero value for the typical reader, relative to huge editorial burdens in maintenance for verifiability, presentation, and vandalism. Yes, we can probably expect, from the mere existence of this discussion, that there is a cohort of editors willing to generate and organize the initial versions of these pages, but once created, the community as a whole accrues a certain degree of obligation to maintain accurate and up-to-date content therein. This compared against a utility for such an exhaustive list that I can only imagine would ever be leveraged in exceedingly rare use cases by athletics researchers and the highest levels of enthusiasts--groups which have other resources at their disposal. There have been some strong WP:NOTPAPER arguments made above, but at the end of the day, this kind of extensive database is just not really consistent with the high-level review purposes of a general encyclopedia, imo. SnowRise ^{let's rap} 06:38, 25 September 2025 (UTC)[reply]
Oppose, for the same reasons described in the initial discussion and the AfD, and per the many arguments above. Such a comprehensive list serves no useful purpose to readers, and indeed the original purpose of the extant lists was actually to shoehorn in biographical info from deleted non-notable multi-Olympians. This RfC is a reasonable followup to the AfD and of course should be interpreted as applying to existing lists. JoelleJay (talk) 15:33, 30 September 2025 (UTC)[reply]
Oppose creating a laundry list of all Olympic athletes ordered alphabetically, however split up: against WP:NOTDIRECTORY; pushing the boundaries of WP:INDISCRIMINATE; terrific maintenance burden; and, in my opinion, not especially useful for the majority of readers, who, if they are looking for a particular Olympian, are probably best off using search. Also, for clarity, I oppose the current lists of this ilk, which I think should be deleted. Cheers, SunloungerFrog (talk) 10:44, 3 October 2025 (UTC)[reply]

Discussion

What is it we're looking to do here? The framing is odd -- It has been proposed to create, and a focus on supporting/opposing creation as though the articles don't already exist. It just went through AfD, which ended in no consensus, and an RfC on retroactive opinions on creation (?) isn't a substitute for that process. Opposition to creation doesn't necessarily mean support for deletion (and vice versa), and the choice here doesn't include deletion. If you're trying to establish a precedent about the scope of a list, this also doesn't do that, because it's too focused on a specific example. — Rhododendrites ^talk \\ 14:46, 17 September 2025 (UTC)[reply]
Thank you. To be honest, I'm feeling this RfC is a little bit of a hostile environment for me because, as it's written, I don't see how this isn't circumventing an AfD that received a sufficient amount of participation and was closed yesterday, started by an editor who I greatly respect but was heavily involved in that AfD (I was also involved as the list creator). It claims it was created at the behest of an admin, but then the admin came here and commented that wasn't what they said. (And if that's going to be the case, shouldn't all the AfD and WikiProject Olympics thread commenters be pinged...?) I desperately want to achieve consensus on having a list of Olympians, including making concessions if needed, but I want to do it the right way.

From a bigger picture it seems this list is being used as a 'proxy battle' among inclusionists and deletionists w.r.t. WP:NSPORTS2022 and its recent implementation this year, resulting in hundreds of Olympian articles being deleted and no suitable place to put that lost information. As someone who genuinely tries to look at each case on its merits, I don't know how to rectify that.

One of the biggest concerns I heard was editors saying they would prefer if lists were created by sport rather than alphabetically. I also thought that originally, but after actually compiling it I realized that anything other than an alphabetic list is guaranteed to create duplicate rows (e.g. for multi-sport athletes who would be listed in more than one of these articles) and thus introduce unforeseen complexities.

Nonetheless I did some of the legwork on this over the last few days to determine what that would look like. The largest Olympic list segment currently is 2,136 rows, a limit that was essentially decided by the community as others have split the original segments that were longer. Using that limit of about 2,100 rows per article, we would need more than one article for each sport, even if broken up further by gender. My best idea after that is to split by year and gender, so here's what that would look like in a ToC table with that approximate limit: Special:Diff/1311981102

This would result in duplicates both across sports and across years, but is the only way I can think of to split by sport. I'm not opposed to creating all those pages, just struggling to see how that would be better or more maintainable than the current list. --Habst (talk) 01:01, 18 September 2025 (UTC)[reply]

Thank you for validating my confusion. The question seems to be "Should we create these articles?" but then the already-existing articles are linked to. The answer would then logically be "No, they already exist." 207.11.240.2 (talk) 12:29, 19 September 2025 (UTC)[reply]

The AFD close specifically included the line "I believe the intersection of lists of sportspeople with NOTDB is ripe for a community-wide RfC." As such, I don't think holding such an RfC could be seen as an end-run around the AFD result. Also, procedurally, I don't think the "retroactive" argument is strong when the mainspacing of these lists is comparatively recent. SnowFire (talk) 15:25, 19 September 2025 (UTC)[reply]
But this... isn't an RfC about the intersection of lists of sportspeople with NOTDB. It's about whether we should create these concrete lists that happen to already exist. — Rhododendrites ^talk \\ 15:28, 19 September 2025 (UTC)[reply]
It's about whether the community supports the creation of these lists, past, present, or future. This is the discussion that should have happened in the first place. It needed to be about something concrete because any other question is far too open-ended.

That'll give us a clear result: if it's against then the issues with these articles need to be addressed, if it's support then sure: "script goes brrrt!". FOARP (talk) 08:56, 22 September 2025 (UTC)[reply]
It plainly isn't, which is why I created the list but agree with the community in opposing the RfC question. The RfC doesn't say or imply anything about past, present, or future. The closing administrator you cited in #Previous discussions even chimed in above to say this isn't what they said to do.

The articles were also not created with a script, by the way; scripts were sometimes used for formatting but the list contents were compiled via a manual process. --Habst (talk) 10:46, 22 September 2025 (UTC)[reply]
I don't think there's any mystery what the people !voting above are saying about these articles. I urge you to put it to them directly if you think otherwise, rather than try to use this as a pre-emptive rationale for ignoring the result once it arrives. FOARP (talk) 12:44, 22 September 2025 (UTC)[reply]
You're right that it's not a mystery; the RfC is very clear that it's about creating new articles and not about keeping or deleting existing ones. The only logical decision is to !vote oppose, which I did in part because any new articles would have to be deleted under CSD A10. --Habst (talk) 13:24, 22 September 2025 (UTC)[reply]
Again, I urge you not to try to set up a pre-emptive rationale for ignoring the result if it's not the one you'd prefer. The discussion is ongoing, if you really think people don't know what they are !voting for, then you should put that to the people !voting. FOARP (talk) 13:34, 22 September 2025 (UTC)[reply]
I promise you I am not setting up any rationale, I am just reading the RfC as written. I do think editors know what they are voting for because it's plainly stated. That's why I !voted to agree with the consensus and most other !voters. --Habst (talk) 13:46, 22 September 2025 (UTC)[reply]
As one voter voting oppose, I can quite clearly assert for myself that FOARP is spot on here as far as how I interpreted this RFC, and I would encourage you to take the feedback from any result seriously rather than casting aspirations or doubt on this process. Let'srun (talk) 20:38, 22 September 2025 (UTC)[reply]
I think there is some misunderstanding here. I always have aspirations to achieve consensus; I agree with the process and the !voters' rationale for voting on this RfC. That's why I !voted similarly to you above. That's of course not incongruous with wanting to keep any existing list; the process for deciding that is generally AfD. The closing administrator, who commented above, was cited incorrectly in #Previous discussions. --Habst (talk) 20:42, 22 September 2025 (UTC)[reply]
Wikipedia is WP:NOTBUR. It is quite clear that this is about having these pages in mainspace at all, not just about future creations (otherwise this would be a pointless RFC, and besides that there isn't a grandfather clause in our P&G's). We disagree on this topic, and that's okay. Just please accept the consensus and take the feedback in stride, no matter what happens. Let'srun (talk) 20:45, 22 September 2025 (UTC)[reply]
I do agree with de-bureaucratizing Wikipedia. It's very clear from the RfC that this isn't about keeping any particular pages in mainspace, but whether or not we "oppose creation of these articles" or "support creation of these articles". That's why I !voted as I did. I don't even agree that's a pointless RfC, though the outcome is somewhat predictable. Opposing creation but not supporting deletion isn't the same thing as a grandfather clause; that's the entire reason why we have the "no consensus" close as an option.

I don't even see where our disagreement is on this topic? I have always accepted community consensus just as you have, have made dozens of changes to my editing behavior and the articles on account of community feedback, and I will do the same on the list of Olympic competitors. --Habst (talk) 20:53, 22 September 2025 (UTC)[reply]
You wish to have alphabetical based lists. I oppose having alphabetical based lists. Let'srun (talk) 21:09, 22 September 2025 (UTC)[reply]

I also oppose creating alphabetical lists of Olympians. I guess the difference is, now that we're here, whether we should delete existing lists -- that question wasn't asked in the RfC. --Habst (talk) 22:12, 22 September 2025 (UTC)[reply]
This RFC isn't about deletion because this isn't AFD. This is about whether these lists specifically should have been created in mainspace, and if the community is opposed to that then they either need to get out of mainspace (e.g., back to draftspace, though I guess transwikiing is also an option) or change to be acceptable to the community.

Of course if the community supports them having been created then they stay as they are.

Can I also point out that your attempt to pre-emptively dismiss the outcome of this RFC doesn't pass even a casual reading of what the people !voting above actually say? The !voters, support and oppose, are taking this as a discussion on the articles that presently exist in mainspace, which is the natural interpretation since there is a link to them (and discussions about them). FOARP (talk) 07:38, 23 September 2025 (UTC)[reply]
FOARP, I am affirming the outcome, not dismissing it as I would never dismiss any community consensus. As you yourself said, this AfD "isn't about" draftification or transwikifying -- it's about whether or not to create an alphabetic list of Olympians, which I happen to think, from where we are now, that it shouldn't be and !voted accordingly. Simultaneously, I don't think they should be draftified or transwikified. That rationale and thought process broadly agrees with the other editors above; even if you interpret it to be about the existing articles which in a very literal sense it isn't, the above editors aren't arguing in terms of draftification or transwikifying.

I think there is some misunderstanding because in #Previous discussions, a specific administrator was cited as the reason for creating this RfC, but then that administrator commented above that wasn't what they said. --Habst (talk) 11:11, 23 September 2025 (UTC)[reply]
This isn't an AFD. Your response is a pre-emptive WP:IDHT and I advise you strongly against it. FOARP (talk) 12:19, 23 September 2025 (UTC)[reply]
@FOARP, I'm speaking to you with an open mind, please tell me where I have erred. The question in the RfC was whether or not an alphabetic list of Olympians should be created. I don't think it should be created, so I !voted oppose. This isn't incongruous with not wanting the lists to be draftified or transwikified.

So that I can hear it or get the point very clearly, can you please state your disagreement in clear terms? Do you think I should have !voted support, even though I don't agree with the RfC statement? --Habst (talk) 12:32, 23 September 2025 (UTC)[reply]
Simply so you cannot later claim that this was not explained to you: This is about the creation of the articles presently in mainspace, not theoretical future articles. FOARP (talk) 13:12, 23 September 2025 (UTC)[reply]
I will accept that and am still against their creation (to be clear, now I'm speaking about the existing articles, not any hypothetical future ones). I'm also against transwikifying or draftification of the existing articles. How is that IDHT, and what is our disagreement here then? --Habst (talk) 14:01, 23 September 2025 (UTC)[reply]
The disagreement here is that you appear to think that the outcome of this discussion will have no impact on the articles presently in mainspace. Read the !votes and see what they say about these articles.

I'm done here. FOARP (talk) 14:18, 23 September 2025 (UTC)[reply]
I don't think the outcome will have no impact on the articles in mainspace; the outcome will decide whether or not to create an alphabetic list of Olympians.

You can disagree with that but still be against deletion, draftification, or transwikifying, which is why I don't think this discussion will result in those three outcomes but others are on the table. I am genuinely in good faith trying to come to a shared understanding here; please explain how this is IDHT. --Habst (talk) 14:30, 23 September 2025 (UTC)[reply]

I think FOARP believes that (almost?) everyone opposing the creation of these lists is inherently simultaneously also advocating for the deletion of those that currently exist and is not understanding why anyone could or would, in good faith, think otherwise.

You (Habst) obviously do think otherwise, and I have no reason to believe you are contributing here in anything other than good faith.
I've just read in detail some of the comments from those opposing, and while some are clearly in support of deleting the articles that currently exist, most do not express a clear opinion on that either way so there is no way that I could support any deletions of any content based on this discussion alone. Thryduulf (talk) 14:49, 23 September 2025 (UTC)[reply]
I see, thank you. The confusing part for me is that FOARP said above, "This RFC isn't about deletion because this isn't AFD". I honestly don't want to get bogged down in semantic debates, but I don't see how one can square that with a closing action of deletion, draftification, or transwikifying.

I do think that (because nobody WP:OWNs an RfC) the community can decide on a result even if it's against the RfC creator's original intentions or wishes, but I just don't see how that can happen here. --Habst (talk) 14:54, 23 September 2025 (UTC)[reply]
Note that WP:OWN goes both ways here. Your failure to get the point here is growing tiresome. Let'srun (talk) 20:21, 23 September 2025 (UTC)[reply]
What point is Habst failing to get? Thryduulf (talk) 20:39, 23 September 2025 (UTC)[reply]
He does not control either his lists or this RFC. Let'srun (talk) 21:53, 23 September 2025 (UTC)[reply]
I've been saying that from the very beginning, including pointing out that the articles don't have any owner and thus opposition based on the personality or perceived motives of any one editor isn't justified. The majority of recent edits to the lists have been from other editors, and more than 30 of the list pages were created by someone other than me. For the pages I did create, let me say here I'll dual license the contents under CC0/the public domain because I will always encourage contributions from other editors and prefer them over my own. --Habst (talk) 22:17, 23 September 2025 (UTC)[reply]

I don't see any evidence of Habst attempting to own either the articles or this RFC. Thryduulf (talk) 23:43, 23 September 2025 (UTC)[reply]
@Thryduulf: Who in this discussion do you think supports keeping the existing lists but is opposed to creating new lists (besides Habst)? As I noted earlier, there is no grandfather clause here. Let'srun (talk) 20:23, 23 September 2025 (UTC)[reply]
Opposes deletion: All those supporting the proposal

Unclear: Masem, Novem Linguae, Isaacl, Sapphaline, mdm.bla, Anachronist, Blueboar, CreateiveLibrary460, Cdr. Erwin Smith

Supports deletion and/or draftification: Mrfoogles (probably), Sirfirboy, John Pack Lambert, Let'srun, S Marshall (probably)

Note that the last category does not distinguish between those who oppose draftification and those who do not. Nobody in the unclear category has made any comment regarding draftification. Several commenters explicitly support lists in other formats and/or more focused (e.g. just medallists) and they would presumably not oppose editing the current lists so they fit that scope but nobody has explicitly commented either way regarding this other than Habst (who opposes). Thryduulf (talk) 20:37, 23 September 2025 (UTC)[reply]
Regardless of your position, I think leaving the nom completely out of this analysis shows that it is quite flawed. Feel free to ping the "unclear" voters, but I think they all are against any such articles being in mainspace. Let'srun (talk) 18:01, 27 September 2025 (UTC)[reply]
I don't intend to ping editors who have clearly responded to the question asked of them to complain that they haven't answered a different question to someone else's satisfaction. I think stating that they are against any such articles being in mainspace is projecting your own preferences onto others. Thryduulf (talk) 19:50, 27 September 2025 (UTC)[reply]

"Who in this discussion do you think supports keeping..." -- You don't have to support keeping a list to be not in favor of deletion. That's what no consensus can mean -- if people oppose deletion but don't support creation, which happpened to be the closing decision at the AfD closed one day before this RfC was started. That's not the same as a grandfather clause, which I also am against on Wikipedia. --Habst (talk) 20:45, 23 September 2025 (UTC)[reply]

The survey options didn't put a timeframe on when the articles in question were created. It doesn't make sense that the community would consider all of the articles listed at Template:List of Olympic competitors intro to be exempt from the general guidance it is creating. isaacl (talk) 17:16, 28 September 2025 (UTC)[reply]

Agree. There's a lot of highly motivated reasoning going on here. This is about the pages an example of which is literally linked in the RFC intro, and which the question was clearly referring to. There is only one logical way to interpret the question. Saying "no, they were talking about theoretical pages that might be created in the future, not the pages that were linked to in the question" is just sophistry, sorry.

Also the answers were very clearly about the pages that had already been created. When @Anachronist said "This is what category pages are for" they clearly didn't mean that they were OK with the pages that had already been created listing every one of the 150,000 Olympians alphabetically and which are not category pages. When @Sapphaline said "Oppose creating database-like lists in the mainspace" they clearly meant the database-like lists that Habst created. When @Mdm.Bla said "Oppose the creation of these lists." they meant these lists. When @Blueboar said "a list of everyone who participated in an Olympics is just too much" they mean they opposed the lists of literally everyone who ever competed at the Olympics that Habst created. When @CreativeLibrary460 said "Oppose per above" underneath a load of other !votes opposing the creation of these articles, they weren't saying anything unclear at all. Similarly when @Cdr. Erwin Smith said "Oppose a list encompassing all Olympians of all the countries.", that clearly applies to the listing of all Olympians of all countries that now exists. FOARP (talk) 22:37, 2 October 2025 (UTC)[reply]

Thank you. To clarify, I oppose creation of a page as proposed, and simple deduction would mean that I also would support deletion of such a page. Why someone wants to interpret what I wrote as something I didn't write is beyond my comprehension. As I said, that's what category pages are for. The objection that category pages don't list nonexistent articles is a red herring; that's what redirects are for. ~Anachronist (who / me) (talk) 23:19, 2 October 2025 (UTC)[reply]

Just because someone does opposes creation does not necessarily imply that they also support deletion, especially when options other than deletion (such as draftification and converting to a category) have been explicitly brought up in the discussion. Many participants have also explicitly supported lists in other formats (e.g. by sport) and/or subsets (e.g. only medal winners) and especially with the latter it's highly plausible that at least some of those editors would support editing the existing lists to convert them to that form/scope - possibly directly in mainspace, possibly in draftspace. It is perfectly reasonable for you to oppose everything that isn't straight deletion, it is not reasonable to accuse other editors of "highly motivated reasoning" or of (deliberate) misinterpretation of comments because you didn't explicitly answer a question that was not explicitly asked. Thryduulf (talk) 23:46, 2 October 2025 (UTC)[reply]

When @Sapphaline said "Oppose creating database-like lists in the mainspace" they clearly meant the database-like lists that Habst created - yes, thank you for clarifying my words. Sapphaline (talk) 09:22, 3 October 2025 (UTC)[reply]

What happened to all the people at the AfD who !voted keep? Literally none of them have voted support here for some reason. I also note that JoelleJay was potentially canvassed. Her vote above is her only edit since she received FOARP's message. ~WikiOriginal-9~ (talk) 12:07, 3 October 2025 (UTC)[reply]

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.

Content merged and later removed

Wikipedia:Redirects for discussion/Log/2025 September 19#Big gene involves a proposal to delete a redirect: Big gene had content that was merged into Gene, and it's still visible in the merger diff (which links big gene, so it's properly attributed), but at some point since then the content's apparently been deleted. Do we have to keep the merged page's history in some manner, because the content is still visible in the page history, or can we dispense with it, because it's not in the current version? I'm leaning toward the first option, but I'm uncertain. Nyttend (talk) 09:01, 24 September 2025 (UTC)[reply]

If there's consensus at RfD that a redirect should be deleted, I don't think it's appropriate to keep it in mainspace solely to preserve attribution. I would feel that way even if the merged content were still live somewhere. Maybe a move (while suppressing redirect creation) to a subpage of the merge target's article talk page? In this example, it'd be Big gene → Talk:Gene/Big gene. Too crazy?

Alternatively, our attribution requirements can be met with a list of authors in an article edit summary, with the summary linking to a longer list kept at the talk page (or subpage), if necessary. Firefangledfeathers (talk / contribs) 15:36, 24 September 2025 (UTC)[reply]

Both of those ideas were in my mind. But again: do we need to keep something because of the merger, although the merged content is now gone? Nyttend (talk) 07:51, 25 September 2025 (UTC)[reply]

I for one would say so, yes. It's visible in a page history somewhere. Graham87 (talk) 09:39, 25 September 2025 (UTC)[reply]

Legally I believe so. Otherwise it becomes a copyright violation. PARAKANYAA (talk) 02:59, 26 September 2025 (UTC)[reply]

My reading of WP:CWW is that yes, Big gene should be kept for copyright purposes. As an alternative, though I haven't checked the merged text word for word against the Big gene text: it looks to me like all of the content that was merged came from a single editor (the editor who created the article, where the content was present in this diff), so for copyright purposes, it might be acceptable to create a dummy edit that identifies that editor as the copyright holder of the material that was merged from Big gene, also noting the edit where the merge occurred. But I'm not positive that that's sufficient. FactOrOpinion (talk) 03:21, 26 September 2025 (UTC)[reply]

A permanent note on the talk page would be more usual than an edit summary at a place in the page history that's far removed from the actual content.

A much simpler solution is just to leave the redirect alone (or turn it into a dab page for content that we do have). WhatamIdoing (talk) 04:49, 26 September 2025 (UTC)[reply]

I agree that attribution is required in this case. As Graham87 wrote, the text is accessible to anyone. However, WP:Copying within Wikipedia (guideline, shortcuts WP:COPYWITHIN and WP:CWW) does not mandate keeping the redirect or its history. Retaining a merged article's history under a redirect is the easiest and most common method of providing attribution, but WP:Copying within Wikipedia#Reusing deleted material (shortcut WP:RUD) and WP:Merge and delete (essay, shortcut WP:MAD) describe alternatives that have been suggested above. Flatscan (talk) 04:24, 3 October 2025 (UTC)[reply]

Taken to its logical extreme, this would let anyone prevent the deletion of any article. Simply merge an article in danger of deletion anywhere (it doesn't even matter if it's related or not). Then someone would likely just revert the merge. But then, oh no!, content is visible in the history somewhere else, we can't actually delete it now. This would be silly. 35.139.154.158 (talk) 16:15, 6 October 2025 (UTC)[reply]

If it's truly unrelated, then it could be revdelled from the other page's history. jlwoodwa (talk) 16:17, 6 October 2025 (UTC)[reply]

Recently deceased crime suspects

BLUF: What should be done when the perpetrator of a crime is killed and will never face trial?

I'm curious to know if there is established precedent on this, or if we maybe need a clearer policy. This has come to bear in a few recent cases like Annunciation Catholic Church shooting and Grand Blanc Township church attack, etc, where the suspect is killed or kills themself. Once the suspect is identified, there is a rush to add their name to the article, which can be seen to violate WP:BLPCRIME as it also applies to recently deceased persons. We do not generally name perpetrators if they have not been found guilty, so we find ourselves in a dilemma where the suspect will never be found guilty in a court of law.

And so my question is: when do you add the name of a dead suspect to an article? First news report? Preponderance of news reports? Once a final investigation has been released? Once the suspect is no longer recently deceased? Once consensus is reached at each individual article that the person has appropriate notoriety because of the news coverage? Something else?

And my second, tangential, question is: should this be spelled out more completely somewhere? ~Darth Stabro^{Talk • Contribs} 19:24, 29 September 2025 (UTC)[reply]

I think this needs to be decided on a case-by-case basis by consensus, rather than be spelt out more completely. Phil Bridger (talk) 19:37, 29 September 2025 (UTC)[reply]

There is a major difference between a perpetrator and a suspect; the Innocence Project has a long list of cases where not only were suspect and perpetrator not the same, but convict and perpetrator were not the same. Similarly, there have been cases where a suspect was shot but the perpetrator turned out to be somebody else. Confusing these terms violates NPOV. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:02, 29 September 2025 (UTC)[reply]

We do not generally name perpetrators if they have not been found guilty I think that's just incorrect. We name deceased perpetrators if they have been described as such in reliable sources. Jahaza (talk) 20:22, 29 September 2025 (UTC)[reply]

Indeed. What matters is that we do not name somebody who has not been named in reliable sources and do not imply they were convicted unless they were. Describing a person as the "alleged", "suspected", "apparent" or "believed" perpetrator (or similar wording) is one way of doing this. Also things like describing someone as having carried out a "killing" rather than a "murder" is relevant in many cases (even if it is incontrovertible that X was the person who killed Y there are many reasons why they might not have been tried for and/or convicted of murder had they lived). In all cases though, the individual circumstances and what reliable sources say matter so there cannot be a one-size-fits-all policy. Thryduulf (talk) 20:57, 29 September 2025 (UTC)[reply]

One should keep in mind that BLP not only concerns the individual but also their family and friends. We want to be sure a named individual, even if killed at the crime, is properly investigated and named before adding it to prevent doxxing and other outings involving their close associates. Masem (t) 20:30, 29 September 2025 (UTC)[reply]

I think that it's easier to figure out the right answer if we set aside most of our "rules" and think about this from the POV of common sense. Think about when you would not want to name a perpetrator: If you didn't have good sources. If there was some reasonable doubt about the facts. If it's a relatively minor crime (someone ran a red light, and hit Chris Celebrity's car). If there's an indication that it wasn't really an intentional crime (someone ran a red light because they unexpectedly had a stroke, and hit Chris Celebrity's car). If the crime is being used as an example, so the broader details aren't relevant ("Sometimes, when drivers run red lights, they unintentionally die"). In cases like these, don't name the perp. In cases the opposite of these, then you should name the perp. And in between, you should talk to other editors about it, and make a decision as a group. WhatamIdoing (talk) 21:29, 29 September 2025 (UTC)[reply]

FWIW, a few of us had a similar discussion not that long ago at WT:BLP/Archive 62 § BLPCRIME, BLPCRIMINAL, and the recently dead who are alleged perpetrators. Even if Phil's response is the consensus, given that this is coming up regularly, I think it would be good to acknowledge in the policy that this question sometimes arises and should be decided on a case-by-case basis. FactOrOpinion (talk) 02:25, 30 September 2025 (UTC)[reply]

"At each article, editors should decide by consensus whether to include the names of alleged perpetrators, victims, or other affected people"? WhatamIdoing (talk) 02:45, 30 September 2025 (UTC)[reply]

I think that works, though I might add something like "including the name(s) of any recently dead person(s) involved." Perhaps there should also be a brief mention of some elements that might affect the consensus, such as how recently the crime (and possible death) occurred, how widespread the names are in reporting about it (though it's still essential to distinguish between "person of interest" and "alleged perpetrator") FactOrOpinion (talk) 00:04, 1 October 2025 (UTC)[reply]

There was a recent discussion about rewriting/modifying BLPCRIME, see Wikipedia talk:Biographies of living persons #Let's put this to rest.

The RfC: Wikipedia talk:Biographies of living persons#RFC: Amount of coverage in reliable primary news sources is still open. Some1 (talk) 02:51, 1 October 2025 (UTC)[reply]

FOO, the more we write, the more we have to wonder whether there's consensus for everything we're writing. I suggest starting small. "Folks, consensus is still a policy" is a pretty minimal thing to add. "Here are the factors I want to explicitly state that the consensus should prioritize" is a bigger lift. WhatamIdoing (talk) 01:17, 3 October 2025 (UTC)[reply]

That makes sense. FactOrOpinion (talk) 03:50, 3 October 2025 (UTC)[reply]

User:Larry Sanger/Nine Theses

Discussion at talk. See also WP:Village pump (miscellaneous)#User:Larry Sanger/Nine Theses 122.57.226.92 (talk) 10:46, 3 October 2025 (UTC)[reply]

Copyrights: links to non-open access articles

I'm not sure if I posted at the right place, but anyways:

If I saved an academic research paper via institutional account, one that's otherwise unavailable on the internet,

uploaded the PDF to Internet Archive, then linked to it in an WP article's references, would that be copyright infringement and a really terrible/stupid/bad thing for me to do?

iris 6:54p (+8), edited 6:58p 海盐沙冰 _{/ aka irisChronomia / Talk} 10:58, 3 October 2025 (UTC)[reply]

That would very likely be an infringement, unless the article had a license that permitted reproduction. And so should not be put on archive.org, and not linked from Wikipedia. Graeme Bartlett (talk) 11:56, 3 October 2025 (UTC)[reply]

Thank you, it's good to have a confirmation on my idea's terribleness. :) 海盐沙冰 _{/ aka irisChronomia / Talk} 12:17, 3 October 2025 (UTC)[reply]

But to add, you absolutely can still cite that as long as you yourself can view and confirm the article contents and know that even with PAYWALL issues, a reader should be able to as well, so do not back away from using those. Like, most papers have DOI information which helps to locate the source via the journal or publisher itself, so that should be in the reference. Also keep in mind that we have the Wikimedia Library Card that helps anyone with an WP account in standing to access numerous academic journal libraries. Masem (t) 12:47, 3 October 2025 (UTC)[reply]

Yep. I came up with that idea when thinking about the accessibility of citations, because I've always wanted to verify / read in detail many of the MEDRS before my extended confirmation. Remembering that feeling, I try to make it easier for other readers to verify an article (especially for empirical sciences) whenever I'm reading the original text through the Library. I now settled on supplementing non-open citations with quotes and/or other open-access papers.

I think the Library is a truly marvelous ~~invention~~ thing to have in this world, especially for individuals / populations unable to access higher education. I always had a passionate love / appreciation of the WP/WM, for gifting me free access to high quality sources and papers I would otherwise never even dream of.

Cheers :) posted 15:07, edited 15:12 UTC 海盐沙冰 _{/ aka irisChronomia / Talk} 15:12, 3 October 2025 (UTC)[reply]

Discussion at Wikipedia:Administrators' noticeboard § Addition of abusefilter-modify-restricted right to EFMs

You are invited to join the discussion at Wikipedia:Administrators' noticeboard § Addition of abusefilter-modify-restricted right to EFMs. Daniel Quinlan (talk) 09:18, 4 October 2025 (UTC)[reply]

Airport destination lists - WP:NOTGUIDE?

There is a huge problem with airport destination lists, in that they are huge, unwieldy, very dynamic and largely unsourced or difficult to source. In my, and others (Courtesy pinging @AndyTheGrump and @EEng as said persons), opinions, they fall foul of WP:NOTGUIDE, as they are nothing more than a huge list of destinations served by airlines operating at an airport. In my personal opinion, they would be better replaced with text, something along the lines of "X number of airlines fly from Airport A, serving destinations across Y number of countries." Currently, these tables are atrociously sourced, being largely unsourced, and efforts to improve sourcing over the last few months have led to no fewer than 3 ANI discussions ([10], [11], [12]), with the quite understandable result that some well-respected editors are tired of the constant back and forth - Not a month goes by that we don't get a report here of some cosmic struggle over lists of destinations reachable from various airports.[13].

In my opinion, these destination lists should be removed from airport articles under WP:NOTGUIDE, as they, as AndyTheGrump said, are arguably fancruft - but definitely not encyclopaedic. There are plenty of websites to get travel information, Wikipedia isn't one of them. If not removed, they should be seriously looked at with a view to fundamentally altering them. Danners430 _{tweaks made} 13:39, 5 October 2025 (UTC)[reply]

Can you perhaps give use some examples of the more ridiculous destination tables? 10mmsocket (talk) 13:51, 5 October 2025 (UTC)[reply]

One of the worst I've come across is Shanghai Pudong International Airport, which before I stripped out the huge amount of unsourced stuff had no fewer than 87 airlines, serving 585 destinations (if my quick flirt with Excel is accurate). Danners430 _{tweaks made} 14:08, 5 October 2025 (UTC)[reply]

I am not a fan of these tables. I think they go against much of what Wikipedia is about including WP:NOTEVERYTHING and WP:NOTTRAVEL. Even when they are properly sourced, which is rarely the case, as they're a magnet for undisciplined (mostly) IP editors, I still feel they are planespotter fancruft and they don't belong. 10mmsocket (talk) 13:54, 5 October 2025 (UTC)[reply]

Describing the content in question as "a huge list of destinations served by airlines operating at an airport" is generally stretching things. What they almost always are is a list of destinations that may possibly have been served by airlines at some unspecified point in time. Destinations are frequently unsourced, meaning that the reader can't tell whether they might have been served two weeks ago, or ten years. Even when sourced, they are rarely up to date enough to even be marginally useful as a guide (which per Wikipedia policy, we aren't supposed to be providing anyway). If people want to know such things, they should be looking elsewhere, for information they can rely on. And if aviation fans want to compile such bloated unencyclopedic and pointless lists, they should take them elsewhere. AndyTheGrump (talk) 14:01, 5 October 2025 (UTC)[reply]

There is previously already two RFCs made on this topic on whether or not airport destinations lists on airport articles violates WP:NOTRAVEL which the first one is 2023 RfC on lists of airline destinations from November 2023 which says that the consensus is where airline destinations lists can only be included if reliable, independent and secondary sources demonstrate they meet WP:DUE but no consensus on whether to remove listings destinations itself, the second one Wikipedia talk:What Wikipedia is not/Archive 60 from January 2025 reached a consensus that both List of airlines destinations articles and airport destinations lists don't violate WP:NOTRAVEL despite of it being a tight vote, if I can recall back correctly, somewhere in the article some users did brought up about the concerns that it's problems would still exists even if with reliable sources mainly because sources like AeroRoutes depends most on primary, non-independent sources (If it isn't there it might be from another similar discussion thread or from a List of Airlines destinations article deletion discussion which I kinda forgot where it was but I remember one user mentioning it), this problem about if these lists should be on Wikipedia along with List of airlines destinations has been a persistent problem among many editors since 2023 (based on what I am more familiar with) Metrosfan (talk) 14:57, 5 October 2025 (UTC)[reply]

I'm in full agreement with AndytheGrump here. A giant list of exact offerings of an airport isn't remotely encyclopedic and just crufty, as would listing all 40,000+ McDonald's franchises for the McDonald's article or all Microsoft employees for the Microsoft article. This is very different from specific notable flights, like, for example, if an airport was known as the only connector for a famous, remote location with no major airport of its own. They're not harmless here, either; there's a tendency in crufty areas to defend any removal of this content like they're fighting at the Alamo. CoffeeCrumbs (talk) 14:58, 5 October 2025 (UTC)[reply]

I fully agree that a complete list of all destinations from an airport is failing WP:NOT in multiple places. I can absolutely see cases where third-party reliable sources broadly list major destination hubs (particularly for regional airports), but since airliners can switch routes to any destination at any time, a full list makes zero sense and impractical to keep up. That level of detail is fine at Wikitravel, but not here. Masem (t) 15:06, 5 October 2025 (UTC)[reply]

I think airport articles should list the airlines that serve it, but not the destinations. Blueboar (talk) 15:37, 5 October 2025 (UTC)[reply]

I’d say that’s a good compromise… easy enough to source too, which in hindsight my suggestion of giving the number of countries served wouldn’t. Danners430 _{tweaks made} 15:41, 5 October 2025 (UTC)[reply]

Agree, that's a very good idea and easy to source 10mmsocket (talk) 15:58, 5 October 2025 (UTC)[reply]

As a traveller, rather than as a Wiki editor, I did / do find these lists very very useful, and I'm someone with both GDS and Amadeus access, unlike most travellers. If you discovered your LHR or LGW to Frankfurt flight was cancelled then it was / is a fast way to find out that actually Ryanair goes to Hahn from Stansted, for example, and thus presents a solution to a problem. I absolutely agree with the verification "issues", and I don't have a neat solution (unfortunately). But in terms of Wikipedia adding value it was often my first port of call. I would personally prefer any changes to go via WP:PRESERVE and WP:COMMUNICATION and WP:TEAMWORK, while seeking an ever more accurate encyclopedia, but I'm sure that's not a problem. ChrysGalley (talk) 16:08, 5 October 2025 (UTC)[reply]
Right - but that’s precisely what WP:NOTRAVEL is about. This is an encyclopaedia, not a travel guide. WikiTravel exists for that. Danners430 _{tweaks made} 16:10, 5 October 2025 (UTC)[reply]
Indeed, the revelation that there are people using these destination lists to reroute themselves while sitting on a baggage carousel somewhere -- that's just about the best argument so far for deleting such lists from all airport articles right now, no exceptions. E Eng 22:13, 5 October 2025 (UTC)[reply]

It's also useful to know where there's another McDonald's nearby and the one nearest me is closed and I really want an Egg McMuffin, but there are far more practical places to find that information than an encyclopedia entry about McDonald's. CoffeeCrumbs (talk) 02:00, 6 October 2025 (UTC)[reply]

Even there, some airlines fly some routes seasonally, so you have editors adding the airline/route in when it is active and then deleting it a few months later when they stop flying. Not encyclopedic. Donald Albury 16:13, 5 October 2025 (UTC)[reply]

It should be limited to airlines with "permanent" installations at the airport, not the low-cost/budgets that rent out services. And yes, major airlines can leave or set up in airports, but that's usually the type of news that will be covered by local reliable sources, so that's fair to document. Masem (t) 16:21, 5 October 2025 (UTC)[reply]

I wouldn’t necessarily use “having permanent installations” as the line… that would seem a little odd as there’s nothing wrong with the low-cost carriers. Instead I’d say limit it to carriers with a “permanent” presence - ie they’re not seasonal (although if it’s a permanent or regular seasonal route…?), it’s not a charter, but it’s a regular route. Danners430 _{tweaks made} 16:37, 5 October 2025 (UTC)[reply]

@Donald Albury: We also have the situation where editors are quick to add new airlines/routes/destinations, perhaps some time before the actual start date, but nobody bothers to remove them once they cease. This show that it is fallacious for ChrysGalley to use Wikipedia to find out that actually Ryanair goes to Hahn from Stansted. Other websites exists for this purpose, and they have an obligation to ensure that their information is up to date. We don't have that obligation. --Redrose64 🌹 (talk) 16:50, 5 October 2025 (UTC)[reply]

I think Masem makes the most relevant point, which is that airlines can switch routes to any destination at any time, often without any reliable sources being created. Many other companies' products take some time to work their way through, so in those cases it is possible for us to list them all. In general Wikipedia seems to attract enthusiasts of various kinds, such as train-spotters and weather-watchers and beetle-fanciers and plane-spotters (of whom I was one for a couple of years over half a century ago, but then I discovered girls). They are very useful, but sometimes their enthusiasm needs to be reined in. Phil Bridger (talk) 16:44, 5 October 2025 (UTC)[reply]

I really think that it's unfair to lump beetle-fanciers in with those other groups. The Creator only evolves new beetles every 50 million years or so, so it's maintainable (though very, very large) list. E Eng 21:31, 5 October 2025 (UTC)[reply]

Are you sure? With 400,000 described species of beetle (plus more that are (probably) yet to be described) the age of this planet works out at 20 million million years. Most recent estimates are somewhat less. --Redrose64 🌹 (talk) 21:50, 5 October 2025 (UTC)[reply]

I said beetles, plural. They come in spurts. E Eng 22:21, 5 October 2025 (UTC)[reply]

Yes, girls are very useful, and some can indeed be enthusiastic. --Redrose64 🌹 (talk) 16:51, 5 October 2025 (UTC)[reply]

We should really create a list of quotes in your user space 🤣 Danners430 _{tweaks made} 16:56, 5 October 2025 (UTC)[reply]

As a trainspotter myself, I can only agree. Most of my work on the project has been in WP:WikiProject UK Railways, working to clean up the fancruft and unsourced nonsense there… what I found in the Airport and Airline wiki projects was a bit of a shock to the system after a few years with the rail articles in good shape! Danners430 _{tweaks made} 16:47, 5 October 2025 (UTC)[reply]

I have quit bothering to look at changes on the airport articles on my watchlist. They are predominately changes to airlines/destinations, usually unsourced, and any attempts I made in the past to deal with them were quickly reverted. As I try very hard not to edit war, and no other editors active on those articles agreed with my edits, I moved on. Donald Albury 17:25, 5 October 2025 (UTC)[reply]

Ok so first off... My bias: I really like the airport destination lists, I especially like when someone takes that list and makes a map out of it. With that being said I think that almost all of the criticisms being leveled at them are relevant, however the one thing I would note is that many airports will be the subject of articles specifically covering the various destinations they fly to, its not exactly hard hitting journalism but it is sigcov. Where I think we get into trouble is trying to make it consistent across all airports, even ones that don't have regular or any independent coverage of their routing. Horse Eye's Back (talk) 17:26, 5 October 2025 (UTC)[reply]

I also like these airport destination lists, but every time I see them, I always wonder if they're regularly updated or accurate. The Minneapolis–Saint Paul International Airport#Airlines and destinations table, for example, has so many uncited entries that it's practically useless. I don't oppose the inclusion of these tables/lists though, provided that they're up-to-date (and accurate, obviously). Some1 (talk) 22:36, 5 October 2025 (UTC)[reply]

Every row has a citation to the airline timetables that make it fairly easily to verify the destinations.There are a lot of people who do work pretty hard to keep these correct and informative, and nowadays with more sources rather than the previous practice of trimming them. I find outdated information on Wikipedia all the time and then correct or remove it, but that's not a great reason to ban the topic altogether. That's the beauty of the project. — Reywas92^Talk 15:24, 6 October 2025 (UTC)[reply]

Let me suggest a test for whether or not information subject to change should, or should not, be included in an article:

In general ... If, when a piece of information changes, the old version of the information is not going to be preserved somewhere in the article (or, perhaps, some related History of X article), then the information shouldn't have been in the article in the first place, because it's apparently of no enduring value -- enduring value being part of the test for what belongs in articles.

Examples:

A subject's marital status is subject to change. But if the subject gets divorced and remarries, then the article will of course note not only the new marriage but the prior marriages as well. So matrimonial status passes the test.
Ruritania's GNP is subject to change. But the history of its GNP over the years is definitely something that belongs in Ruritania's article (or perhaps the Economy of Ruritania article.) So GNP passes the test.
The destinations reachable from JFK Airport is constantly changing, and there's a hardcore group of editors that seem very interested in keeping that information up to date. But even that hardcore group would not (I hope) argue that we should have an article History of Destinations Reachable from JFK Airport article, because no one in ten years, or even next year, or even next month, will care what the destination list was yesterday. So JFK's destination list does not pass the test, and does not belong in the article.

I thought up this test in the shower 5 minutes ago, so no doubt it could stand refinement. But perhaps it's a start.

E Eng 22:07, 5 October 2025 (UTC) P.S. Someone suggested above that, in place of detailed destination lists, articles report X number of airlines fly from Airport A, serving destinations across Y number of countries. But even that requires constant updating (and perhaps some OR in combining the country lists for multiple carriers in order to obtain a comprehensive country count). My counteroffer is this: "Some [approximate X number] of airlines fly from Airport A, serving destinations across Y number of continents". That should be easy to keep up to date.[reply]

To add to that comparison, railroad routes (but not schedule) are generally okay because you can't easily reorganize railroad tracks. Train companies may change what stops a specific route may stop at, but generally, like for London, explaining that it connects to multiple other UK cities as well as Paris, seems completely fair. Masem (t) 22:47, 5 October 2025 (UTC)[reply]

Although keeping stopping patterns of a rail line up to date is equally a minefield… I try to steer well clear Danners430 _{tweaks made} 22:48, 5 October 2025 (UTC)[reply]

The one problem with the test: someone who really likes making sure every airline route must be on an encyclopedia page about the airport may say "good point, these SHOULD be preserved!" and be determined to also maintain a historial table of every route that ever existed at the airport. CoffeeCrumbs (talk) 02:03, 6 October 2025 (UTC)[reply]

Yes, but that will never get community approval. E Eng 03:07, 6 October 2025 (UTC)[reply]

For better or worse, airports can be measured in their importance by the number of flights they have. So perhaps a third option, to be considered where sources exist without WP:SYNTH - some airports list the number of aircraft movements they have, or the number of flights they have in corporate documentation. Perhaps this, if such a source exists, could be added? Danners430 _{tweaks made} 22:24, 5 October 2025 (UTC)[reply]
I would think many or most airports report the # of departures per day, and gross passenger figures. Those probably bear including. E Eng 22:45, 5 October 2025 (UTC)[reply]
Just a note that there are editors discussing this topic on my talk page - I have invited them here, but they don’t wish to participate… but it’s another viewpoint that editors here may wish to consider. Danners430 _{tweaks made} 22:25, 5 October 2025 (UTC)[reply]
In that discussion I see people arguing that not just passenger routes, but cargo (!) routes as well, should be listed. That sets a new low for fancruft, and shows the truly bizarre lack of common sense that sometimes comes into these discussions. E Eng 22:45, 5 October 2025 (UTC)[reply]
The lists are useful, frequently updated and usually correct. Wikipedia happens to be the best place on the Internet for this information. We have discussed this many times already and never found consensus to destroy this wonderful resource, even though the discussion is usually in a place that violates WP:LEOPARD. Can we please give it a rest? —Kusma (talk) 22:26, 5 October 2025 (UTC)[reply]
useful, frequently updated and usually correct – You might very well be able to say that same about List of products sold by Trader Joe's, if for some reason such an article had flown under the radar for a while -- but it wouldn't be an argument for keeping it. E Eng 22:45, 5 October 2025 (UTC)[reply]
These lists are pure fancruft and should be split into their own air travel enthusiast wikis. I don't believe at all that anyone actually "uses" them in the claimed last-minute cancellation situations. I would guess the only readers who look at these lists are those who are already overly into that stuff. JoelleJay (talk) 23:10, 5 October 2025 (UTC)[reply]
For sure. I mean, look at this edit [14] to Atlanta International Airport -- the edit summary for which is Delta Airlines has ended flights to Fresno. Think about it. Really? REALLY? It is so that readers can keep abreast of the breaking news that Delta Airlines no longer flies from ATL to Fresno that dozens of editors at ANI have to referee, week after week, dumb disputes over sourcing for such junk -- in order to maintain this pointless gargantuan list [15]? And then look at the Top destinations section in that same article [16], which tells us (among other things) that 358,860 (precisely, I guess) passengers flew from ATL to Lima, Peru last year. SO WHAT? Who cares? What is the point of all this? There may be people who tell themselves that such stuff is part of the beautiful tapestry that is Wikipedia, but they're fooling themselves. It's a pointless slagheap of worthless miscellany that saps community time for no purpose, other than to give a certain kind of editor a hobby (i.e. copy-pasting numbers from a US Government website [17][18].) E Eng 23:43, 5 October 2025 (UTC)[reply]
This just seems gratuitously derogatory and hyperbolic... Do you actually mean what you're written here or should we interpet it more as an emotional word salad/poem? Horse Eye's Back (talk) 01:01, 6 October 2025 (UTC)[reply]
Yes, I mean every word. I have little patience for fanboys of any flavor who waste community time. The fact of the matter is that the quality of the editors involved in a given topic area (in terms of their ability to grasp and adhere to P&G's, judge and interpret sources, work with other editors effectively, and so on) is inversely proportional to the triviality of that topic area. That's why, historically, we get so much traffic at ANI regarding: footy players, beauty pageants, music subgenres, pornstars, anything related to Ru Paul, video games, Japanese comics and animation, Indian cricket, railroad rolling stock specs, vehicle production dates, unrecognized micronations, every little named storm anywhere on earth, AND ESPECIALLY "PRO" WRESTLING!!! E Eng 01:20, 6 October 2025 (UTC)[reply]
I also have little patience for fanboys of any flavor who waste community time... And the battle scars to prove it... But I think we should be more charitable here, with all the actual coverage we aren't in fanboy territory all the time. Even if we take a rather harsh position there are still going to be some airports where a destination list is going to be due, arguably there are even a tiny fraction of the total where a standalone destination list would be due since theres so much sigcov. Horse Eye's Back (talk) 15:52, 6 October 2025 (UTC)[reply]

Great point about the top destination tables, and don't even get me started on flags. Country flags are bad enought, but state flags? FFS! At least all the UK airport article tables are now flag-free. 10mmsocket (talk) 07:03, 6 October 2025 (UTC)[reply]
I think that it is past time the lists were removed. At one time things like these, and other materials, were needed to grow the encyclopedia but they have outlived their usefulness with the growth of sister projects. They certainly violate Wikipedia:What Wikipedia is not#Wikipedia is not a manual, guidebook, textbook, or scientific journal. The tables may be of assistance to some readers but they don't need to be here. The list should be sent to Wikivoyage, not Wikitravel, as a sister site. The tables don't even follow Wikipedia:Manual of Style/Text formatting#When not to use boldface, in that Seasonal is always bold and any attempts to remove it is reverted. Sourcing, if it exists is poor, I found one sourced to Wikivoyage.
Danners430 can you clarify "For better or worse, airports can be measured in their importance by the number of flights they have."? Did you mean in relation to Wikipedia or in general? If in general then that's not always the case. CambridgeBayWeather (#1 deranged), Uqaqtuq (talk), Huliva 00:45, 6 October 2025 (UTC)[reply]
It’s more a measure of public perception of an airport - for example why Heathrow is seen as more important than Gatwick. I’ve no objection to not include the info I proposed, just a suggestion :) Danners430 _{tweaks made} 07:21, 6 October 2025 (UTC)[reply]
As another editor pointed out above, the November 2023 RfC (Wikipedia:Village pump (policy)/Archive 187 § RfC on the "Airlines and destinations" tables in airport articles) found that there is consensus that airlines and destination tables may only be included in articles when independent, reliable, secondary sources demonstrate they meet WP:DUE. There is not a consensus for wholesale removal of such tables, but tables without independent, reliable, secondary sourcing, and where such sourcing cannot be found, should not be in the articles. Do editors here think that the outcome of another RfC will be any different than the one from two years ago? Some1 (talk) 01:03, 6 October 2025 (UTC)[reply]
I'm glad you pointed that out, since it looks like most or all of this stuff is sourced to primary sources such as airline websites -- not indep, rel, sec sources -- and therefore the DUE test is failed. E Eng 01:20, 6 October 2025 (UTC)[reply]
The way I interpret this consensus is that one may remove the tables page by page after evaluating and coming to the conclusion that the table does not meet the DUE test. Wholesale removal (i.e. mass removal of all tables) is not allowed as there could be some tables that might meet the DUE test. – robertsky (talk) 01:34, 6 October 2025 (UTC)[reply]
Maybe I'm not making myself clear. AFAICS, these tables are never supported by secondary sources, but rather primary sources such as searches on each airline's "Buy-a-ticket" website e.g. for Atlanta Intl Airport, the destination list for Delta is cited to this Delta website [19] (on which you then have to run a query), and the one for British Airways is cited to [20] (and I don't see how the ATL destination list was extracted from that one). Not only are these primary sources, but running a query on a website is blatant WP:OR; any content sourced that way should be removed right now -- no Village Pump needed. The more one looks at this stuff, the more bankrupt it turns out to be. E Eng 02:59, 6 October 2025 (UTC)[reply]
The proposal that airlines that serve an airport is acceptable content in an airport article sounds good to me - there's almost always at the very least a press release when an airline inaugurate scheduled services from a new airport, and while WP:PRIMARY that is acceptable for citing simple facts (such as, for instance, that Fooian Airlines serves Barford International Airport) - and usually when an airline stops service to an airport this gets reported in at least the local newspaper. Routes on the other hand are sometimes - maybe even often - ephemeral things, subject to change at a moment's notice and without any notification sometimes other than being added or removed from the flight-boards in the terminal, and so destinations served lists are absolutely in violation of WP:NOTTRAVEL if not, in a wide number - I won't say the vast majority, but it's probably close - of cases failing WP:V, which is our single most important and fundamental PAG. - The Bushranger _{One ping only} 01:49, 6 October 2025 (UTC)[reply]
If I'm reading the closure correctly, the RfC from eight months ago (RfC on WP:NOT and British Airways destinations) found that these lists aren't in violation of WP:NOT. Some1 (talk) 02:02, 6 October 2025 (UTC)[reply]
When properly sourced with independent sources - but out of the hundreds of routes on a typical route table, perhaps a small fraction use true independent sources, most using first party sources. Danners430 _{tweaks made} 07:23, 6 October 2025 (UTC)[reply]
I have sometimes seen these articles when pending changes reviewing and have found the practice rather confusing to deal with, particularly as it seemed to go against WP:NOTGUIDE but the precedent of inclusion was clearly prevalent in such articles. Reviewing at least would become easier if the articles no longer contained such lists. Perfect4th (talk) 03:33, 6 October 2025 (UTC)[reply]
One thing i wanna note about these articles is that from what ive seen most of the time most editors focus more on the airline destinations list itself and there isnt as much edits when it comes to other parts of the article like history, terminals,etc Metrosfan (talk) 06:29, 6 October 2025 (UTC)[reply]
I am fully in agreement with Kusma, airport destinations are one of the things we do very well, and from my experience they're generally well referenced, updated regularly and accurate. This is something Wikipedia does really well that other sites don't, and I've been using them for pretty much the past 20 years when planning travel myself. And let's face it, the destinations you can reach from an airport is a fundamental part of thr information about that airport anyway. I would oppose a GA or FAC that omitted such info as incomplete. We should be praising those who work in this, not tossing out their work for entirely bureaucratic reasons. — Amakuru (talk) 07:04, 6 October 2025 (UTC)[reply]
Poor sourcing isn’t a bureaucratic reason - it’s breaching a core Wikipedia policy. Danners430 _{tweaks made} 07:25, 6 October 2025 (UTC)[reply]
They're not poorly sourced though. I've just checked Bucharest Henri Coandă International Airport as a random example and every destination there has a reference. There are so many areas of Wikipedia that are out of date, unsourced, inaccurate and frankly useless to readers, yet you choose to attack an area of the project that is none of those things. And, as noted above, the notion that the lists violate WP:NOT was already rejected in the RFC at [21], so even the supposed policy basis for this has not been accepted by the community. — Amakuru (talk) 07:58, 6 October 2025 (UTC)[reply]
You’ve picked a cherry in a pile of moss then… here’s the opposite example, or rather the unsourced being stripped from it… [22] Danners430 _{tweaks made} 08:22, 6 October 2025 (UTC)[reply]

I checked all the capital city airports in Australia, my home. In alphabetical order: Adelaide is partly sourced; Brisbane is partly sourced; Canberra is partly sourced; Darwin is fully sourced; Hobart is partly sourced; Melbourne is partly sourced; Perth is partly sourced; Sydney is partly sourced. And these are the main airports in each state - if any Australian airports should be properly sourced, it should be these. But they're not, except for little Darwin and its twelve destinations. You may have gotten lucky with your random airport. Meadowlark (talk) 09:12, 6 October 2025 (UTC)[reply]
Part of the issue is that most of that sourcing is based on 1st party press releases, or from the website Aeroroutes, which is a one-person "trainspotting" equivalent that just tracks all those press release notices. That doesn't equate to the type of independent sourcing we would expect for supporting these lists. Masem (t) 12:09, 6 October 2025 (UTC)[reply]
i mean, not to mentioned though, other US airport pages like Los Angeles International Airport, if y'all observed and seen there's a separate ref section on the table, which each airline (yeah it's not independent sources per texted) has a source which is uh, flight timetable nor flightmap, or maybe both.... Drcarrot.phd (talk) 14:44, 6 October 2025 (UTC)[reply]
What? E Eng 15:25, 6 October 2025 (UTC)[reply]
This was already discussed just this year at Wikipedia talk:What Wikipedia is not/Archive 60#RfC on WP:NOT and British Airways destinations, closed as clear consensus that these lists are not indiscriminate information and do not violate WP:NOT. It is wildly inappropriate to propose deleting longstanding, well-maintainted information across hundreds of widely read articles for the same tired reasons yet again. These are simple lists of destinations but without schedules or other details; they are not remotely a travel guide merely for having travel-related information. They instead provide the entire purpose of the airports with what businesses and markets they serve. The fact that it's informative and useful does not mean it's forbidden! Sourcing has significantly improved since recent discussions on these that have changed the previous practice of removing destination-specific sources after an announced route has begun. We should continue these improvements, not make the project worse. Reywas92^Talk 15:05, 6 October 2025 (UTC)[reply]
Sourcing has significantly improved – That's a shocking indictment of what the sourcing must have been like before. Here's how Aeroroutes -- apparently the go-to source for these lists -- describes itself [23]:
AeroRoutes is the successor of daily worldwide airline schedule/network changes from April 2022, independently owned Jim Liu ... Mainly based in Vancouver, Canada, Jim is an airline schedule nerd, started collecting airline timetables since 9, and has been staring at flight schedules via various platforms for almost 30 years ...

That's what literally thousands of our articles are based on.

And since we're here, let's look at some other "sources". For example, in the Atlanta Airport article, the Delta destination list is cited to this url [24]. Now tell us please, Reywas92: where in there is the list of destinations to which Delta flies from ATL? Or -- oh wait! -- actually, the citation gives us an archive.org url ("archived from the original") [25]. Please tell us where in there we look to find the list of destinations? E Eng 15:25, 6 October 2025 (UTC)[reply]
All you have to do is click "Filter", select operated by Delta Air Lines, and select only Nonstop. Voila! There's your destinations! It's indeed verifiable, and the results are not required to be at a specific URL. But Delta does have PDF timetables, so we could also add [26] and [27]. We could also add other third-party sites like [28] and [29], but it's nice that Wikipedia has this data links to the other airport articles and without ads. I mean, it seems you didn't know how to use Delta's website to find the info, so I think it's great that we compile it as a simple list. Again, past practice was to remove destination-specific sources with a route's starting date and then only citing the timetables, but as those are retained these thousands of articles will gradually improve. — Reywas92^Talk 16:29, 6 October 2025 (UTC)[reply]

All you have to do is click "Filter", select operated by Delta Air Lines, and select only Nonstop. – I thought you might say that. Problem is, when I do that it says "247 Cities Available from ATL", yet the article lists only about 200 cities. How do you explain that? E Eng 16:59, 6 October 2025 (UTC)[reply]