Thepolicy section of thevillage pump is intended for discussions about already-proposedpolicies 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 somethingnew that isnot a policy or guideline, useVillage 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 manyWikipedia:Noticeboards.
If you want to inquire about what the policy is on a specific topic, visit theHelp desk or theTeahouse.
This isnot the place to resolve disputes regarding the implementation of policies. For such cases, consultWikipedia:Dispute resolution.
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 ofWP: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 ([1],[2],[3]), 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.[4].
In my opinion, these destination lists should be removed from airport articles underWP: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.Danners430tweaks made13:39, 5 October 2025 (UTC)[reply]
I am not a fan of these tables. I think they go against much of what Wikipedia is about includingWP:NOTEVERYTHING andWP: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 thatmay 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 violatesWP:NOTRAVEL which the first one is2023 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 meetWP:DUE but no consensus on whether to remove listings destinations itself, the second oneWikipedia 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 violateWP: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 specificnotable 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]
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 viaWP:PRESERVE andWP:COMMUNICATION andWP: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]
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.EEng22: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 Ireally 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 theairline/route in when it is active and then deleting it a few months later when they stop flying. Not encyclopedic.Donald Albury16: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.Danners430tweaks made16: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 forChrysGalley to use Wikipediato 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 airlinescan 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.EEng21:31, 5 October 2025 (UTC)[reply]
Are you sure? With 400,000 described species ofbeetle (plus more that are (probably) yet to be described) the age of this planet works out at 20 million million years. Most recent estimates aresomewhat less. --Redrose64 🌹 (talk)21:50, 5 October 2025 (UTC)[reply]
As a trainspotter myself, I can only agree. Most of my work on the project has been inWP: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!Danners430tweaks made16: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 Albury17: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. TheMinneapolis–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. — Reywas92Talk15: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, theold version of the information is not going to be preserved somewhere in the article (or, perhaps, some relatedHistory 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 theEconomy 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 articleHistory 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 listdoes 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.
EEng22:07, 5 October 2025 (UTC) P.S. Someone suggested above that, in place of detailed destination lists, articles reportX 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]
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]
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 withoutWP: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?Danners430tweaks made22: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.EEng22: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.Danners430tweaks made22: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.EEng22: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 violatesWP: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 aboutList of products sold byTrader 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.EEng22: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[5] toAtlanta International Airport -- the edit summary for which isDelta 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[6]? And then look at theTop destinations section in that same article[7], 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[8][9].)EEng23: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!!!EEng01: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]
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 :)Danners430tweaks made07: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 thatthere 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.EEng01: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[10] (on which you then have to run a query), and the one for British Airways is cited to[11] (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 blatantWP:OR; any content sourced that way should be removedright now -- no Village Pump needed. The more one looks at this stuff, the more bankrupt it turns out to be.EEng02:59, 6 October 2025 (UTC)[reply]
The proposal thatairlines 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 whileWP:PRIMARY that is acceptable for citing simple facts (such as, for instance, that Fooian Airlines serves Barford International Airport) - andusually when an airlinestops 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 sodestinations served lists are absolutely in violation ofWP:NOTTRAVEL if not, in a wide number - I won't saythe vast majority, but it's probably close - of cases failingWP:V, which is our single most important and fundamental PAG. -The BushrangerOne ping only01:49, 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.Danners430tweaks made07:23, 6 October 2025 (UTC)[reply]
Yeah, I'm with Bushranger on this. The fact thatTed Stevens Anchorage International Airport has both historically and in the present day connects many Asian cities (like Tokyo) to North American/European ones, due to both Cold War and its location, is source(able) to secondary sources and important to include. The fact that it's used by regional carriers to connect Anchorage to the Bush is, again, likely sourceable and important; probably many of them should be mentioned, too! The fact thatIliamna Air Taxi specifically will take you toIliamna Airport inIliamna, Alaska, population 108 as of the last census, is probably not.GreenLipstickLesbian💌🦋06:51, 7 October 2025 (UTC)[reply]
The fact that you can get from Iliamna to Anchorage, though, is very important to know about Iliamna Airport, for it tells you how it is connected to the world.SportingFlyerT·C21:12, 7 October 2025 (UTC)[reply]
Certainly what we'd expect at a regional airport would be different from a major hub, and I would actually expect asymmetric info here (Iliamna mentioning what hubs one can get to, but not at hubs of which fly to Iliamna). A broad picture of connected cities for any airport makes sense but the resolution should be much higher level for system hubs compared to smaller ones.Masem (t)21:19, 7 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,etcMetrosfan (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]
They're not poorly sourced though. I've just checkedBucharest 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[12], so even the supposed policy basis for this has not been accepted by the community. — Amakuru (talk)07:58, 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 likeLos 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]
The requirements on sourcing have changed over time, though - looking at Melbourne, it wouldn't be surprising if many of the partially sourced routes are ones which pre-dated the old requirements. My local paper is very good at announcing new routes.SportingFlyerT·C16:42, 9 October 2025 (UTC)[reply]
What do you mean byThe requirements on sourcing have changed over time? If you mean some fantasy "requirements" put forth by some Wikiproject, that's irrelevant because Wikiprojects have no authority to override project-wide policies and guidelines. And if you mean said project-wide policies and guidelines, the requirements of verifiability, no original research, and so on have been there for decades.EEng19:35, 9 October 2025 (UTC)[reply]
At this point with so many being considered SPS, UGS and deprecated sources, I just agree to delete it altogether. Easy to manage and only put airport facts and progress specifically.
Kinda sad unregistered normal community not going to use wiki as a first look on the destinations the airport served anymore because we want to keep following the guideline to the tee. That's all I have to say.Lowyat Slyder (talk)16:23, 22 October 2025 (UTC)[reply]
This was already discussed just this year atWikipedia talk:What Wikipedia is not/Archive 60#RfC on WP:NOT and British Airways destinations, closed asclear consensus that these lists are not indiscriminate information and donot 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.Reywas92Talk15: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[14]:
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 theAtlanta Airport article, the Delta destination list is cited to this url[15]. 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")[16]. Please tell us where in there we look to find the list of destinations?EEng15: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[17] and[18]. We could also add other third-party sites like[19] and[20], 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. — Reywas92Talk16:29, 6 October 2025 (UTC)[reply]
The need to use the airline or a avid plane watchers blog explemefies how these lists fail not only NOTGUIDE and also NOT#IINFO. Where there are dozens to hundreds of possible cities, in using them all with a majority of those based on such primary sourcing is a major issue.Masem (t)18:21, 6 October 2025 (UTC)[reply]
There was already a large discussion that found these do not violate WP:NOT, and I don't care to repeat this argument. There are also industry databases and other types of sources that are usable, but airline sources are perfectly verifiable as well. There is nothing wrong with primary sourcing either, as this is not going to be biased personal accounts. — Reywas92Talk18:36, 6 October 2025 (UTC)[reply]
As quoted from the RFC above, they don't violate NOT if they were sourced to independent third part sources. But they aren't, they heavily rely on primary sources.Masem (t)18:55, 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?EEng16:59, 6 October 2025 (UTC)[reply]
The "247" is counting them incorrectly. If you select List view in the bottom left, it organizes by continent but under "Asia, Middle East, & India (3)" Seoul is listed twice and under "Europe (21)" Amsterdam, London, and Paris are listed twice, plus many more in the other sections. If our article does actually have any inaccuracies, that's a reason to fix it, not delete the whole concept from thousands of pages.Reywas92Talk
So you're saying that the airline's own website counts the cities wrong, but you know how to massage the data to get the right answer? How is that not in direct contradiction ofWP:NOR, which forbids inclusion ofany analysis or synthesis of published material that reaches or implies a conclusion not stated by the sources? To repeat: you're telling me that the source has the wrong answer, but you know how to fix it. NOR requires thateach statement in the article being verifiable in a source that makes that statement explicitly. Source material should be carefully summarized or rephrased without changing its meaning. You are blatantly thumbing your nose at that, and it appears that's what's going on in all these lists.EEng19:13, 6 October 2025 (UTC)[reply]
WTF? Our article just lists the airports, it's not giving a specific number. I trust that the list of airports on Delta's site is correct, and it appears our list matches those. I'm NOT saying the source has the wrong answer, and nothing is being "fixed", as the question is where do their flights go, not how many flights are there. The Atlanta Airport article says that Delta flies from Atlanta to Albany, which is accurately verified on Delta's website, and not summarized or rephrased, certainly not changing any meaning, even if their route map system lists and counts it twice. In what universe is our article synthesizing anything by naming the cities? What unstated conclusion do you think the article is making? Seriously, what the hell are you accusing me of? I'm not putting any analysis in any article, certainly not one that makes a false conclusion. Simply excluding duplicates isn't even effing "massaging the data", it would be a simple count, here only on a talk page to explain why you don't know why the articlemight not be listing as many cities as they do. This is wildly out of line. — Reywas92Talk21:37, 6 October 2025 (UTC)[reply]
WTF yourself.
Following your instructions, the Delta website returns 247 "cities available from ATL", though the ATL article lists only 206 "destinations". You say the discrepancy is due to the website's 247 "cities available" containing duplicates. So I deduped the 247 down to unique airport codes, which resulted in a list of 230. That still doesn't match the 206 in the ATL article. How do explain that?
You also linked to Delta's flight schedule pdfs (domestic[21] and international[22]). But concatenating those lists and deduping gives a set of 282 destinations, which doesn't match the 206 destinations in the article, nor the 230 destinations obtained by deduping the search result, whichyou specified, on Delta's website. How do you explain that?
What you're exposing here is that this content can only be created through original research by editors, requiring non-trivial judgement-calls about what is/is not listed, that are (at most) only valid for a few days since destinations served change so quickly. There is no single source in which this kind of information can be verified as a whole.FOARP (talk)12:34, 7 October 2025 (UTC)[reply]
Except the ATL article doesn't only have 206 listed for Delta, you also have to count Delta Connection. I cross-checked our list against Delta's andevery single one except the suspended Tel Aviv is accurately verified on that page. So unless you have identified somewhere where Wikipedia is actually wrong, what exactly is the problem???? Cut the crap FOARP, I fail to see what judgement call was made on this page. — Reywas92Talk13:43, 7 October 2025 (UTC)[reply]
Going to jump in as someone not involved in this particular thread and advise everyone to cool off.Cut the crap,WTF andWTF yourself aren’t phrases I’d expect to see in a civil discussion.Danners430tweaks made13:45, 7 October 2025 (UTC)[reply]
the ATL article doesn't only have 206 listed for Delta, you also have to count Delta Connection – Uh huh. And how -- after we follow your directions toclick "Filter", select operated by Delta Air Lines, and select only Nonstop. Viola!, and then (as you go on to instruct us) dedupe the results -- do we distinguish the "Delta" destinations from the "Delta Connection" destinations?EEng05:31, 8 October 2025 (UTC)[reply]
Endeavor Air andSkyWest do publish their route maps[23][24] so those can be cited instead, it's not like this is unverifiable. Or let's just combine those rows in the table just list them all as Delta! That's been proposed before but wasn't adopted. I don't care precisely how it's presented, but that's no reason for it to be deleted altogether. — Reywas92Talk14:38, 8 October 2025 (UTC)[reply]
We should probably have a RSN discussion about Aeroroutes but it seems like an unnecessary tangent here... Whether or not Aeroroutes is a RS doesn't seem to be relevent to answering the core question at hand because its still an open question either way.Horse Eye's Back (talk)19:08, 6 October 2025 (UTC)[reply]
No, it's directly relevant. When material is inappropriate, it usually inappropriate in multiple ways. The fact that editors maintaining these lists are forced to scrape the bottom of the sourcing barrel, because there are no independent, reliable, secondary sources for them, is further evidence of the un-WP:DUE nature of those lists.EEng19:13, 6 October 2025 (UTC)[reply]
That Aeroroutes is used so heavily on these lists is a good sign that it wasn't out of laziness or error. Laziness or a mistake would br a reasonable interpretion if there were like one or two routes source to it while the rest were far better RSes.Masem (t)19:33, 6 October 2025 (UTC)[reply]
There has never been a RSN discussion on Aeroroutes, it currently appears to be a source in good standing so its harder to fault anyone who uses it. Laziness is not out of the question... My experience with fansites is that they're generally used out of laziness, they're essentiall a shortcut which means you don't have to track down the actual sources/do the hard work of weighing weight.Horse Eye's Back (talk)19:40, 6 October 2025 (UTC)[reply]
Just doing a basic check on it against the tenets of what a good RS is meant to be shows that it is basically a single user blog with no editorial oversight. The person running it frequently just uses schedule changes on flight databases as a means to report a route change, but thats a level of trivality we shouldn't be operating at as an encyclopedia. So it should not be considered reliable for these articles, certainly not for trying to summarize destination lists from an airport.Masem (t)12:14, 7 October 2025 (UTC)[reply]
Agree, this is literally a blog run by a company that does airline industry events. "Not independent" hardly covers it.FOARP (talk)12:30, 7 October 2025 (UTC)[reply]
Wikipedia is an encyclopedia, and one of the features of encyclopedias is that they contain a lot of information which most people consider stupid or boring. I, however, think it is good when there is information in an encyclopedia article, so I resist with manly firmness the perpetual attempts to remove it. Especially if there has been a consensus not to!jp×g🗯️05:10, 15 October 2025 (UTC)[reply]
There is no OR aspect here, these are very straightforward facts. These sources are perfectly reliable, no one has ever identified how these would result in wrong or biased information because of the type of source. A simple list without details is not a travel guide, as established by clear consensus at WP:NOT. — Reywas92Talk13:46, 7 October 2025 (UTC)[reply]
when independent, reliable, secondary sources demonstrate they meet due quote from the previous rfc closure in 2023. Most of the sourcing is not independent/secondary, the OR aspect is claiming that itsWP:DUE to include these tables based entire on primary sources. There is also OR that can occur when updating to remove no llonger served destinations. As for the clear consensus at WP:NOT archive 60 that was about TWO list articles, not the issue at hand.Lavalizard101 (talk)14:21, 7 October 2025 (UTC)[reply]
That's not what original research means.... there is no synthesis or analysis of anything to draw unsupported conclusions. You don't need sources to prove a negative since the articles do not say where the airline does not fly. You not liking the sources used does not mean this is original research, not to mention the improvements seen to add more sources. The previous discussion was clearly about the whole topic with those just as examples and commenters understood it as such.Obviously if consensus had been found against those articles, that would have been used against every other one, not actually limited to them. — Reywas92Talk14:43, 7 October 2025 (UTC)[reply]
Except per the rfcindependent, reliable, secondary sources are required, most of these are built on primary sources, its got nothing to do with me "not liking the sources" and everything to do with policy and the rfc requiring independent secondary sources. Heck if it were up to me personally most airport articles would be gutted down to just a secondary sourced blurb on history and maybe 2 or 3 paragraphs on facilities and operations.Lavalizard101 (talk)14:55, 7 October 2025 (UTC)[reply]
If you believe that independent secondary sources are required, why don't you add them? They're not difficult to find, at least for western countries. Just look in the biggest newspaper where the airport is located.WhatamIdoing (talk)18:13, 7 October 2025 (UTC)[reply]
I’m going to jump in here and say that these lists definitely do involve OR. This is particularly the case when an entry is removed without any positive announcement that the route is no longer being served, only it no longer being listed. Additionally, usually the table is compiled from a bunch of different data at different dates, and then presented as being the routes served on date X.FOARP (talk)22:40, 7 October 2025 (UTC)[reply]
Then you don't understandWP:OR - facts "for which no reliable, published source exists." Almost if not every air route will be announced and available somewhere.SportingFlyerT·C12:25, 8 October 2025 (UTC)[reply]
“X is terminated”, “Y is seasonal” is OR unless the links actually say that, but they almost never do. Additionally "This is a list of destinations served on DATE.[Reference from date years before DATE]" is clearly OR.FOARP (talk)06:56, 9 October 2025 (UTC)[reply]
It clearly is OR when they're saying "these are the service offered on DATE" and the list is in fact a list of services that were possibly planned and/or listed on their website at some point, often years before.FOARP (talk)07:03, 13 October 2025 (UTC)[reply]
"Then you don't understand WP:OR" - That's a pretty bold statement. Let's see how it pans out...
"Almost if not every air route will be announced and available somewhere" - Ah, so here's where I've got to stop you because this is, I'm afraid, factually inaccurate. The majority of airline routes are sourced either to RoutesOnline, or to AeroRoutes, or to Airlineroutes, or to the airline website, or to literalflight tracking data. Not to announcements about the opening of routes in the media or even really any announcement at all. And whilst new routes are seldom announced in the media (because they are opened and closed all the time) still less is theclosing of a route likely to be announced in the media.
Instead what typically happens is this:
Someone goes to the website of airline X and sees that they are selling tickets from PLACE to OTHER PLACE.
They update the list of destination to include this, citing the website.
Someone checks the website of airline X some time later and sees they are not offering tickets from PLACE to OTHER PLACE.
They update the list to say the destination is now terminated.
This is just straightWP:OR, since no source ever said that the route was flown in the first place, nor does it not being listed any more mean that it is actually certain to be terminated.FOARP (talk)15:15, 8 October 2025 (UTC)[reply]
How does that process (which I agree is bad) actually prove that "no source ever said that the route was flown in the first place"?
That is shameless sophistry propped up by a not-a-policy, not-a-guideline essay. Whenwhen someone checks an airline's website and makes some guesses, that's OR, and if an article relies on it to make an assertion, then that article incorporates OR. If someone later finds a newspaper containing that assertion, and substitutes that newspaper into the article as the citation for that assertion, then the article no longer incorporates the OR. But the OR is and was OR.In any event, I do hope we can agree that under now circumstances can articles rely in any way onsomeone checks an airline's website and makes some guesses -- whether or not we can agree on what exactly to call that.EEng19:51, 9 October 2025 (UTC)[reply]
The actual policy says that OR = no reliable source in the entire world. To quote the policy:the reliable source must have been published and still exist—somewhere in the world, in any language, whether or not it is reachable online—even if no source is currently named in the article.
A plain reading of the words in the policy indicates that finding a newspaper containing that asserting and substituting it – though a desirable action that should be strongly encouraged – does not change the facts. That fact never was OR, because the newspaper source existed—even though that OR-disproving source wasn't previously cited in the article.WhatamIdoing (talk)23:49, 12 October 2025 (UTC)[reply]
No, OR=you came to the conclusionwithout sources yourself. Just because your conclusion matches sources later found doesn't make it not OR as you yourself didn't use those sources. (Note I use "you" in the sense of a general "you" I am not accusing anyone here of OR directly).Lavalizard101 (talk)09:59, 13 October 2025 (UTC)[reply]
@Lavalizard101,WP:BURDEN "is satisfied by providing aninline citation to a reliable source that directly supports the contribution". Note the absence of the word "independent". Note the presence of the word "an", as in "one", not "WP:FETCH me an endless supply of sources until you convince me that it's good enough".
Read the footnote in BURDEN: "Once an editor has provided any source they believe, in good faith, to be sufficient, then any editor who later removes the material must articulate specific problems that would justify its exclusion from Wikipedia (e.g., why the source is unreliable; the source does not support the claim;undue emphasis;unencyclopedic content; etc.). If necessary, all editors are then expected to help achieveconsensus, and any problems with the text or sourcing should be fixed before the material is added back."
@Lavalizard101, ONUS doesn't say anything about it not being on you to find independent sources. ONUS is about finding consensus, not about whether one editor gets to tell another one "No way, it'syour job to do all the boring work, because it's not onme to find independent sources."WhatamIdoing (talk)23:53, 12 October 2025 (UTC)[reply]
Establishing consensus for inclusion includes finding the citations that support the material for inclusion. These are just two different aspects of the same thing.
If you want to include something, you have to find the cites to support it. We have discussed, at great length, the problems with relying on airline websites, blogs, and press-release announcements of future plans that may not have happened or may be for flights that are already cancelled.FOARP (talk)07:07, 13 October 2025 (UTC)[reply]
Consensus doesn't always depend on citing sources. If it'sWP:CHALLENGED, then yes, you have to add sources, but consensus might depend entirely on other questions, like "Should this actually be in the lead?"WhatamIdoing (talk)04:56, 16 October 2025 (UTC)[reply]
Your essentially doing the "it's your job to clean up our mess" routine that has gotten people blocked in the past. I don't even edit airport articles, I came in as an uninvolved editor to provide an outside perspective.Lavalizard101 (talk)09:53, 13 October 2025 (UTC)[reply]
I don't edit airport articles either, but I'm hoping that you will learn to use the relevantWP:UPPERCASE. Here's a quick comparison:
WP:ONUS means you (not the other editor) have to start a discussion that results in consensus to include your content, or your content gets removed.
WP:BURDEN means you (not the other editor) have to citeone source, or your content might get removed. Note that it's limited: other editors can't tell you toWP:FETCH an endless string of sources. After you do your best, it's now everyone's job to figure out how to do the best thing by the article.
WP:CHALLENGE means I don't think you'll be able to find that one source, so I'm planning to remove your content.
WP:MINREF is the list of situations when anInline citation is actually required by policy. Note that it's less than "always".
I think it's worth mentioning that the 2025 RFC was explicitly about two individual pages (not pages in general) and was, put charitably, a fairly odd RFC question combining two unrelated pages. It did not make clear any specific consensus about these pages in general.
No, we definitely should not be carrying such lists without independent secondary sourcing demonstrating that it isWP:DUE to list this. This secondary sourcing should not be simply airline industry aggregators. And even in that case, the list should be restricted to major routes to prevent it flooding the page. Anything that does not meet these criteria should be removed.
There seems to be a large majority here against these lists. Count me in that majority: destination lists on both airport and airline pages violateWP:NOTGUIDE and very rarely have acceptable sourcing. All I'm seeing in favour of keeping them areWP:USEFUL andWP:EFFORT arguments. What's the next step? An RFC here on VPP?Rosbif73 (talk)12:45, 7 October 2025 (UTC)[reply]
I’ve no idea what the process looks like - my inexperienced thought would be that surely this discussion, if consensus has been reached, that would be sufficient? But more experienced editors would probably be best to chime in here, like @EEng or @AndyTheGrumpDanners430tweaks made12:56, 7 October 2025 (UTC)[reply]
Another person who voted at the WP:NOT RFC making the same arguments that were in the minority there. The next step would be a review of the close of that discussion, not starting a new one. — Reywas92Talk13:57, 7 October 2025 (UTC)[reply]
Exactly. This looks a lot likeWP:FORUMSHOPPING and failure toWP:DROPTHESTICK. The RFC was well-attended (and not by me, incidentally, but I certainly support its findings) and came to a definitive conclusion that airport destination lists do not violateWP:NOT. There should not be another RFC on the same question so soon after the previous one. — Amakuru (talk)14:56, 7 October 2025 (UTC)[reply]
Except that we're dealing with the sourcing issue for the majority of these lists, where the last rfc found they were okay as long as the sourcing was based on third party sources, which is not the case.Masem (t)16:50, 7 October 2025 (UTC)[reply]
I think the destination tables (and maps) should go from the airport articles. Other than all the arguments above about what Wikipedia is about, it's missing one major item. Flight destinations are not properties of airports, they're properties of airlines. The articles are about airports and airports don't operate flights. Airline articles can have destination lists, but they actually are not relevant to the airports. Airports are locations where airlines operate to perform flights, they're not the flight operators. London Gatwick doesn't fly to JFK. Narita airport doesn't operate any flights to Sydney. The airlines do. Once the aircraft, operated by the airline, leaves the airports terminal airspace it has nothing to do with the airport. Airports and webpages of them may provide info on these flights, but that is on behalf of the airlines that are paying to avail themselves of the airport services and facilities, not the airport itself.Canterbury Tailtalk15:33, 7 October 2025 (UTC)[reply]
That sounds reasonable to me. Take the example of a shopping mall. It's fine to list the stores that make up the mall. However what we're doing with airport articles is listing the products those individual stores sell, which is not what we're supposed to be doing.Canterbury Tailtalk15:45, 7 October 2025 (UTC)[reply]
Even for a shopping mall a full directory of store would be inappropriate because those can change quickly (look how fast Spirit Halloween can be set up in available space). Secondary sources would most likely identify the archor stores, and any unique stores but the full listing fails the point of how we are writing for the long term/ ten year view.Masem (t)16:48, 7 October 2025 (UTC)[reply]
That's incredibly reductive and destructive of what airports are for and how informative Wikipedia can be. I don't go to the airport to fly on British Airways, I go to get to London. I look at the big board of where flights are coming from and going to, which provides a lot of context about how the airport works as a transportation hub. Listing the destinations shows which airlines have a major presence at the airport compared to the ones that only go to from spoke to hub. Only naming the airlines doesn't show the reader to what extent the airport serves different markets for long- or short-distance and holiday or business passengers. Destinations give context for how the airport may serve locals, visitors, or passengers in transit. Listing the destination airports does thatwithout the need for any synthesis or original research by just providing the basic, straighforwardly verifiable information to the reader. An airport is not merely a big building. Many airports do in fact work closely with the airlines in determining routes, since they influence the airport's growth, services for the community, how other airlines may choose to fly there, and how facilities like immigration checkpoints are used. In Indiana the state government even provided incentives to get flights from Indianapolis to Dublin and previously Paris[34][35][36][37], so don't pretend these are purely airlines making independent decisions that have nothing to do with particular airports. This might be its only flight to Europe, but it's much more neutral to just list all destinations rather than pick and choose to name only those that are "major" and have articles like these. Saying destinations from an airport are irrelevant to the airport is absurd when they're actually integral to the article. — Reywas92Talk16:51, 7 October 2025 (UTC)[reply]
You are trying to explain a use scenario for these lists that flat out violates NOTGUIDE, and certainly doesn't make sense to use compared to the airlines site or any flight search site directly. We are not here to help one plan their travel, we are trying to describe an airport in an educational context. Identifying major operators using that airport, and summarizing destinations reported by secondary sources does that, but not trying to document every route in and out of the airport.Masem (t)16:57, 7 October 2025 (UTC)[reply]
I said nothing about planning travel, and one would be an idiot to plan travel using these basic lists, as there are no schedules, prices, or other details that you would find when searching Expedia or an actual travel resource. I think it is quite educational to see how an airport is part of a global network even when I have no intention to go there. Still, information being "used" in a certain way does not make it a travel guide or forbid its inclusion. We have the advantage over the airline's site or flight search sites of being concise and compact, easy to read, ad-free, comprehensive, and with wikilinks. NOTGUIDE refers to content likethis I just removed yesterday, orthis andthis with a how-to tone. I use Wikivoyage a lot too and know the difference in what belongs here or there, both in content and style, though I certainly do use Wikipedia to plan travel too! I just consultedList of National Historic Landmarks in North Carolina andAsheville, North Carolina#Arts and culture to see if I should visit any of these places on my upcoming trip there, but that doesn't make them forbidden travel guides either. — Reywas92Talk18:06, 7 October 2025 (UTC)[reply]
Landmarks do not change significantly, once a landmark it remains such barring destruction of it. So documenting landmarks of a locale is fine considering the permanence of that info, as long as we are using appropriate independent sourcing as to what makes a landmark. That's a far cry from airport connectivity, which can change at any time. Sure, Delta isn't going to bail out of Atlanta any time soon, and that certainly can be documnlent as a broad description, but whether you can fly from Atlanta to smaller regional east coast airports will vary greatly and doesn't make any sense to try to track at that level, as it doesn't help understand delta or ATL.Masem (t)19:17, 7 October 2025 (UTC)[reply]
And that's the beauty of Wikipedia! If something changes, we can update it! There are many, many editors who contribute to these articles, and I've never seen evidence that they are regularly incorrect or out of date. — Reywas92Talk14:42, 8 October 2025 (UTC)[reply]
Updates that likely will remain relevant in the long term make sense. Making updates that could vanish at any time does not make sense, that's unnessary effort and busywork.Masem (t)15:11, 8 October 2025 (UTC)[reply]
I was specifically talking about airport destination tables, not airline lists. That page does still accurately say the airline merged and their routes were terminated, so there's still nothing incorrect about it at all, even if that's perhaps not the best format. — Reywas92Talk03:06, 13 October 2025 (UTC)[reply]
The same could be said about any train station, since whether passenger rail is available at all, and if so, which destinations it leads to, is a property of the railway service, not a property of the station itself. Train service could be started, expanded, reduced, changed, or cancelled at any time. New rail companies could be created, and old rail companies could cease operations.
And yet we don't say "Making updates that could vanish at any time does not make sense". Instead, we say "you're a volunteer, and if that's how you want to spend your time, then it's no skin off my back".WhatamIdoing (talk)19:30, 9 October 2025 (UTC)[reply]
Our articles about railways cover railway lines, not railway schedules. Railway lines are relatively stable and not going to disappear tomorrow.FOARP (talk)22:01, 9 October 2025 (UTC)[reply]
Our articles about trainstations (a physical node in a transportation network; equivalent of an airport) include every railway operator (equivalent of an airline) at that station plus every destination they have a direct connection to (equivalent of an airport destination).
And how frequently do these services change? In the UK for example, it’s a maximum of twice a year because that’s when the timetables change. As for adjacent stations… that only ever changes if new lines are opened or lines are closed, which is less than once per year. In other words, it can be generally assumed that such information is highly stable. Airport destinations however are highly UNstable as airlines can add, remove or change their schedules at any time during the year, and frequently do.Danners430tweaks made22:45, 9 October 2025 (UTC)[reply]
Does it matter? I don't recall any policy or guideline that says information that changes frequently is unsuitable for an encyclopedia. For many small airports, changes to destinations are rare. I just checked one: It's had flights to the same two destinations for over a decade. By comparison, your twice-a-year railway changes are really quite unstable.WhatamIdoing (talk)23:57, 12 October 2025 (UTC)[reply]
"I don't recall any policy or guideline that says information that changes frequently is unsuitable for an encyclopedia".
"Wikipedia considers theenduring notability of persons and events. While news coverage can be useful source material for encyclopedic topics,most newsworthy events do not qualify for inclusion and Wikipedia is not written in news style. For example,routine news coverage ofannouncements, events, sports, or celebrities, while sometimes useful, is not by itself a sufficient basis for inclusion of the subject of that coverage (see WP:ROUTINE for more on this with regard to routine events).
Our airport-destination lists, and even more so our airline-destination lists, are entirely based (in as much as they are reliably sourced at all) on exactly this kind of routine coverage.FOARP (talk)07:19, 13 October 2025 (UTC)[reply]
Yes, and the airport is an enduring subject, so including information about the current state of the subject is entirely compatible with NOTNEWS. Compare, e.g., theTemplate:Infobox company parameter|num_employees: We expect to change that frequently. Nobody says that having up-to-date information is a violation of NOTNEWS just because it changes regularly. In fact, the first sentence of NOTNEWS, whch you didn't quote, says:In principle, all Wikipedia articles should contain up-to-date information.
And I think that when you talk about airport-destination lists requiring frequent updates, it'd be good to remember that this claim is only true at the larger airports. Smaller airports often go many years without a single change to the airport-destination list.WhatamIdoing (talk)05:11, 16 October 2025 (UTC)[reply]
These tables include airline routes, not airline schedules...99% of airline routes are also pretty stable and won't disappear tomorrow either. — Reywas92Talk03:07, 13 October 2025 (UTC)[reply]
"99% of airline routes are also pretty stable" - We've got entire articles given over to the routes of airlines that launched and flopped within a few years. See, e.g.,List of Play destinations. How on earth can that be described as "stable". The lack of stability is emphasised by 1) the requirement to give a specific date for the table (because if a specific date isn't given it's not even clear when it's supposed to be valid for) and 2) the endless updating that the tables require.FOARP (talk)07:23, 13 October 2025 (UTC)[reply]
Although personally I don't think maintaining exhaustive lists of airport destinations is a good idea, due to various reasons that have already been discussed, I don't agree with the reasoning about destinations not being decided by the airports. The network connectivity is a relevant property of a given node in the network, apart from how administration of the network and node are divided.isaacl (talk)17:00, 7 October 2025 (UTC)[reply]
Except that at a whim an airline can say "we're not flying to this destination anymore", wiping out that connection in the graph. It's a dynamic mesh, and for that reason we shouldn't be trying to document it's fine details that are subject to daily changes. Broad strokes are fine, and like if LA Guardia lost all routes to London I'd expect that to be covered to secondary sources to discuss major changes at the airportMasem (t)17:12, 7 October 2025 (UTC)[reply]
Yes, as I stated I don't think maintaining exhaustive lists of airport destinations is a good idea, which is in accordance with your statement.isaacl (talk)21:35, 7 October 2025 (UTC)[reply]
Do you think you would understand an airport if you don't know how many places you could get to from it, and something about the qualities of those places? Do you really think there's no educational difference between "Smallville Airport, connecting only to Nearby City Airport" and "Midtown Airport, from which it's possible to go directly to four different airports" and "Major Hub Airport, connecting to most of the US"? Or even between "Smallville Airport, sole path to Seasonal Hop"? I'd think these would be important things to know, and a destination list conveys that information.WhatamIdoing (talk)18:24, 7 October 2025 (UTC)[reply]
I don't think a single sentence conveys that. Maybe it could, at a very small airport (and I believe I'm on record in past discussions as advocating for using prose when the list of destinations is relatively short). But If you were writing aboutHartsfield–Jackson Atlanta International Airport, I think it would take a substantial section to properly describe its relationship to the air network, and even then, you'd have editors saying "You've listed 43 countries. Just make that a bullet list instead of aWP:SEAOFBLUE – no, on second thought, add a little more information and make that a table."WhatamIdoing (talk)19:34, 9 October 2025 (UTC)[reply]
Personally, I don't work in this area, butas a reader of those pages I find the lists useful and informative, and I feel that they are appropriate for Wikipedia. On the occasions I've mentioned the past discussions about this to non-editors, they seemed to agree. Take that for what you will.
More to the point, though, in the last two years we have had three big inconclusive discussions on this (two RFCs, plus one lengthy close review rehashing the first RFC) and ... we are where we were two years ago. As far as I can tell the number of airport articles with these tables is about the same as it was in September 2023. I don't think a fourth big discussion is going to change anything, except a lot more yelling and drama - this discussion already feels a lot more acrimonious and unproductive than the earlier ones were, and those weren't exactly pleasant.Andrew Gray (talk)16:28, 7 October 2025 (UTC)[reply]
I’ve spent many painstaking hours over several weeks updating the Clark and Manila Airport cargo destination tables — bringing them up to date with accurate and verifiable cargo route information. I removed outdated routes and added new ones, ensuring that each entry, both old and new, was supported by a Flightradar24 reference with available flight playback as evidence of regular weekly operations. I followed theWP:AIRPORT-CONTENT as directed by a Wikipedia administrator.
The reference guidelines in the cargo section state the following:
Sources: Because cargo airline schedules are often less readily available than passenger schedules, a reliable source should be explicitly listed verifying the service of each cargo airline.
The best source is typically the airline's schedule listing a flight number of a cargo-only service to the airport in question. If an airline cargo timetable is available, it should be listed as a reference, with the reference including the direct URL of the timetable and the publication or access date.
If a timetable is not available and no other reliable source explicitly states that the airline operates a cargo flight to the airport, each destination should be justified by footnoting a flight number. URLs for cargo schedule/status on airport websites can be used. For areas of the world with air traffic control tracking coverage (North America, Europe, Australia, and any flight flying through related airspaces, such as most of the North Atlantic and North Pacific), a flight number and a static URL of such a flight number (e.g.CPA095 on FlightAware within <ref></ref> tags) should be included so anyone can easily verify if the service still exists. For these types of references, the inclusion of an access date is particularly important. As far as I was aware, I was working fully within Wikipedia’s guidelines, only to have all of my work deleted in one sweep byDanners430. I opened a discussion on his talk page requesting that the changes be reverted, but he declined, stating the following:
“I have to repeat though that WikiProject guidelines (which WP:AIRPORT-CONTENT is) don’t overrule Wikipedia policy, those being WP:RS and WP:V. My concern is that if this is the only reliable way to source these routes, then perhaps they shouldn’t be included at all.”
My point is that before removing such a large amount of content, it would have been fair to issue updated guidance or clarification — which was not done. I followed the existing guidelines in good faith and was effectively penalized because someone later personally decided that flight-tracking references were no longer permissible. When it comes to cargo flight schedules,flight-tracking websites provide the most accurate and up-to-date information on real-time cargo operations. They are far more reliable than old press releases, which quickly become outdated and misleading. Without a flight number, it’s impossible to verify whether a cargo route is still active. By simply reviewing the provided flight data and playback, anyone can confirm the operation of each route. Every cargo flight thatDanners430 removed was an active, scheduled service. I would appreciate it ifDanners430, in good faith, could revert the changes he made until updated guidelines are established. Flight-tracking references are used across many other airport cargo tables. If they’re not being universally removed, then deleting only a few is selective and inconsistent.
What definition of "OR" are you using, if "the reference including the direct URL" is "OR"? It can't be the one in the OR policy, because "the reference including the direct URL" is clearly not a case of no source in the entire world ever publishing that information.WhatamIdoing (talk)19:40, 9 October 2025 (UTC)[reply]
This is a preposterous standard for OR. OR is not"no source in the entire world ever publishing that information". OR is editors doing their own original research and using EN WP as an outlet to publish it, regardless of whether an independent, reliable source could ever have published it. The existence of, e.g., independent and reliable biographies of Winston Churchill, doesn't make using EN WP as an outlet to publish your own biography of Winston Churchill not OR.
And in this case it's very questionable whether there are an independent, reliable sources publishing the information that airline fans want EN WP to carry. Reliable, independent sources rarely (if ever) provide a complete listing of all the destinations of an airline at a specific date. Instead these listings are typically cobbled together by editors out of individual bits of coverage, often just from the airline website and blogs like Routesonline/aeroroutes, stretched out over a period of years.FOARP (talk)07:58, 13 October 2025 (UTC)[reply]
Well, preposterous or not, it's the standard that's actually in theWikipedia:No original research policy. May I invite you to read it? Here's the first two sentences and the footnote, for your convenience.
Wikipedia articles must not contain original research. OnWikipedia,original research means material—such as facts, allegations, and ideas—for which noreliable, published source exists.[1]
1. By "exist", the community means that the reliable source must have been published and still exist—somewhere in the world, in any language, whether or not it is reachable online—even if no source is currently named in the article. Articles that currently name zero references of any type may be fully compliant with this policy—so long as there is areasonable expectation that every bit of material is supported by a published, reliable source.
The burden of updating wikiproject guidance to be in line with global P&Gs is wholly on project members, not the wider community. Editors should not be editing mainspace based on principles that are not in accordance with P&Gs.JoelleJay (talk)01:44, 8 October 2025 (UTC)[reply]
This is a fundamental mis-understanding ofWP:NOTTRAVEL, which is supposed to allow us to remove things like restaurant entries or tourist destination lists, presented in travel guide format, from cities and tourist destinations such as hotels. Lists of airport destinations are encyclopedic - many airports discuss the first routes from the airline in prose, and the intent is reference, not to help someone actually select flights. Also, there have been four ANI requests as a result of these lists, but all four of them involve the petitioner - surely the easier thing would just be to topic-ban the petitioner from editing airports?SportingFlyerT·C21:11, 7 October 2025 (UTC)[reply]
WP:AIRPORT-CONTENT should have been updated or withdrawn before mass deletions of airport destination data were carried out. Many editors invested significant time maintaining that information, and the situation could have been managed with greater consideration and diplomacy.Dootfish (talk)21:59, 7 October 2025 (UTC)[reply]
WP:AIRPORT-CONTENT is actually irrelevant to all of these discussions. That is a Wikiproject page that has no say, control or authority over the content of any mainspace pages. It's just a suggestion that some likeminded editors have put together and carries zero weight. It even says at the very top "Remember that you're in no way obliged to follow all, or even any, of these guidelines to contribute an article." Wikiprojects don't have a say, they're just a means of editors in certain areas to collaborate and communicate, nothing more.Canterbury Tailtalk22:32, 7 October 2025 (UTC)[reply]
I've never had any problem with their reliability - many different users gnome-update these lists, and they really aren't difficult to source or verify at all.SportingFlyerT·C02:18, 8 October 2025 (UTC)[reply]
So, just to be clear here, the Wikiproject guide:
- tells you to go to a flight tracking website (raw data ripped straight from stuff input by the airlines at best).
- tells you to list flights numbers (how do you know CX95 is a regular flight? How do you know it’s a cargo flight? How do you know CX95 is always that route? I mean I used to fly CX250 fairly regularly and they don’t change much, but they can).
This was precisely my point when removing those sources - at best, they’reWP:SYNTH. Flight tracker websites show you a history of when that route has been operated… but it tells you nothing about the state of the route. For all we know the route could be temporary, one-off, or a charter… but editors are using these sources to unequivocally state they are scheduled routes.Danners430tweaks made06:17, 8 October 2025 (UTC)[reply]
If a timetable is not available and no other reliable source explicitly states that the airline operates a cargo flight to the airport, each destination should be justified by footnoting a flight number. URLs for cargo schedule/status on airport websites can be used. The project explicitly says to use flight tracking websites to source flight numbers that are not verifiable as representing continuing services.JoelleJay (talk)16:15, 10 October 2025 (UTC)[reply]
I'm concerned about the destinations, rather than the flight numbers. I can imagine that people who are interested in airlines find the flight numbers especially handy, and presumably that was their motivation for suggesting them, but I'm concerned about whether Cathay flies from Boston Logan to Hong Kong. No matter what anyone has (or hasn't) cited for the fact that this airline flies between these two destinations, the claim that this airline flies between those two designations is not, and can never be,WP:Original research, because proper reliable sources definitely exist for that claim. Those sources exist in the real world (←the main concern of the OR policy) even if nobody has actuallyWP:CITED them yet (←not a relevant factor when deciding whether to condemn the material as OR).WhatamIdoing (talk)00:02, 13 October 2025 (UTC)[reply]
The individual facts are supported and yes, would not fail OR, but it is the agglomeration of this information in a form that no other reliable source documents airports or airlines to this degree that is original research. It would be like having a list of the most number of balls pitched by pitchers in baseball; certainly for individual pitchers you can likely find those numbers in sports alamnacs, but the collection in that fashion would be a novel invention for WP's purposes.
Wedo know that independent, third-party sources do give broad overviews of routes and destinations, and that should be included, but going beyond that creates problems from the OR standpoint.Masem (t)00:07, 13 October 2025 (UTC)[reply]
And in case this isn't clear: Ifany reliable source in the whole world does this, even if it's not an independent reliable source, then it's not OR. Feel free to complain that it's "bad practice" or "subpar sourcing" or whatever else you want, but don't call it OR ifany reliable source (including any non-independent+self-published+primary reliable source) publishes lists like these.WhatamIdoing (talk)00:22, 13 October 2025 (UTC)[reply]
This is just totally wrong and entirely your own head-canon version of what EN WP's rules around OR actually are. See particularlyWP:STICKTOTHESOURCE -"Even with well-sourced material, if one uses it out of context, or to state or imply a conclusion not directly and explicitly supported by the source, one is engaging in original research". When editors list flights as"terminated" based simply on them no longer being listed on the airline website, they are doing exactly this.FOARP (talk)08:07, 13 October 2025 (UTC)[reply]
Finding some examples of flights currently cited only to flight trackers where appropriate sources do happen to exist somewhere is entirely irrelevant to the point of this thread, which is about the fact that using flight numbers from flight tracker websites as sole sources forroutes is clearly OR, and that the wikiproject explicitly endorses using those sources whenno other reliable source explicitly states.JoelleJay (talk)01:12, 13 October 2025 (UTC)[reply]
I thought the point of the thread was to promote the POV that "airport destination lists...are huge, unwieldy, very dynamic and largely unsourced or difficult to source" that "would be better replaced with text".
I doubt that I'm understanding your point. The airport (as nearly as I can tell) that's closest to theGeographic center of the United States isKearney Regional Airport. It has one destination, which is theDenver International Airport. This is currently cited to a document athttps://www.regulations.gov. But you're saying that if the contents of the ref tag instead said "UA 5057" or "UA 5074" (they appear to have two flights to Denver each day), then all the other reliable sources in the world would magically disappear?
Because having all the other reliable sources that contain this information disappear is the only way that there could be no reliable sources—anywhere "in the world, in any language, whether or not it is reachable online"—and no reliable sources anywhere in the world, even if that reliable source isn't "currently named in the article" is what we require to say that something is OR.
I don't think OR is a complicated concept, so I'm not understanding why you think this is OR. Here's the basics:
OR: Somebody cites an unreliable sourceand no other reliable source in the entire world has ever said anything about this.
Because the local newspaper wrote about United flying from Kearney to Denver, the claim that United flies from Kearney to Denvercannot be OR no matter what source is cited in the Wikipedia article. It can be all sorts of other kinds of wrong, but it cannot beOR (specifically).WhatamIdoing (talk)02:52, 13 October 2025 (UTC)[reply]
You're setting a standard for OR where it's only OR if there isn't any source that could be used. That's totally illogical. It's still OR when an editor does their own original research (for example, comparing versions of a company website and using it to say that services no longer listed are "terminated") and uses EN WP to publish it, even if there's a source buried somewhere that they could have used instead (which, BTW, typically isn't the case for most "terminated" services). The existence of someone else's research somewhere doesn't make OR by a Wikipedia editor not OR.
If you write your own biography of Winston Churchill and try to cite an article about Winston Churchill to it, that is still OR even if independent, reliable biographies of Winston Churchill exist.FOARP (talk)07:35, 13 October 2025 (UTC)[reply]
I agree that comparing versions of a company website and using it to say that services no longer listed are "terminated" is inappropriate. But if that comparison happens by chance (and I give it low odds) to align with what's published in a reliable source, then it's not actually OR. If someonecan cite it properly, it's not OR. It's justWP:Glossary#uncited.WhatamIdoing (talk)05:32, 16 October 2025 (UTC)[reply]
I am obviously talking about the topic of this specific thread, the wikiproject guidance endorsing performing OR, as should be evident by my and others' repeated quoting of that guidance. Your example is completely irrelevant.JoelleJay (talk)14:44, 16 October 2025 (UTC)[reply]
"many airports discuss the first routes from the airline in prose" is acceptable Saying that "Heathrow Airport opened in 1946 with the first flight to someplace and the first non-British aircraft arrived from foreign parts. (some really good source)" in prose is how it should be butHeathrow Airport#Airlines and destinations isn't a good thing. But at least they didn't try and add a map.CambridgeBayWeather (#1 deranged),Uqaqtuq (talk),Huliva00:16, 8 October 2025 (UTC)[reply]
The fact they're "isn't a good thing" is incredibly subjective. I probably use these sections more than any other on Wikipedia as reference information.SportingFlyerT·C02:19, 8 October 2025 (UTC)[reply]
There isn't a single place on WP where it's considered kosher to source massive lists of services almost entirely to the companies that provide those services, and blogs.FOARP (talk)14:27, 8 October 2025 (UTC)[reply]
It may well be but that's the same impression I'm getting from editors who wish to retain the lists. I see little discussion as to how policy requires or permits the lists. Most arguments for retention seem to come down to liking them.CambridgeBayWeather (#1 deranged),Uqaqtuq (talk),Huliva15:05, 8 October 2025 (UTC)[reply]
The sections are encyclopedic reference material, and we've just required verifiability in the past, with discussion about what sort of sourcing is required changing over time as the evergreen nature of these discussions evolve.SportingFlyerT·C17:15, 8 October 2025 (UTC)[reply]
How doesthis source (literally Jim Liu's personal blog) "verify" that American Airlines is operating a"seasonal" service from Heathrow to Phoenix-Sky Harbour? But that's what the Heathrow destinations list says it says.
All it says is that it's cancelled for this winter (having previously not been cancelled for this winter), not that this is going to be recurrent thing. It's also far from sure that it's be back in March.
Similarly how doesthis source (again, Jim Liu'spersonal blog) verify that the London Heathrow - Bodrum service is"seasonal"? Actually how does it verify that the service is presently even operating? And if the list is not supposed to be accurate for the present date, then, considering these schedules change month to month, what date is it supposed to be accurate for? The sources range in date as far back as 2019 and as far forward as for next year.FOARP (talk)21:16, 8 October 2025 (UTC)[reply]
Remove this information and prohibit further addition – This information is poorly sourced and difficult to verify. The more significant issue, in my view, is that its significance from an encyclopaedic perspective is never addressed. There may be instances where the addition or elimination of certain aeronautical routes is encyclopaedic, but these will appear in reliable, secondary sources. Wikipedia is not a guide; it is also not anindiscriminate mass of information. If a reader seeks information on the service provided by any aeronautical firm, he would be better served by inquiring with the company directly. Wikipedia cannot offer up-to-date, accurate information, and it ought not attempt to do so.Yours, &c.RGloucester —☎01:55, 8 October 2025 (UTC)[reply]
Suggestion: Just having a bit of a think about what has been discussed so far, and the various options discussed. I'm well aware doing nothing is still on the table, but if something is done what about this - Remove the tables in their current form, and replace with an "Airlines" section for airlines which currently serve the airport. This should be easily verifiable through a combination of primary and secondary sources. Then, add a sub-heading for notable routes - ie routes which have received significant media coverage, or which are notable by being in the news for other reasons (such as celebrities regularly using it, or incidents etc.). This wouldn't be an exhaustive list, but rather a bulleted list where each route has a short piece of prose establishing notability - for example, "Regularly used by members of parliament to travel to X"; "involved in Air Example Flight 123, which crashed en route to Incident Airport"; "Cancelled and reinstated multiple times in 2024 due to conflict in Antarctica" - obviously each with relevant third party sourcing. If the notability of a route is questioned,WP:BRD could apply, and this could be easily mentioned in any updated Airport guidelines or in an invisible comment. Thoughts?Danners430tweaks made07:53, 8 October 2025 (UTC)[reply]
Re"I'm well aware doing nothing is still on the table", given that this was already formally discussed earlier in the year, with a consensus that the airline lists do not violate policy, "doing nothing" is the only outcome that an informal discussion such as this one can hope to achieve. We're here to discuss it, not to make actual changes. If you want this to be a concrete proposal if some sort to Deprecate the lists, then a fresh RFC would be required, with a neutral question and clearly setting out what change is proopsled. Until that is done, the RFC stands, and this thread can't overrule it. Cheers — Amakuru (talk)12:16, 8 October 2025 (UTC)[reply]
I think you should be topic banned. All of the ANIs you mentioned involved your conduct, and instead of getting into another evergreen fight about this, it would remedy the disruption the easiest.SportingFlyerT·C12:26, 8 October 2025 (UTC)[reply]
Then instead of throwing aspertions about, open an ANI (The appropriate venue for behavioural concerns) and make that suggestion. Otherwise you're simply being, in my humble opinion,uncivil and don't like the fact that action is being taken to improve the verifiability of a currently problematic area. I await the thread with popcorn in hand. I will not be further discussing my conduct, which if you look at those four ANIs was never agreed by consensus to be problematic, in this or any other non-ANI thread, as they are not the appropriate venues.Danners430tweaks made12:37, 8 October 2025 (UTC)[reply]
Furthermore, this suggestion is terrible, as you are suggesting that routes need to be notable as opposed to verifiable, which is not a standard we use for reference data anywhere else on the website.SportingFlyerT·C12:27, 8 October 2025 (UTC)[reply]
That's fine - I have no objection to your voicing such an opinion, as it's through discussions like this that consensus is formed. We don't all have to agree with one another (if we did the world would be a very boring place). However, going by the number of other editors on this thread that appear to agree thatsomething needs to be done, I don't think we can really dismiss the idea outright.Danners430tweaks made12:39, 8 October 2025 (UTC)[reply]
"you are suggesting that routes need to be notable as opposed to verifiable, which is not a standard we use for reference data anywhere else on the website" - Requiring that list-items be notable rather than just verifiable is avery common solution to long lists, widely used. See, e.g.,WP:LISTCRITERIA. It's literally the number-one method listed atWP:CSC.
Meanwhile the method currently used (listing everything that is regarded as verifiable) is number 3 atWP:CSC, and the way it is presently done using blogs and company-websites goes explicitly against the requirement that"The inclusion of items must be supported by reliable sources". Doing it based on flight-tracker websites is straightWP:OR of the most blatant kind.FOARP (talk)14:25, 8 October 2025 (UTC)[reply]
WP:LISTCRITERIA only applies to stand-alone lists. The page it sits on is literally titled that. Lists within articles don't seem to ever have been held to such a high standard and I think if they were to be, we'd end up having to throw out vast reams of information from the project much of which, like the airport destination list, has a fairly clear encyclopedic purpose in understanding the topic. One explanation for this may be that no encyclopedia before us has ever gone into the level of detail that ours do, so many of the lists we have in articles, which are quite proper when considering the topic as a whole, don't exist in their entirety anywhere else. This includes discographies and filmographies on actor/singer bios, lists of appearances by sports people etc. Sourcing that each entry exists is necessary, but sourcing the list as a whole apparently not. — Amakuru (talk)15:36, 8 October 2025 (UTC)[reply]
If we are collecting information on a form not previously used in any reliable sources, we shouldn't be doing that as a matter of SYNTH. And while standalone list inclusion can be subject to notability, all lists, standalone or not are subject to NPT#IINFO.Masem (t)15:41, 8 October 2025 (UTC)[reply]
Category:Lists of airline destinations still holds something like 156 stand-alone list articles. We managed to get that down from 400+ at one point, but as far as I am concerned that's still 156 too many.FOARP (talk)16:14, 8 October 2025 (UTC)[reply]
You realize your opinion of wishing to removing perfectly verifiable reference material significantly lessens the usability of this site for others, yes?SportingFlyerT·C17:08, 8 October 2025 (UTC)[reply]
"perfectly verifiable reference material" =/= stuff ripped from blogs, airline websites, flight trackers, and pure conjecture about what flights are and are not "terminated", "seasonal" and so-forth.FOARP (talk)20:57, 8 October 2025 (UTC)[reply]
Masem, I believe the complaint is that we're collecting information in a form thatis used in other websites. What some editors want is proof that this form is used in certain/special kinds of sources – excluding all primary sources, excluding all non-independent sources, excluding all sources that automatically import their information directly from airlines or public/government sources, etc. Perhaps an appendix in a scholarly paper or a book doing exactly the same thing would be grudgingly accepted, but nothing that's easy for editors to find on the internet.WhatamIdoing (talk)20:05, 9 October 2025 (UTC)[reply]
The form here I'm talking about is an exhaustive list of all destinations an airport or airline serves, which outside of databases is not something covered by RSes. Those sources will broadly cover major routes, and the inclusion of major new routes is generally available from RSes too. But when the exhaustive list is built with heavy reliance on databases, first party sources, and blogs, that begs if the full collection of that information is encyclopedic.Masem (t)21:05, 9 October 2025 (UTC)[reply]
We're making a list of all destinations an airport serves ...and you don't think that the airport's own website (a reliable though non-independent) has that list?
It even verifies claims that certain destinations are seasonal.
I'm all in favor of using better sources, but I really don't think we can claim thatno reliable source provides a complete list of which airlines serve which destinations.WhatamIdoing (talk)00:08, 13 October 2025 (UTC)[reply]
The archived page tells you that"Some nonstop routes may be offered seasonally, so be sure to check with individual airlines when booking your travel.", which is to say that some of the services listed may be seasonal but not listed as such and it is the passengers job to check which - this is not a total listing and disclaims being accurate.
If this page exists then why on earth is our Des Moines airport article cited to references dating back to 2011?
When you click on a destination to expand the details, it provides seasonal status. For example, the first in the list is Austin, Texas, about which it says:
Explore Austin, Texas, and experience outstanding food, live music and culture. Allegiant Air offers direct flights from Des Moines to Austin. View your flight options! *This is a seasonal route.
When you have a reliable source saying"This is a seasonal route", it cannot be a violation of the OR policy for a Wikipedia editor to write that this is a seasonal route.
While WP:V is a requirement to include information, it is not a guarentee that that info is required to be improved as all other content policies come into place, here been multiple facets of NOT. There's clear agreement above that routes that are not sourced to independent third party RSes should not be included to avoid these lists from becoming a travel guide or to avoid indiscriminate infoMasem (t)15:16, 8 October 2025 (UTC)[reply]
This isn't any sort of information which would appear in a travel guide! That's one of the easiest parts of NOT to refute here. This information would be found in specialty airline publications. The Aircraft Year Book of 1930 for instance published route information as reference along with aviation business and engine design, among other things. Further, this isclearly discriminate information.SportingFlyerT·C17:13, 8 October 2025 (UTC)[reply]
The intent of NOT is not explicitly cover all poosible things we are not, so while may argue a list of airport destinations does fall into the specific hole that NOTGUIDE says in text, it's definitely a problem in the spirit of what that section is about. And it is indiscriminate info because there is no long term value to a list of destinations that can change on a whim.Masem (t)17:22, 8 October 2025 (UTC)[reply]
No, the intent of NOT is to make sure that we remain an encyclopedia, not something else. Also, there is nothing indiscriminate about maintaining lists which are up to date - there are many places where we do this on the site, such as sports squads.SportingFlyerT·C18:26, 8 October 2025 (UTC)[reply]
The members of a sports team during a given season have the permanence of information already documented in RSes, but here we have separate pages for each team by Season to do that, we don't keep a current roster on the main page of the NY Yankees, for example. Changes in the roster are routinely documented in independent sources. So thats just not a good comparison.Masem (t)18:36, 8 October 2025 (UTC)[reply]
But to add, we know you can find the roster summarized in multiple RSes, there us zero synthesis used here. We are still doing a ton of synthesis in creating airport destination lists, which no source fully documents in whole.Masem (t)19:51, 8 October 2025 (UTC)[reply]
To be even more blunt, we are not sourcing our roster for the New York Yankees to some random ball fan's blog, still less are we saying that players are "terminated" because we didn't see them at the last game, or "seasonal" because they won't be back playing for the next few months.FOARP (talk)21:22, 8 October 2025 (UTC)[reply]
You're wilfully mis-representing the sourcing here. Routes starting and stopping frequently get covered in reliable media, similar to sports transactions.SportingFlyerT·C23:35, 8 October 2025 (UTC)[reply]
We're asking about thewhole of the airport destinations without having to combine sources or weigh on first-party sources. Yes, secondary RSes frequently talk about major route changes, but combining all those to try to justify listing out every route is not supported without engaging in SYNTHMasem (t)00:06, 9 October 2025 (UTC)[reply]
”Routes starting and stopping frequently get covered in reliable media,” - so you won’t mind only listing those services that actually get reported inreliable, independent media?, rather than Jim Liu’s blog and a blog run by a company that does events for airlines? And also not putting stuff in that the source doesn’t actually say (eg “terminated” just because it’s not listed any more, “seasonal” just because it’s cancelled for the next few months)?FOARP (talk)06:07, 9 October 2025 (UTC)[reply]
I still don't see the problem with listing routes with primary sources if that's the only way to ensure the information is completely correct, but the vast majority of sources are going to be reliable and independent. Implementing that standard is just going to create more conflict. Plus, the major route announcements which have just happened from US carriers have been clearly reported.SportingFlyerT·C16:46, 9 October 2025 (UTC)[reply]
"the vast majority of sources are going to be reliable and independent" - The vast majority of sources cited right now are airline websites and Jim Liu's AeroRoutes blog.FOARP (talk)19:37, 9 October 2025 (UTC)[reply]
As a relatively new editor who has been updating airport destination tables for only a few months, I have to admit I’m quite confused about which sources are acceptable for use. I was initially advised to followWP:AIRPORT-CONTENT when editing — but now I’m being told that it’s no longer valid. Then I’m directed to follow various other Wikipedia policies, each saying something slightly different. It’s no surprise that new editors are confused when even experienced ones can’t seem to agree on the guidelines.
It would be far better to reviseWP:AIRPORT-CONTENT (or create a new, unified version) that clearly outlines what types of sources are permissible that align with Wiki's main guidelines. This should then be posted prominently at the top of every airport destinations section with a clearNOTICE. A simple, consistent explanation of what is and isn’t acceptable would make things much easier for editors at all experience levels. For experienced editors or administrators to delete large amounts of route data without prior notice is not a constructive approach and has understandably frustrated many editors and users. A better method would have been to place a notice at the top of the destinations section, requesting the removal of outdated sources, the addition of updated citations for each route, and clearer guidance for editors on what changes were required. Overall, the gung-ho approach was poorly received and generated significant backlash from editors across the Wikipedia community, especially when the vast majority of editors were making revisions in good faith.Dootfish (talk)22:14, 9 October 2025 (UTC)[reply]
So, a few things here:
1) I'm not an elected representative of the Wikipedia community or anything (hey, wait a minute,I am kind of) but the community extends way beyond the airline project and involves many more people than its members, and I feel fairly secure in saying that most of the community is not OK with building entire list-categories almost entirely out of self-published blog information, and we have never been unclear about that.That's one of our most basic rules and hasbeen for at least 22 years now.
2) I'm sorry if airline community members have made a big thing out ofWP:AIRPORT-CONTENT to you and you are now discovering that it is in fact not very important. I was also once a noob here and also found the rules quite perplexing at first, but as a cut-and-keep how-to on this Wikipedia has (in order of importance) policies, guidelines, explanatory documents, and essays, and along side these it has a manual of style.WP:AIRPORT-CONTENT is confusingly described as a "style guideline", which asthis explains are essentially essays - that is to say, they are the lowest level of guidance that Wikipedia has and can be ignored. They do not in any way, shape, or form trump established guidelines, still less policy.
3) Another thing we do here on EN WP is discuss things. Like, a lot. So this is something we've discussed many, many times and come up with some conclusions about. As far as I am aware the Airline Project members have usually been made aware of those discussions by a notification on their talk page, but of course it is quite likely and understandable that new project members haven't seen those notifications.FOARP (talk)12:43, 10 October 2025 (UTC)[reply]
Comment on sources - Just a comment also on some of the sources being used, I'm not sure that even the reliable ones are being used properly. They're sources of an announcement of a route, and perhaps evidence of the ability to book a route, but this isn't the same as the route actually flying. Plenty of route are announced but never end up flying due to poor demand. I don't think we're covering for that and there is an assumption that because a route ends up on a database somewhere, there's an actual plane flying actual paying passengers on that route which the sources don't prove.Canterbury Tailtalk21:47, 9 October 2025 (UTC)[reply]
It gets worse. An announcement of aplan to fly the route is used as evidence that the routeis being flown, but then when it is found that the routeisn't being flown this is used as evidence that the routewas flown but is now "terminated". 100% this is OR.FOARP (talk)07:26, 13 October 2025 (UTC)[reply]
Next steps - The discussion has quietened down a fair bit over the last few days, so I think it's worth asking the question what the next steps should be. Certainly to me it would appear there's a fairly large voice speaking against the inclusion of these lists, so I don't think letting it lie is really the best option. What do we think?Danners430tweaks made12:22, 12 October 2025 (UTC)[reply]
Lists of airline/airport services are lists of goods and services offered by a business that change regularly (e.g., monthly), and should be correct for a specific date, with sourcing for that date. Where the list is a stand-alone article, the items listed should be notable underWP:LISTN/WP:NCORP as a group for that date. Any lists that can't fulfill this requirement should be deleted.FOARP (talk)22:10, 12 October 2025 (UTC)[reply]
Question. I've read through this as it's been ongoing and I skimmed through it again overnight. One thing stands out. The proponents of keeping the lists don't seem to be addressing the hundreds of smaller airports. They only seem to be talking about larger / busier airports. Smaller airports that have scheduled flights may not have websites and the start / stopping of a route isn't announced in a press release or a newspaper. The only way to find these is to use the airline schedule. What steps will be taken to ensure that these airports will have regular updates or even a source at all?CambridgeBayWeather (#1 deranged),Uqaqtuq (talk),Huliva21:11, 13 October 2025 (UTC)[reply]
Just as an example of what happens with smaller airports, here's a diff from today[38] removing a route for which we had an announcement of a new route for summer 2025 cited to a reliable source, for which the editor now claims the airline "removed nonstop [...] did not launch in 2025 and will not launch in 2026". The edit summary includes a link to the airline's timetables page. Searching on that timetables page for the route in question returns results, but with no indication of termination. Admittedly, the durations given for the next few days are slightly longer than expected for what ought to be a short hop and seem to suggest that this route now involves a connection somewhere, but this is not explicitly specified in the cited source. The editor may be right, the direct routing may have ended, but it's totally unverifiable and typical of the problems that affect all of these lists.Rosbif73 (talk)15:07, 15 October 2025 (UTC)[reply]
@CambridgeBayWeather, I think smaller airports are the easiest to find information about starting/stopping/changing routes. I've posted several in this discussion, and I've not yet failed to find a local newspaper article about this when I've looked for one. (Hint for anyone who wants to try: find the local newspaper's website, and search it directly.)
My feeling from this thread is that it's the opponents who never address the hundreds of smaller airports. It's all "too many changes, destinations change practically every single day!" – and the sound of crickets echoing in the silence when I give an example of a small airport whose sole or very short list of destinations hasn't changed for over a decade.WhatamIdoing (talk)05:43, 16 October 2025 (UTC)[reply]
Have a look athttps://nunatsiaq.com/ andhttps://www.nnsl.com/, our two newspaper organisations. You can't recreate flights for Nunavut using those. The only source is the airlines themselves. It's worse for cargo flights. This weekBuffalo Airways did their general freight run using a C46 and last week the same run using a B732 both with different flight numbers.Summit Air comes her weekly using an AT72 with freight for theNorth West Company, but not always the same plane, so different flight numbers, and sometimes it's not a freight run but just a fuel stop. There's no source for the Summit as it's a contract and they don't do general freight. It's difficult to source the smaller airports as they don't always have websites.CambridgeBayWeather (#1 deranged),Uqaqtuq (talk),Huliva15:27, 16 October 2025 (UTC)[reply]
No! I detest this modern phenomenon of legislating article content from the Village Pump: it should be figured out at the articles themselves. If some airports are too small or too large to have a reasonable list of their destinations, then fine, but there is virtually no situation where it makes sense to dictate what articles can or can't have in them in a discussion here. There is no way that a discussion at the Village Pump about 8,000 articles at the same time is going to be smarter than a discussion that takes place at any of those articles individually.jp×g🗯️05:14, 15 October 2025 (UTC)[reply]
Right, but there is precisely and absolutelyzero chance of this being discussed at 8000 individual articles at the same time. By all means if an RfC is opened we can request a bot place a notice on the talk page of every airport article, but we're not having 8000 individual discussions. I'm sorry if the "modern phenomenon" of centralising discussions about multiple articles doesn't work for yourself.Danners430tweaks made09:45, 15 October 2025 (UTC)[reply]
100% agree. I think a lot of the problem people have with VPP discussions is:
People in a project become highly invested in things being a certain way. Other project members disengage/drift away or are overruled.
Other people disagree with this, but it's impossible to implement any change in a forum where a handful of the same people showing up each time is sufficient to stymie change, so they make an appeal to a VPP RFC.
The VPP RFC comes back with a resounding response of "LOL, wut?" from the wider community when presented with what the people in the project decided.
We saw this particularly in the list-of-all-Olympians case. Members ofWP:OLYMPICS might not be able to come out straight and say "actually it would be a bad idea to have a list of 160,000+ contextless names, we understand that you've put a lot of work in to this, but this is actually exactly what we've been saying for decades thatWikipedia should not be", but VPP contributors can come out straight and say that in aWP:SNOW outcome.FOARP (talk)10:50, 15 October 2025 (UTC)[reply]
I don't think it'll be discussed on 8,000 articles because if the opponents were to show up with their standard complaint of "It's too big! It's too many changes! My watchlist is flooded by you airport fanboys!" at most articles, they'll just get laughed at, because the number of destinations will be fewer than five and the number of destination changes in an entire decade could be counted on your fingers.
I think there's a good case to be made for saying that thevery biggest airports don't need to contain comprehensive lists, just likeUniversity of Oxford#Notable alumni needs to say "Notable alumni include three Fields Medallists, two British kings and at least fifteen monarchs of eleven other sovereign states (including five reigning monarchs), twenty-eight British prime ministers, and thirty-five presidents and prime ministers of nineteen other countries" instead of naming them each one by one. The articles about thevery biggest airports might do well to provide a summary, like "Destinations include every country in Europe and North America, plus 17 countries in Asia and 12 in South America" instead of a comprehensive list.
But just likemost schools don't have such an abundance of high-profile alumni,most airports are quite a bit smaller than the very biggest ones, and a list of destinations is neither a maintenance nightmare nor unencyclopedic.
I mean, if you're looking atKearney Regional Airport#Airline and destinations, do you really think it's necessary to exclude the name of its sole destination, for fear of cluttering up the article with a table containing just three (3) words? Is it a terrible maintenance burden to have that in the article, without needing a single edit for years at a stretch? Do you really think it would be better to write a sentence that says something like "Destinations include the nearest regional hub, by the main airline at that hub", just to avoid saying "United" and "Denver"?
I'm not convinced that this is a one-size-fits-all situation. While 8,000 separate discussions might not be needed, maybe a little less "my advice forHeathrow Airport should apply to tiny rural airports, too" would be helpful.WhatamIdoing (talk)05:59, 16 October 2025 (UTC)[reply]
Keep in mind its not able getting rid of the destination lists, but pruning these lists to what can be sourced to independent, third-party sources. Most small regional airports are going to have this type of sourcing (most likely more local than national in coverage) that explain what major hubs you can easily get to, and that's great, we want that. But at the same time, mention of every regional airport that a major hub flies too would likely be excessive, and instead, this would be better served to explain the major airlines that use that airport (and likely listing the other major hubs that those airlines use), and the broad area that their flights serve, like LAX serving several trans-pacific flights to Hawaii and many eastern Asian destinations.
The goal is to think about how one would describe how an airport functioned far in the future, potentially after the airport long closed. If Atlanta's airport eventually shut down one day, it would still have been known as a major Delta hub, for example, that aspect doesn't change. Or for a regional airport, even something like Kearney, that it existed to primarily connect to only one major airport, would still be significant.Masem (t)12:47, 16 October 2025 (UTC)[reply]
The following discussion is an archived record of arequest for comment.Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
No: If necessary, and if the list is very short, it may be included in the prose. For example,The [...] airport only services weekly flights to [Location 1] and [Location 2] Anything more is overkill. Most large airports service too many airports for destination lists to even be considered for inclusion.Kingsacrificer (talk)18:38, 19 October 2025 (UTC)[reply]
Invalid RFC First, this is not a policy question, it's about content the proposer simply doesn't like. Second, just earlier this year,Wikipedia talk:What Wikipedia is not/Archive 60#RfC on WP:NOT and British Airways destinations foundclear consensus that these lists are not indiscriminate information and do not violate WP:NOT. No request was made to review this closure, nor is there any reason to restart it. There have been several discussions that have found these appropriate to include. Third, this is not an appropriate way to remove whole, important sections of thousands of articles.Reywas92Talk22:11, 19 October 2025 (UTC)[reply]
One-size-fits-all answers are wrong given that there aremany airports that have just one or two destinations (in which case, write a sentence instead of making a list), lots of airports that have a list-worthy number of destinations (e.g.,The Magical Number Seven, Plus or Minus Two), and some airports whose list of destinations is so large and complex that it's aWP:SIZE problem.WhatamIdoing (talk)05:05, 20 October 2025 (UTC)[reply]
I’m in no way against discussing some kind of size based solution - I didn’t add more “options” etc. to the RfC so that it would remain a neutral and brief question.Danners430tweaks made07:22, 20 October 2025 (UTC)[reply]
I tend to agree that this is just a bad RFC and should be shut down for lack of pre-RFC work. This RFC, either way, does not address the essential issues raised in the discussion it is following which focused in large part on sourcing andWP:DUE, and where there was no ground-swell of opinion against the whole idea of ever having a list of destinations ever.
I don't like this kind of list, but if someone can find a reliable, secondary source with a list of destinations that isWP:DUE to include in an article, then sure, why not?
Lack of pre-RfC work…? What on earth was the weeks-long discussion above then? To me there seems to be pretty clear consensus that something needs doing - not clear consensus on what needs to change, but most contributors agree that the current situation is untenable. However, RfC questions must be neutral, which is why I wrote what I did.Danners430tweaks made09:16, 20 October 2025 (UTC)[reply]
The problem is, that would breach RfC guidelines by being a non-neutral question - it would be loaded towards making a change when there are still some editors who disagree that anything should happen, such as Reywas92.Danners430tweaks made09:20, 20 October 2025 (UTC)[reply]
RFC question neutrality is a matter of not advocating that people vote any particular way in the question, not having an RFC question that 1) wasn't what was really discussed in the discussion (practically no-one was saying we should get rid ofall lists ofany kind) and 2) isn't going to produce a meaningful outcome from a policy POV, because there is absolutely 0% chance of this passing.
You can totally have an RFC question that says "Should airport destination lists be required to cite at least one secondary source" or "Do you agree or disagree that comparison of airline destinations taken from company websites is OR?" (not saying these are the specific questions I'd propose, just that these aren't non-neutralper se).
Reywas92 said in their !vote that this is an invalid RFC. Shutting it down would be in agreement with that !vote, as well as mine. Shut it down, and let's get a proper question that will give us a meaningful outcome either way.FOARP (talk)09:46, 20 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.
Given the withdrawal of the above RfC, here's a stab at an alternative formulation drawing on the points made in the discussion above:
Are details of all airlines offering service from an airport, and all destinations served by each airline, acceptable content (i.e. not covered byWP:NOT) in airport articles?
1: An exhaustive table of current destinations for all airlines is acceptable in all cases, even if some destinations are verifiable only in primary sources.
2: An exhaustive table of current destinations for all airlines is acceptable provided that all destinations are cited to reliable secondary sources.
3: Details of airlines and destinations should be summarised in prose; tables should be excluded.
4: All such details should be excluded.
All suggestions and improvements welcome. I have included option 1 only because it represents the status quo in many airport articles, though I'm not sure we should be explicitly encouraging anything that goes against usual sourcing requirements.Rosbif73 (talk)15:06, 20 October 2025 (UTC)[reply]
You’ve beaten me to it - but I’m in no way complaining! I would strongly be leaning towards option 3, with option 4 a second choice.
The problem with options 1 and 2 is that I simply cannot find a reliable way to source whether a route is *currently* operating - you’ll get press releases at the beginning and end of some routes, but there’s no reliable way to verify that the route is actively being flown. FR24 is one that’s occasionally used, but it’sWP:SYNTH in that there’s nothing to say explicitly that a route is operating, and airline booking pages are ditto synth as airlines may take flights off sale for a plethora of reasons - and most don’t necessarily mean the route has formally been cut.
Right now we have the situation where routes are added to tables, often using Aeroroutes (now deprecated) as the only source, then they stay until someone can find a press release or news article stating that the route has ended… and especially since Aeroroutes is now deprecated, the list of available sources has suddenly shrunk significantly to the point where removing such tables is really the only way forward, through either options 3 or 4 as listed here.Danners430tweaks made18:13, 20 October 2025 (UTC)[reply]
If you want to verify that United flies between Newark and Charlotte, you can absolutely check United's website to see its schedule. If the route were to be cut, you would not need an affirmative source saying so, since the article would simply not need to list the route at all – articles do not have to prove negatives. If a route has ended, that doesn't need Aeroroutes or any other source, it can just be removed. Flights are rarely flown with unpurchasable tickets, nor do they go untracked by FlightAware and other services. You are attacking a subset of perfectly usable sources to undermine the entire concept and shift the goalposts, yet no one has ever shown that there's actually an intrinsic issue to this information. Our editors are diligent and know how to verify things, and there is no evidence that these tables are full of false information because it supposedly can't be verified. What is truly the issue here, besides a general complaint that you don't like certain sources? It's certainly not that our articles are just wrong all the time. Occasional imperfections with timetables and certain websites – which can be used in combination – do not invalidate the entire concept, or how else does an entire industry operate?
I'd also note that the use of "exhaustive" is biased against the destination lists – why not "comprehensive", "informative", or better yet no adjective there? Moreover, option 2 is absurdly restrictive with "provided that all destinations": If an airport has several routes that are sourced in detail yet one is not particularly newsworthy (perhaps the oldest one without recent, easily findable sources!), why in the world would that invalidate the entire table? Or why would that one be removed, leaving an incomplete article?
A requirement for secondary sources, which "contains analysis, evaluation, interpretation, or synthesis" is utterly unnecessary for something as straightforward as "Airline flies here to there". I agree that we should supplement airline- or database-type sources with third-party sources wherever possible, but a restriction to "secondary" sources is unnecessary and inappropritely biased against this concept and is not applied to any other type of information on the project. SeeWikipedia:Independent does not mean secondary. Secondary sources should be included to show an full article topic's notability, but it is never broadly required for individual, non-controversial items within a section. Third-party sources help in reliability, but "analysis" in secondary sources is an unnecessary requirement that falls outside of generally applicable policies or "usual sourcing requirements", designed against this content.Reywas92Talk20:09, 20 October 2025 (UTC)[reply]
The problem is that if content is sourced, then either you need a new source to verify that the existing source is no longer valid, or the existing one needs to have updated to show the route being cut. Otherwise (and this happens frequently) anyone could just remove the sourced content willy nilly, based upon theirown research or knowledge. The way this has typically been handled in the past is editors just put a link to the news article stating the route has ended in the edit summary - on airport articles it’s done frequently, usually well, but occasionally well—sourced routes are simply deleted with no explanation or source.Danners430tweaks made20:32, 20 October 2025 (UTC)[reply]
Just a couple of examples recently -[39],[40] and[41]. All are well sourced, and are removed without explanation. Where an explanation is provided, it's nothing more thanBA cut route. Without a source, that's simply original research... so yes, a source is needed to remove sourced content - otherwise I could simply remove any route I felt like without explanation.Danners430tweaks made14:43, 21 October 2025 (UTC)[reply]
That's not how our sourcing policies are written. Information that isnot in an article does not require an inline citation. If you thought that was wrong, then you should take it up on the talk page.WhatamIdoing (talk)22:09, 21 October 2025 (UTC)[reply]
Ok, so by that logic I could go into any article and remove sourced content…? The sourcing policies don’t cover that, but it would be almost instantly reverted as vandalism…Danners430tweaks made04:52, 22 October 2025 (UTC)[reply]
@Danners430 Yes, you canabsolutely go into any article and remove sourced content, so long as you provide a reason. Commonly it's for BLP reasons (typicallyWP:BLPCRIME orWP:BLPNAME), but, for something less controversial, I literally spent the better part of my morning removing sourced content fromOkapi because it looks likeWP:CITOGENESIS magicked a common name into existence.GreenLipstickLesbian💌🦋05:00, 22 October 2025 (UTC)[reply]
It does raise a concern though if we pivot back to the topic at hand - if we have a route listed with a valid and accurate source, and another editor comes along and removes it simply saying “the route isn’t flown anymore”. There are no sources that you can see that verify this, and yet there exist sources that state the route IS flown…Danners430tweaks made05:04, 22 October 2025 (UTC)[reply]
GLL's correct: Please do remove information that you know (with certainty) to be wrong. Outdated information is a particular problem in some fields (including, but not limited to, high tech, politics, and medicine) and we'd often prefer to have nothing than to have wrong information.
How often are you truly unable to check whether a flight is scheduled? Imagine that you have a source from 20 years ago saying that Flight nn123 is flown from A to B. You have an editor saying that's no longer true. Even if you can't find "a source", you can ask Mr Google aboutnn123 flight status or go to the airport's website and see what it says, or go to the carrier's website and pretend that you want to book a flight. While you can'tWP:CITE search results, you can actually use search results to figure out whether the removal might be an honest mistake or if it's probably true.WhatamIdoing (talk)03:40, 23 October 2025 (UTC)[reply]
For clarity – pleasedo not !vote yet, this is NOT intended to be an RfC. It is a preliminary discussion to determine the best wording for a future RfC.Rosbif73 (talk)18:23, 20 October 2025 (UTC)[reply]
One suggestion for an amendment - for option three, add the caveat that even the prose should be sourced, and that details would be “fleshed out” following conclusion of the RfC.Danners430tweaks made18:32, 20 October 2025 (UTC)[reply]
Aboutwording the question: By referring to "details of all airlines", the RFC question is implying that this isWP:TRIVIA. One of the goals for anWP:RFCNEUTRAL question is that reading the question doesn't make the OP's POV obvious, and since @Rosbif73 voted against the consensus in an RFC on this subject, this trivializing wording has the potential to cause avoidable drama. In fact, to avoid any drama about "taking another bite at the apple" andWP:Forum shopping (don't like the answer you got in an RFC on the policy's talk page? Well, try again on the village pump!), it might be better if someone else handled any RFC. But if he wants to continue, then that needs to be re-phrased.
I would only include this information if it isverifiable (←click that link) in something other than the airline or the airport's own website (e.g., ordinary article in the local newspaper).
I would only include this information if it is verifiable in a source that discovered this information without consulting the airline or the airport (e.g., the journalist constructed a list of destinations by interviewing passengers instead of contacting the airport's media office).
I would only include this information if it is verifiable in a source that provides an analysis of this information (e.g., compare/contrast with a nearby airport, statement of why this destination is important to the local economy or residents).
I also think that you need to pick a couple of examples and sort through what's intended. For example, to name some examples that have already been discussed, considerHeathrow Airport#Airlines and destinations (dozens of airlines, hundreds of destinations) is very different fromDes Moines International Airport#Passenger (nine airlines, 35 destinations) fromKearney Regional Airport#Passenger (one airline, one destination). Maybe we need a different approach for thethe busiest airports than for the tiny ones. Additionally,Wikipedia:Stand-alone lists are different from a section inside a larger article. So think about what you actually want to achieve, and write it out. Maybe you'll write "We should have deletedList of British Airways destinations when we had the chance, but I don't mind a paragraph in an article about smaller airports, as long as it's prose instead of a list." Maybe you'll write "Because we haveList of British Airways destinations, and it's the biggest airline out ofHeathrow Airport#Airlines and destinations, there's no need for a table in both articles." Maybe you'll write something else. But you should think about what's reasonable and realistic in a variety of cases, instead of fixating on the 5% of busiest airports and then writing something that would apply to 100% of airports, when the considerations for other airports are completely different.
Aboutthe bigger problem:Wikipedia:Wikipedia is a volunteer service, which means that even when a discussion concludes with a consensus that X should happen, that doesn't mean that anyone will actually volunteer to do X. If we want independent sources in certain parts of articles, then we need toencourage volunteers to do this. I see more yelling than I'd like to see about how nobody else did it, and "I" shouldn't have to, because doing boring work like finding appropriate sources issomebody else's problem. RFCs should not be seen as a mechanism to forceother editors to do work that I'm unwilling (or feel too important) to do myself.WhatamIdoing (talk)01:42, 21 October 2025 (UTC)[reply]
I agree that "comprehensive" would be less polarising than "exhaustive", and "all" should probably be avoided. And lastly, despite being one of the main discussion points above, perhaps sourcing is a red herring and should be left to P&Gs; removing sourcing aspects from the RfC would hopefully avoid derailing the wider question as to whether we want these tables or not. Here's a second stab at a question:
Is information about the airlines offering service from an airport, and the destinations served by each airline, acceptable content (i.e. not covered byWP:NOT) in airport articles?
Option 1: A comprehensive table of airlines and destinations is acceptable.
Option 2: Airlines and destinations should be summarised in prose; tables should be excluded.
Option 3: The preferred format for this information depends on the number of airlines and routes, with a summary in prose preferred for large airports.
Option 4: All such information should be excluded.
As suggested, it would probably be preferable that the RfC be asked by someone uninvolved. Volunteers for further refining the wording and posting the RfC welcome!Rosbif73 (talk)07:00, 21 October 2025 (UTC)[reply]
I've just come acrossWikipedia:Village pump (policy)/Archive 187#RfC on the "Airlines and destinations" tables in airport articles which I must have missed at the time (though I see it is actually linked once above), which concludedit is clear that there is consensus that airlines and destination tables may only be included in articles when independent, reliable, secondary sources demonstrate they meetWP: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.
This confirms that there's no point asking about sourcing, as we already have clear consensus to remove poorly sourced tables. Whether it is worth asking about tables vs prose is less clear-cut...Rosbif73 (talk)08:56, 21 October 2025 (UTC)[reply]
To separate the concerns about sourcing vs whether we should have this at all, I'd add an explicit statement about sourcing. Here are some options:
Open with "Is(properly sourced) information about the airlines offering service..." (I put "properly sourced" in parentheses to hint that this detail, though important, isn't the focus of this particular question. If you don't like it, then of course do what you think works better.)
Add something like "Assume for the purposes of this RFC that the material in question would cite a reliable source in compliance withWikipedia:Verifiability".
Expand Option 4 to say "All such information should be excludedeven if it is properly sourced."
The original intention of airlines and destinations was to give some sort of history of the airlines that use the the airport and scope of destination rather than a current list. A bit like "Pan Am - served the transatlantic route particularly New York from 1900 to 1999" "Foo Airlines started the first service to FooLand in 1900" "Scruggs Airways was based at the airport from 1900 to 1999 with scheduled and charter routes to destinations in Europe" so perhaps this "History" option should be part of RFC.MilborneOne (talk)12:06, 23 October 2025 (UTC)[reply]
You keep saying "notable routes" like there is clarity on what a "notable" route is. These aren't being held to the same standards as a stand-alone article. We just need to be able to verify the route to include it on the page.SportingFlyerT·C14:46, 24 October 2025 (UTC)[reply]
And I’m sorry but I fundamentally disagree. This is why there are options 2, 3 and 4 here - I personally am of the opinion that we don’t need comprehensive lists of every verifiable route from an airport, especially larger ones. To me, a notable route is one that has received media coverage for reasons other than simply existing - for example, it’s been involved in a high profile incident, or has been covered by sources due to historical significance.Danners430tweaks made15:03, 24 October 2025 (UTC)[reply]
To reduce this to a yes/no question as suggested, I guess we could eliminate the idea of totally removing all airline and route information, as it seems highly unlikely there would be many !votes for that. So it would boil down to asking whether the tables are encylopedic, and if not then remplacing them by a prose summary.Rosbif73 (talk)09:30, 25 October 2025 (UTC)[reply]
Replacing the tables with a prose summaryis totally removing all airline and route information. How do you even summarize content that's not in the article. It's easy to verify that an airline has flights on ten airlines to fifteen countries on three continents when they're all listed, no so much without a table verifying them. This is just destrying huge amounts of valid content on thousands of pages with no workable replacement.Reywas92Talk17:09, 25 October 2025 (UTC)[reply]
then here's how I summarize it in prose:"United Express provides passenger service toDenver.[2]"
See how easy that was? Any editor do that. Most of our airport aren't Atlanta or Heathrow.Most of them would be easy to summarize. Since I found the example of Kearney by looking for the one closest to the geographic center of the US, I'm now looking atList of airports in Kansas. It has seven (7) airports with commercial passenger service. Six of them would be easy to summarize in a single sentence. Even the second largest in terms of passenger enplanements only has one airline serving it and two destinations. The largest, which is Wichita (home toLearjet and other fabled names in flight), has ~880K passenger enplanements a year.[42]
Looking through those stats, I see thatDurango–La Plata County Airport has a quarter million enplanements a year, with basically two airlines (or four, if you prefer to count United separately from United Express, etc.) and four destinations. I'd bet that a Wikipedia editor could write that in two sentences.
Rogue Valley International–Medford Airport, with half a million enplanements a year, has five (or six) airlines and 10 destinations. That's a bit trickier, but a determined editor could do it. Half a million, BTW, appears to be the cutoff between "small hubs" (>500K) and "non-hub" (<500K) US airports.
Eastern Iowa Airport, with three-quarter million enplanements a year, has five (or eight) airlines and almost 20 destinations. That's reasonable to present in a list, though an ambitious editor might manage it in prose.
Piedmont Triad International Airport, with almost a million enplanements a year, has five (or seven) airlines and 15 destinations. That's less than Eastern Iowa, and again, a list feels reasonable but not absolutely, unavoidably necessary.
If we set the cutoff between "Use prose" and "Accept a list" at "Use prose for small airports (less than 250K enplanements per year; consider a list or table for larger airports", then two-thirds of our articles about US airports would get plain old prose, and it would be easy to do it. If we set the bar a little higher, then it might take a bit more work for airports with 300K or 400K passengers, but it would still only take a few sentences. No content would be "destroyed" or "removed" by this recommendation, and it's no more difficult to verify a short list of destinations in a table vsthe same short list of destinations in a sentence.WhatamIdoing (talk)00:39, 26 October 2025 (UTC)[reply]
High profile incidents have little to do with routes though. It's not particularly relevant thatUS Airways Flight 1549 was going to Charlotte, nor thatJeju Air Flight 2216 was coming from Bangkok. How exactly would this be done? These are usually already listed in the relevant accidents and incidents section, and incidents are about a single plane, not the many planes that serve passengers every day. While there are substantive sources on a variety routes, it would be original research to decide which ones to include and why since they cover different aspects. You're proposing going from deleting the simple and straightforward work that's always been done to something more complex, and it makes for a shitty, incomplete, and less cohesive article to leave out routes, perhaps even among those with the most daily flights and passengers, that are significant yet less newsworthy since they've been mainstays for so long. Many airport articles do mention some major historical flights like first intercontinental route, but this would remove vast amounts of important relevant content, as it's the network as a whole and the relative presence of different airlines that's significant as well. Moreover, other users have deleted prose coverage on such significant flights since they're essentially redundant to the lists. Without the lists, I know you're not going back to restore those items to thousands of history sections. Ans as Sportingflyer said, individual items in an article – here just single words in an table – do not have to provide notability, a concept that is really only used for whether article topics as a whole should have standalone articles.Reywas92Talk17:09, 25 October 2025 (UTC)[reply]
I cannot find a discussion on any Village Pump pointing to the discussion. The [discussion took place on the talk page behind the WikiProject page in 2021.
Support. This mostly explains existing PAGs and applies them to automobiles. There are a few errors (e.g. around capitalisation of compound units), and overly specific prescriptive guidance that make it unsuited as a guideline at the moment.—Femke 🐦 (talk)13:00, 12 October 2025 (UTC)[reply]
The page says incorrectly that compound units do not use capitals, but contradicts that statement later on by correctly using capitals in kWh and Nm. The tips section is an example text you would not find in a normal guideline. Another example is for instance 100% prohibition on variants being bold. If a variant is what the car is mostly known as for some reason, it should be bolded.—Femke 🐦 (talk)07:42, 13 October 2025 (UTC)[reply]
Okay. So there is a little rewording required. Many editors will want to use "RPM" and "MPH" when MOS says to use "rpm" and "mph". We make this explicit because most editors do not go chasing every clause in MOS - we collect the relevant parts of MOS into a single place to make it easier for new editors. As pointed out, we need to reword it to allow for SI symbols such as kWh and Nm. The bolding issue can be looked into too. I also note that MOS itself gets frequent updates in both its decisions and its wording, so neither the capitalisation or bolding issues should be a reason to demote. Stepho talk23:55, 14 October 2025 (UTC)[reply]
Sure, I agree with Femke that this is just instructions for the sake of having instructions and that if you want to make this into a community guideline you need to followWP:PROPOSAL (at a minimum, notifying the wider community).HouseBlaster (talk • he/they)21:40, 13 October 2025 (UTC)[reply]
Oppose. Automobiles have many different conventions in different countries. Some conventions are simply an overwhelming choice of options, eg, km/h vs kph or rpm vs min-1. Sometimes these conflict in an unresolvable manner (eg US style model years vs calendar years used in most other countries). Only by setting conventions can these be easily understandable by the average reader across many countries without requiring readers to understand every possible usage in every possible country. Stepho talk04:21, 13 October 2025 (UTC)[reply]
But do these conventions need to be a project-wide guideline or simply a Wikiprojectguideline advice page? In terms of the choice between km/h and kmh, we already have guidelines to use the appropriate SI unit formatting. This page needs wider community vetting to be designated a guideline.—Femke 🐦 (talk)07:42, 13 October 2025 (UTC)[reply]
AWikipedia:WikiProject advice page is a page written by the participants in that group and represents their advice to everyone else. The name includes the name of the WikiProject, and the group gets to control the content, just like you'd get to control aWikipedia:User essay in your User: space. It's "just an essay", but they are often respected because of the expertise of the authors.
Procedural oppose – I don't disagree that a broad consensus should be attained before promoting any page to guideline status, but I am not sure that this approach is the best one. Long-standing pages like this may have attained consensus as documentation of actualeditorial practice. This proposal is premised on demotion and therefore non-neutral: its apparent goal is to simply invalidate the page without considering the specific reality of its application in the relevant topic area. I believe that it would be more reasonable to hold a neutral RfC to consider whether this page should retain guideline status or not, rather than merely attempting to force demotion.Yours, &c.RGloucester —☎00:30, 14 October 2025 (UTC)[reply]
I'm following the procedure as set out atWP:Policies and guidelines#Demotion. The alternative is to simply revert the inappropriately placed guideline tag and ask for others to start the discussion here to make this a (community-wide) guideline. The route I've chosen means that there is more of a status quo bias in favour of retaining the inappropriately placed guideline tag. I've reworded the section heading to be more clearly a question.
Note that WikiProject advice pages can still be cited and applied. Many essays on Wikipedia are cited frequently and (mostly) reflect consensus.—Femke 🐦 (talk)19:09, 14 October 2025 (UTC)[reply]
My concern is with the way that your own project, which itself lacks any broader community-based authority, seeks to rewrite, eliminate, and otherwise 'simplify' our policies and guidelines. I do not believe that small groups of editors should be plotting to implement changes that affect the broader community. Much as you object to Wikiprojects establishing 'guidelines' that may not have been subject to a formal consensus, I object to your Wikiproject's objective to impose its own philosophy on everyone else, including content editors in specific topic areas, without fully considering the implications of those changes, or consulting those editors. This concern arose when I noticed that, upon launching this discussion, you provided no courtesy notice to Wikiproject Automobiles.
Guideline pages are intended to document actual editorial practice. Before considering whether a guideline should be 'demoted', it is necessary to evaluate whether the practices documented at the relevant page faithfully represent actual editor conduct. Simply insisting that a page must be demoted because it may have evolved informally is contrary to the spirit ofWikipedia:NOTBURO. I appreciate that you and your collaborators are acting in good faith. I am also much obliged that you updated the section heading. I still do not agree, however, that this is the best way to go about what you are trying to do.Yours, &c.RGloucester —☎00:00, 15 October 2025 (UTC)[reply]
What if we make this an RfC? That way, we get more input from a wider range of editors (hopefully), without a double notification of automobile specific editors (both on the essay/guideline and the WikiProject). If the outcome is that the essay/guideline is rewritten to be in line with established guidelines and moved to Wikipedia space, I'd be happy too.—Femke 🐦 (talk)07:07, 15 October 2025 (UTC)[reply]
WP:ADVICEPAGE talks about what happens when a WikiProject advice page becomes a guideline:[A]fter being adopted by the community, they are no longer WikiProject advice pages and have the same status as any other guideline. When this happens, the WikiProject's participants cede any notion of control over the page, and everyone in the community participates equally in further development of the guidelines. Such pages move out from under their original "Wikipedia:WikiProjectSomething/" path. It would make sense to frame an RFC with two options: keep as a guideline and move out from under the WikiProject, or change to an advice page and leave it where it is.--Trystan (talk)22:56, 24 October 2025 (UTC)[reply]
Support The 2021 WikiProject discussion proposed making it "an official guideline of the automobile project", so does not establish even a local consensus for making it a project-wide guideline.--Trystan (talk)17:34, 19 October 2025 (UTC)[reply]
Oppose any changes to these long-standing guidelines without involving the editors who actually use them. These have evolved over decades and concern themselves with minor issues that are specific to automobiles. Mr.choppers | ✎ 02:29, 20 October 2025 (UTC)[reply]
You call it a guideline but it is not a guideline in the Wikipedia sense of a Wikipedia guideline. Any page with some prescriptive content can naturally be called a guideline, policy, standard, etc. On Wikipedia, i.e., within this encyclopedia-building project, "guideline" has a particular meaning defined by policy. This page was incorrectly tagged as a guideline using a template reserved for guidelines when it is not a guideline. Proposing to "demote" it was the wrong framing because it actually empowers the wrong idea that the page is a guideline, since for something to be demoted from guideline status it first must be a guideline. —Alalch E.08:04, 25 October 2025 (UTC)[reply]
Remove the guideline tag without an RfC. This is a mistagged page. Someone put the guideline template by mistake, not understanding what the template is for.Wikipedia's policy on Wikipedia guidelines (titled "Wikipedia:Policies and guidelines") says:Simply adding the{{policy}} or{{guideline}} template to a page without the required consensus does not mean the page is policy, even if the page summarizes or copies existing policies. The existence of the markup for the transclusion of the guideline template in the discussed page's wikitext is a content error that any editor can correct. There is nothing to "support" or "oppose" here and nothing to "demote". A non-guideline page mistagged as a guideline is not a guideline for it to be demoted from a guideline to a non-guideline: it is already not a guideline. —Alalch E.07:52, 25 October 2025 (UTC)[reply]
@Andrew Davidson: I'm not saying that this is a WikiProject advice page, I'm just saying that it is not a guideline. Someone just incorrectly put up the guideline template on a page that is not a Wikipedia guideline. This discussion is like "should we phase out this banknote" and the "banknote" is a white piece of paper with "THIS IS MONEY" written on it. You will come and say "meh, this money business has become too complicated, oppose". Consensus does not form to "phase out" the "banknote". Can I go to a store and buy a gallon of orange juice with this piece of paper? —Alalch E.18:33, 25 October 2025 (UTC)[reply]
So you're saying I'm getting orange juice with a white piece of paper with "THIS IS MONEY" written on it. If not orange juice, maybe bubblegum? —Alalch E.23:54, 25 October 2025 (UTC)[reply]
@Alalch E.: FWIW, on a trip to Italy in the 1980s the people who made money (as in mint workers, or perhaps it was the people who distributed coins, I don't know, I was young) went on strike. When you bought things, stores would write IOUs on tiny pieces of paper rather than hand you change. Near the end of our stay at a campground, me and my siblings went and bought Nutella and candy with all the little slips of paper we had accumulated, since they would be unlikely to be accepted anywhere else. Mr.choppers | ✎ 03:47, 26 October 2025 (UTC)[reply]
The main differences between a guideline and a WikiProject advice page are that the latter is maintained by the members of a WikiProject and represents their consensus advice. A guideline requires broad community consensus, and consequently it is not part of a WikiProject's pages and no WikiProject has any special role in updating it. A project content guideline isn't really a separate classification, it is just a guideline that deals with the content of admin pages, in the same way that a content guideline deals with article content.--Trystan (talk)18:38, 25 October 2025 (UTC)[reply]
That's a theory but the practice is otherwise. For example, I tend to focus on the main page currently and this is effectively organised as a project for each section. And they have their guidelines such asWP:ITN/R forIn the News andWikipedia:Did you know/Guidelines forDid You Know? These are not "advice" – they are taken quite seriously in the day-to-day operation of those projects. This is the practical test for such pages – do people take them seriously?
Glendower: I can call spirits from the vasty deep.
Hotspur: Why, so can I, or so can any man; But will they come when you do call for them?
ITN and DYK are rather exceptional cases, as they aren't WikiProjects in the normal sense. WikiProjects are entirely voluntary; they provide a forum for collaboration, using their WikiProject pages to discuss articles, generate reports, and provide advice. ITN and DYK are different, providing the only process for participating in the content of the related main page features. By contrast, a user interested in editing automative articles is under no obligation to participate inWP:WikiProject Automobiles. The question is then why would it be preferable to have community guidelines about automobiles located in the WikiProject's pages. AvoidingWP:CREEP definitely is not helped by creating confusion between community endorsed guidelines and the advice of a WikiProject's participants.--Trystan (talk)17:15, 26 October 2025 (UTC)[reply]
@93.176.153.172: For future reference, if somebodydid use an incorrect flag, you are free to just replace it yourself. You only need to escalate the issue to a discussion board such as this one if it is contentious, with editors continually arguing over which flag to use. Also, keep in mind that Wikipedia isnot censored - we leave it up to the end user to not view content that they think is illegal in their home country, and I don't think Spain has German-style laws on the use of fascist symbols to begin with; even in Germany the use of Nazi symbols is allowed in educational contexts.Passengerpigeon (talk)08:04, 23 October 2025 (UTC)[reply]
I have a strong belief in changing the policies of AI on Wikipedia. I am outraged on the current policies.Wikipedia:WikiProject AI Cleanup is ok. However, it's misunderstood that not all Wikipedia AI edits are poorly written. Recent updates have made it a lot easier to make AI edits accurate. Although I do believe it still has its cons. I want justice. I want all sourced, well written AI edits to not be cleaned up. As, I feel like AI is the future of Wikipedia if we like it or not.CostalCal (talk)02:18, 20 October 2025 (UTC)[reply]
Can you point to any "all sourced, well written AI edits" that were reverted? AI-assisted edits are held to the same standard as unassisted edits. I certainly have used ChatGPT for copyediting suggestions.Catalk to me!04:54, 20 October 2025 (UTC)[reply]
Wikipedia's singular value as a project is that it brings together the independent work of many thousands of independent, human writers from right across the globe in one, unmonetarised place. As soon as we outsource the business of writing and thinking to machines, we might as well sell the project to Google or some other corporate abomination. Wikipedia editors need to be able to think, research, and write using their own intellect. Without this basic qualification, participation in complex editorial discussions is impossible. Given that these discussions may well shape the world's understanding of events for years to come, the last thing that we should want to do is encourage participation by incompetent editors who need a machine to issue forth any coherent utterance.Yours, &c.RGloucester —☎05:32, 20 October 2025 (UTC)[reply]
This isn't really something suited for village pump, but another big problem with your edits besides what others have mentioned is that they often add unsourced, speculative paragraphs about what "could" happen. (example:last paragraph here)This is against Wikipedia policy no matter whether an AI or human wrote it, butAI does it more than humans do. It also includes the kind ofsuperficial analyses characteristic of AI, such asOverall, the combination of a Red Flag Warning, dry fuels, and long-term drought provided the perfect backdrop for the Wolf Fire's explosive growthhere; not only is this entirely unsourced, but it's a vague combination of synthesis and opinion.Gnomingstuff (talk)17:35, 20 October 2025 (UTC)[reply]
... and just plain bullshit that a high school student makes up when he realizes his homework is due in 15 minutes.EEng03:02, 21 October 2025 (UTC)[reply]
Wikipedia has nosingle "AI use policy", "AI-generated content policy", "AI content guideline", et cetera. However, there exist disparate portions of policies and guidelines which are specifically and explicitly about AI-generated content. They are listed inWP:AIPOLICY. —Alalch E.14:39, 25 October 2025 (UTC)[reply]
You are on a final warning for adding incorrectly sourced content. AI or not you need to ensure that your edits are supported by the correct reference.Theroadislong (talk)14:32, 21 October 2025 (UTC)[reply]
When discussion hasended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
English Wikipedia's recall process was largely based on German Wikipedia's recall process, but it has played out differently here than it did on German Wikipedia. Now that we've had 10 recall petitions it seems like a good time to examine the process.
Support 1 or more of the following:
Process is working well, no changes needed
There should be some way of enabling support for the admin during the petition phase
There should be fewer signatures needed
There should be more signatures needed
30 days is too long, the petition process should be shorter
30 days is too short, the petition process should be longer
Keep recall, but develop a different process than petition leading to a re-RFA
Keep recall, but do some other change to how re-RFA works
Keep recall, but do some other change to how the petition works
Recall should be abolished
Prohibit admins from !voting in RFCs to amend recall
When closing the closer is encouraged to think about overall support relative to participation in the RfA (e.g. if 5 people support Foo, 10 people support the opposite of Foo, and 30 people didn't support either but participate elsewhere, the consensus may be no change rather than opposite of Foo) and where abartender's close may be appropriate.Barkeep49 (talk)14:31, 21 October 2025 (UTC)[reply]
Support D, weak support for B, open to G. I am very opposed to abolishing a community recall, but I think we can do better than our current process. Right now we have changed a system where 15 highly scrutinized and widely endorsed editors make a decision about an editor's fitness for adminship (ARBCOM), to 25 self-selected people. I don't think that's a good change. This also stands in contrast to the 200+ people that can be counted on, in the current era, to show up to an RFA. We based our process on the German Wikipedia's process, but didn't adjust the number of supports needed despite being a much larger community. Perhaps for this reason, perhaps for other reasons, we also haven't seen most candidates go through with the re-RFA, which is a difference between the two. This can perhaps be explained away for good reasons (the "rightness" of the recalls to date) or perhaps ones that deserve scrutiny (differeing cultures of enwiki and dewiki). The idea of allowing editors to support may help admins who have support from the larger community realize that and not think they are starting off a re-rfa with 25 opposes or perhaps it's just better to raise the the threshold so borderline petitions without widespread community support fail at that stage, but I don't think we should continue where a 25 signature petition essentially is a desysop because I find it completely out of line with our other community practices, norms, and values. Best,Barkeep49 (talk)14:36, 21 October 2025 (UTC)[reply]
I support Mz7's analysis of the issue below. So one change I would be open to, in addition to what I've already supported, is actually dramatically lowering (to say 3 or 5) the number of signatures needed combined with requiring everyone involved to be extended confirmed. This would (hopefully) keep out the purely frivolous petitions (none of which we've had so far depending on how one views the inactivity ones) while also not starting the admin "down" 25 votes at a re-RFA. Best,Barkeep49 (talk)16:11, 22 October 2025 (UTC)[reply]
Support D and/or E, Support B assuming the details work, Very open to and interested in developing G - Very similar to Barkeep here, this is a net positive process that would benefit from tweaks. I think the easiest thing to do would be to reduce the duration of a petition down to 14 days - most petitions we've had have long-since succeeded or failed at that point. I like B in principle, but am wary of accidentally creating a mudslinging mess, in which case we might as well be at RFA. The biggest issue is that the RRFA at the end in practice hasn't happened, so the 25 signatures is a de facto desysop. I haven't seen a recall that went strongly off the rails yet, although Necrothesp's came close.Tazerdadog (talk)14:52, 21 October 2025 (UTC)[reply]
Support A, but also remove the little clause that allows people (i.e. other admins) to remove a recall petition prematurely if other means have not been explored first or whatever it is the get-out clause says. (edit: "Other methods of dispute resolution should be attempted before a recall petition is initiated.") - oh and also "An editor may sign no more than five active petitions at a time." is sketchy af. Tewdar 14:54, 21 October 2025 (UTC)[reply]
Also there should be alerts for recalls like we get every time there's an RfA, and avery big alert for every user (like, email and Web notifications) any time anybody attempts to make even the slightest alteration to the recall process like what seems to be happening here. Andsupport K, what a great idea. Tewdar 10:21, 23 October 2025 (UTC)[reply]
Support what let's call I.a (1 signature per user per 90 days) per my commentbelow.Weak support D as second choice to I.a: I don't think it'd make a huge difference to go with a bigger number, and there's some argument that it could be even more discouraging of RRfA than it already is, which is why I would prefer I.a, but if we retain a system where anyone can support every recall (beyond the so-far inoperative restriction on 5simultaneous signatures), then increasing the threshold is better than nothing. If we're going to do that, I don't think it'd make much sense to just tweak it a bit, though; something like 40 or 50 would be preferable.Neutral on G&H. Oppose all others, in particular B (that's called RfA!), C (obviously per !vote on D), and of course J. --Tamzin[cetacean needed](they|xe|🤷)14:55, 21 October 2025 (UTC)[reply]
I'd be all in favor of your I.a - even if you can't vote against another admin solely because their recall came up before your timeout period was over, nothing's stopping you from using the discussion section to try to convince other users to sign - except that, in practice, I think it'd be more likely to encourage sockpuppetry than active persuasion. Same reason I didn't seriously propose that the ambiguity closed bythese edits be resolved the other way. —Cryptic02:23, 24 October 2025 (UTC)[reply]
Support A as first choice. After 10 recalls, no obvious issues with the system have become apparent, so there is no actual need to change things. Having said that, I would not be opposed to shortening to nothing less than 15 days, and am certainly opposed to making the process longer than the current 30 days. Lowering the number of signatures seems like a bad idea, raising it to more than, say, 40 seems like a bad idea as well (the 25 is "there are serious concerns with your adminship, please either stop being an admin or at the very least go through RfA again": if you raise the bar to 50, 60, ... signatures, then you are just saying "you are not fit to be an admin at the moment" and can simply abolish the whole RRFA thing). I see no reason to support BCFGHI at the moment, and no reason at all to support J.Fram (talk)15:10, 21 October 2025 (UTC)[reply]
Support A given this RfC is being held. This is not due to a particular strong feeling regarding many of these, but because that lack of feeling is due to many of these seeming potentially cosmetic tweaks that would not greatly change the underlying process.Oppose B though, on practical/procedural grounds. The point of the petition is to bulwark against stray fires. Allowing supports at that stage seems liable to essentially turn the petition into another (R)RfA.CMD (talk)15:35, 21 October 2025 (UTC)[reply]
Support E and/or D per Barkeep. 30 days is a long period. 14 or 15 days seems about right to make sure that the community is aware of a petition. Oppose others. --Enos733 (talk)15:37, 21 October 2025 (UTC)[reply]
Support B and DStruck in favour ofUser:Mz7/How to fix administrator recall While I take Tamzin's point that B is what you get at RfA, I still think this would be a good idea, as it directly addresses my main concern with the recall procedure, namely that it only counts votesagainst the admin, completely disregarding the level of support they may have. So the relatively small number of 25 people (which IMO should be doubled, hence D) can force an RfA/election, even if 250 were perfectly content with the admin in question. And before someone says "but in that case they'll have no trouble getting the mop back"... well, maybe,if they choose to go for it. What if they feel so betrayed or snubbed or whatever that they don't even want to try? Then they'll never find out that their supporters outnumber the opponents by an order of magnitude. We don't grant the mop by counting only support votes, why potentially take it away by counting only opposes? --DoubleGrazing (talk)15:43, 21 October 2025 (UTC)[reply]
Support B Agree with DoubleGrazing – if we select admins via a vote, why shouldn't the process for deselecting them be the same? Basing recall purely on oppose votes would be like only considering support votes in an RfA (which I don't think anyone would consider a good idea?).Number5716:02, 21 October 2025 (UTC)[reply]
Support B and D perDoubleGrazing, but perhaps more immediately we should require an actualconsensus in favor of the recall (or at least a 50% threshold in favor of it), in order to avoid wasting resources on bureaucratic processes and potential system-gaming as an end-run around disputes.BD2412T16:06, 21 October 2025 (UTC)[reply]
Support A seems to be working fine enough. The first part is not supposed to be a full debate, it is just a check to avoid wasting the subject and the communities time with frivolous requests - and that is working. —xaosfluxTalk16:26, 21 October 2025 (UTC)[reply]
Support D and E, okay with B. If you can't find, in a month's time, 25 people an admin has irritated at some point or another, they either haven't been one long or are totally unwilling to make tough calls in contentious areas. That shouldnot be what we want; there are a lot of cases where someone's going to hate your decision no matter what it is, and often those are the cases which most need to be dealt with. So, make it shorter and require more signatures, to reach a point of "This admin really has made an egregious bad call or a lot of them", not "This admin has made tough but defensible calls that were sure to annoy someone no matter what." B would make a reasonable alternative to that in principle, but then we basically have the possibility oftwo repeat RfAs, and the thought of one is bad enough.SeraphimbladeTalk to me16:33, 21 October 2025 (UTC)[reply]
Support D I certainly don't think these need to be open longer as it seems like most of the recalls get 25 signatures long before running out of time. It might be good to provide some way to allow a defense of admins during the survey phase though. This seems like something missed.Simonm223 (talk)16:36, 21 October 2025 (UTC)[reply]
Is the best solution raising the number of signatures, or is it shortening the time to gather them (i.e. would option E be just as good?)Tazerdadog (talk)16:44, 21 October 2025 (UTC)[reply]
I would also support raising the number of signatures. I'm not sure shortening the time would really do much TBH. But I do think it's a good idea to allow some form of support statement for admins going through this. I'll be honest: the main thing that has prevented me from trying out for an admin position is the fact that they have to run a gauntlet just to pick up the mop and then, if people get upset about their comportment, we expect them to sit in silence and wait to see if they've upset enough people to then be told not to do this anymore. It's not a great way to treat some of our more-engaged volunteers TBH.
I understand we need checks and balances for when admins screw up. I've even signed one or two petitions. But I think we need to give some way for the process to allow people who think the admin is doing good work to be involved in the decision.Simonm223 (talk)14:11, 22 October 2025 (UTC)[reply]
Support G. Broadly, I do agree now that a community-based desysop process like this is and has been desirable. (I did not always hold this view.) However, there are several key flaws with the recall system as it is currently formulated, and I have written a bit of a lengthy essay atUser:Mz7/How to fix administrator recall with my thoughts. The high-level summary is this:a certified recall petitionis a desysop. When we supported creating the recall process, there was the impression that the petition would just be a lightweight filter for frivolous requests, and the re-RFA would be where we actually examine the evidence and discuss whether to desysop. The reality is that the petition itself is what functionally desysops administrators and forces them to reassert themselves as an RfA candidate just like any other RfA. The only functional difference between a regular desysop and a successful recall petititon is that the effect is delayed by 30 days, and if the recalled admin chooses to do an RfA within those 30 days, the support threshold is slightly lower. So what does this mean? It means that we now have a process that lets 25 self-selected editors desysop admins withno requirements for evidence, consensus, or prior dispute resolution. What do I think the solution is? I've detailed this a bit more atUser:Mz7/How to fix administrator recall § Proposed solution, but at a high level, I think that the recall process should requireconsensus to desysop in order to desysop. A successful recall petition should lead to arequest for de-adminship (RfDA) instead of a "re-request for adminship" (RRfA). This shifts the focus of the recall discussion to evidence that an administrator is actually causing some active harm (or would be likely to cause harm in the future), and it converts the petition system into being a legitimate filter against frivolous desysop requests, as opposed to beingthe desysop process.Mz7 (talk)16:41, 21 October 2025 (UTC)[reply]
I would supportUser:Mz7/How to fix administrator recall#Proposed solution, but I do think it is important to hash out where ADMINRECALL (or a similar process) fits into the structure of Wikipedia (and whether doing something different would cause issues). In my mind, a ADMINRECALL is a community-led L2 desysop for obvious long-term errors and I wonder if a RDfA raises the bar there or keeps it the same.Sohom (talk)17:07, 21 October 2025 (UTC)[reply]
Support D Raise the required number of signatures to 30. Defense of the admin can always be put in the discussion section or the talk page. This was especially prevalent in the first two petitions, which had boldedOpposes. Also, based on discussion below of Cryptics query, we should raise the sufferage requirements. I don't know to what standard exactly, but we definitely need to raise them. I alsoStrongly Oppose J. While Novem and others make great points about removing admins at a time of needing admins (which is very true), sometimes we need to prioritize quality over quantity (and I have very low standards compared to most). The whole point of recall was to give people more reason to vote support for candidates, because if the community made a mistake, we can always recall the admin. It's unfortunate that even with recall, some people still refuse to support decent admins, as evident at AELECT and a few RfAs.fanfanboy(blocktalk)17:00, 21 October 2025 (UTC)[reply]
Somewhere between G and J -- I share some of Mz7's concerns and remain unconvinced that recall is the necessary format or that existing measures wouldn't have been adequate to address the 10 examples we've had. I think in the current format both the time period and the number of supports are out of whack (too long, and too few). I reiterate the points I made in Night Gyr's case about the potential for misuse of recall to allow a smaller local consensus to bypass our project-wide policy on administrator inactivity. But addressing that is not one of the available options, so I'm stuck between "throw it out and start over" and "throw it out and move on", either of which I'd be fine with.⇒SWATJesterShoot Blues, Tell VileRat!19:38, 21 October 2025 (UTC)[reply]
Support for B and/or D, weak support for G recognizing that it's very easy to say "come up with something else" but that doesn't really get us very far.signed,Rosguilltalk19:43, 21 October 2025 (UTC)[reply]
A lot of the discussion here has focused on the inactivity-based recalls, and those in favor of the status quo have expressed a dismissive attitude to hypothetical situations. While that's not unreasonable, I would flag that my primary concern here is how easy it would appear to be to abuse this process--a hypothetical, but hardly irrelevant, concern. With the rules set as they are now, I imagine that with a bit of legwork and sockpuppetry, I as a lone individual could get someone de-sysopped. I imagine it would take about a month of work to do this sloppily, six months to a year to do it semi-convincingly, and a few years to do it in a fashion that would be difficult to detect or dispute. That's my assessment of what an individual could do--a well-funded organization or state could accomplish it much more readily and convincingly. Of course, such a recall would likely raise suspicions and be called out at least part of the community, and I do have some faith that we'd survive the ensuing crisis of trust. But I think it would be better to modify our practices to avoid such a crisis entirely, and that support for the status quo is being naive with respect to what forces external to our community would be willing and able to do.signed,Rosguilltalk14:50, 23 October 2025 (UTC)[reply]
AndI (there should be some actual issue stronger than "admin meets the letter of the activity requirements"). Lots of good stuff in Mz7's essay too. —Kusma (talk)10:04, 22 October 2025 (UTC)[reply]
AndK (proposed by asingle-purpose IP) shouldn't have been added to the list of proposals. A topic-ban for a thousand people (including me) should not even be debated without evidence that it is required.oppose, in case it isn't clear, but suggeststriking. —Kusma (talk)18:09, 25 October 2025 (UTC)[reply]
Support for B Support for the admin needs to be factored in to the equation, and not simply await an RfA that the admin may have no stomach for..--Wehwalt (talk)20:17, 21 October 2025 (UTC)[reply]
I'm hesitant to provide any !votes on a process this open-ended, because the number of proposals more or less precludes specific consensus emerging, and I worry about what a bartender's close might produce. In the interest of aiding a temperature-taking exercise, I will note that I explicitlyoppose A, C, and J. I am open to the other ideas but specifics are needed: there are distinct directions we could go that are mutually exclusive but would represent improvement. The rationale behind a two-step recall process is reasonable: the first step is supposed to be "light-weight", and simultaneously act as a filter against bad-faith requests; and an admin who was moved to the second stage but still retained community support ought to be able to pass RRFA as we have set it up. I still believe this reasoning is sound. And to the extent that we have used it with active administrators who made serious mis-steps, it has worked as intended. The difficulty with it has been in two specific areas, in my view; first, that given our large editor community, getting any 25 editors to sign something is perhaps too easy; and second, that when the subjects of recall are admins who are not very active, the perceived cost-benefit ratio of an RRFA is not favorable, and consequently administrators resign instead of running at RRFA. The first problem is easier to fix. Given the size of our community, 25 votes in 30 days is far too few. Most admins who work at SPI or AE or ANI would likely accrue that many. If we preserve a two-step recall process, the first step must set a higher bar than the number of editors an active admin taking good decisions might annoy. The second problem is difficult: when the justification for recall is losing the community's trust, we cannot effectively prohibit inactivity recalls. But I am hopeful that addressing the broader issues will help. That said, I am not certain that a two-step process is necessarily the best process long-term. I can see a genuine case for a one-step process: essentially, immediate RRFA. This has some major attractions: my gut tells me that shortening the process and allowing support will improve the effect on admin morale even if the eventual outcome is the same. The biggest difficulty with this is potential inconvenience to the admin in question, but this is a fixable problem. I rather think we need to settle on whether we want a two-step process, before refining the steps, at least for a trial period. A second RfC will be necessary.Vanamonde93 (talk)20:54, 21 October 2025 (UTC)[reply]
@Asilvering: I could see it playing out in different ways: we could, for instance, allow it to be triggered by a good-faith request after an admin action was overturned via noticeboard discussion. Arguably the simplest way is what's being implied with the suggestion of allowing supports at the petition stage: if we're allowing support and opposition for retaining admin status, we have an RRFA triggered at the request of any EC editor. It's possible I didn't choose the best words above, though. I'm not advocating for dropping the petition stage; certainly, I think allowing an RRFA to be initiated at any time by most editors would be a mistake, which is why I'm not supporting B. But I do think we need to give serious thought to whether drawing out the process is the best way to balance admin morale and community recall.Vanamonde93 (talk)02:57, 23 October 2025 (UTC)[reply]
Support A; nobody has presented any convincing evidence of problems. Andoppose B in strongest possible terms as a suggestion that completely misunderstands the purpose of the petition. The sole purpose of the petition is solely to prevent people from having to go through a rough, adversarial process in the case ofcompletely frivolous recalls, which every indicator shows that it is doing. It's not supposed to be a stumbling block for any recall with even the slightest chance of success. Making the initial petition adversarial would defeat the entire purpose for it - in that case, why not just go straight to a single RRfA? The people who decline to continue to a RRfA after a successful petition are usually doing so because they want to avoid that adversarial process; if we made the petition adversarial, they'd just resign as soon as it started getting off the ground. And if it were adversarial, what would be the point of the RRfA afterwards? Basically, for the people supporting B, how do they envision the petition differing from the RRfA, and why do they think we should have a two-step process at all? (Also, I will point out that this RFC contains a bunch of complaints about the petition stage, but doesn't offer the obvious option of "remove the petition stage, have recalls consist of a single RRfA." If people are viewing the petition stage as a referendum on an admin rather than a quick-and-easy sanity check, perhaps the problem is that we should just have gone with a single-step process in the first place? We already have a solution to obviously frivolous requests, it's calledWP:SNOW. Anyone can attempt to open an ANI or AE thread about a user seeking to get them banned at any time, no matter how frivolous it is, and we somehow deal with that; how are recalls different? For that matter, why is it so much easier to seek to get an administrator banned than it is to get them desysopped?) --Aquillion (talk)20:58, 21 October 2025 (UTC)[reply]
Support G. I agree with Mz7; it is a problem that an admin can be removed without even a simple majority consensus ever being achieved for removal. I thinkUser:Mz7/How to fix administrator recall#Proposed solution makes sense, though I would make it a little easier to remove an admin; 50% should be enough (which is what Commons uses). In any case, 60% is still better than 40%, which is what the current policy calls for. --King of ♥ ♦ ♣ ♠21:21, 21 October 2025 (UTC)[reply]
SupportUser:Mz7/How to fix administrator recall. Sosupport E (having this hang over your head for 30 days sounds like torture) and I supposesupport G per Mz7. I'dsupport D, but really would prefer a successful recall to automatically transition into a "request for de-adminship" as Mz7 proposed.Guettarda (talk)21:31, 21 October 2025 (UTC)[reply]
Support A, as the process has repeatedly shown that it's working just fine and as intended. I'm fine withsupporting D as well, just in the hopes that it would stop more people from whining about every recall petition that happens. Doubtful that would be the case, but one can dream.SilverserenC21:58, 21 October 2025 (UTC)[reply]
Support B, I and much ofUser:Mz7/How to fix administrator recall. Specifically it is a problem that 25 people can effectively desysop an admin before they're even aware that there is a recall process. Petitions should not be open for signatures until the earlier of the admin concerned explicitly noting that they are aware of the petition or 24 hours after the editor's first edit after being notified of the petition on their talk page, and there should be a way for editors to actively oppose recalling the administrator.Thryduulf (talk)22:01, 21 October 2025 (UTC)[reply]
I'm very surprised to see so many comments along the lines that recall is working as intended - please could those editors show some evidence of this with reference to the discussions that resulted in recall. I've read those discussions and the reality does not match the intent of what most commenters there were supporting.Thryduulf (talk)22:01, 21 October 2025 (UTC)[reply]
Thryduulf, it seems very odd that you're only demanding people to "show evidence" that recall is working as intended, but not for the reverse. How are you deciding which comments are self evident enough that the "reality does not match the intent of what people were supporting"?
It seems to me that you are decided that RECALL must only work the way you think it should, and everyone else must always explain themselves.Soni (talk)00:58, 22 October 2025 (UTC)[reply]
Okay, here's some proof: In the RFCs that led to RECALL's creation, nobody expected it to be used to desysop admins who were skating on the thin edge of INACTIVITY. There is not a single !vote for it that says anything remotely like "This will be good for INACTIVITY cases, too". The comments are about actively abusive admins, not about absentee ones. But a majority of the RECALL petitions so far have been about INACTIVITY. Therefore, RECALL is not working "as intended".WhatamIdoing (talk)02:51, 22 October 2025 (UTC)[reply]
I would argue that out of those three inactivity cases, two were of the editors wereWP:GAMING to stay within the activity criteria, which falls squarely into "abusive behavior" that should have community review.Sohom (talk)03:06, 22 October 2025 (UTC)[reply]
Firstly there is absolutely no consensus that either those editors were actually gaming, or that gaming the inactivity requirements is "abusive behaviour". Secondly, a recall petition is not, in practice, a community review - it's a place where an editor has 30 days to see if 24 other people agree with them that an admin should be desysopped (for any reason or no reason). If you can find any comments in the discussions that resulted in recall intending that then please link to them here as I've not found any.Thryduulf (talk)03:12, 22 October 2025 (UTC)[reply]
The RECALL petitions and surrounding discussions shows there was enough agreement among editors that there was a case to be made for GAMING the criteria. The RECALL petition is the start of a process of community review which culminates in a re-RFA, the fact that the administrators decided to not engage with the community review process is their decision. That does not allow you to assert that there were no concerns of GAMING the inactivity criteria. I'm not arguing that the process is perfect, but I don't think those two RECALL petitions are necessarily standout examples of RECALL going wrong. You'll see that I have explicitly saidout of those three inactivity cases, two wereWP:GAMING because I see thethird one as being a particular display of what is wrong with the process, in that you can convince 25 people to vote against me in 30 days, if you spin any set of events correctly. TLDR, I think INACTIVITY is the wrong hill to die on, but I do think recall has it's flawsSohom (talk)03:42, 22 October 2025 (UTC)[reply]
But the fact that (some part of) 25 people signed a petition doesn't mean that the community as a whole endorses the view that carefully complying with the written rules is GAMING, either.WhatamIdoing (talk)03:48, 22 October 2025 (UTC)[reply]
Gaming is weird, tbh. Like, takethis guy, who made about ten stupid edits that they self-reverted to get their account autoconfirmed, just so they could fix a template.[46] Indef blocked, they couldn't figure out how to format their appeal so they went away forever. Many wikipedia power users... really don't like anything that could be perceived as gaming, I guess.GreenLipstickLesbian💌🦋06:47, 22 October 2025 (UTC)[reply]
I can't speak for others but inactivity and gaming most certainly could lead aa user [to believe] that an administrator has lost the trust of the community, which is what I supported andbelieved the spirit of ADRC to be. I don't think anyone created an exhaustive list of situations they considered to warrant recall but I suspect, had there been one, inactivity would have made the list.Sincerely, Dilettante11:40, 23 October 2025 (UTC)[reply]
Support D/E/G - I think that a formalized recall process of some kind is necessary, and have long felt that many users are somewhat immune to traditional forms of accountability, especially when it relates to civility. That said, the current system seems to incentivize knee-jerk recalls, the signature requirement without a requirement for discussion is contrary to the basic principles of this community, and the lengthy time the petitions stay open makes hitting the requirement almost inevitable. At a minimum, I think that the signature requirement should be increased and the petition length should be decreased.ThadeusOfNazereth(he/him)Talk to Me!22:16, 21 October 2025 (UTC)[reply]
Support A. Weak support for D; the number of signatures could be raised from 25 to 30, but I'm not opposed to keeping it at 25. Regarding B, if editors want to show their support for the admin, they can do so in the Discussion section or the admin's talk page. Oppose J.Some1 (talk)22:57, 21 October 2025 (UTC)[reply]
Support J. At a time when we are having a lot of trouble finding new admins, making it easy to destroy existing ones should in my opinion not be the priority. I find the 3 recalls related to inactive admins to be especially egregious. Admin inactivity should be handled by increasing the inactivity requirements via an RFC atWikipedia talk:Administrators, not via dragging individual inactive administrators through the mud at WP:RECALL. We often talk about how we should notWP:BITE the newcomers. How about not BITING the admins either? Keeping administrators motivated is in my opinion just as strategically important as keeping newcomers motivated. –Novem Linguae(talk)23:54, 21 October 2025 (UTC)[reply]
Support G, above all, with secondary support forB, D, and J. Here's what I mean. I accept that there have not been any egregious cases of admins being subjected to petitions unfairly. Overall, this has worked reasonably well. But what I see as a problem is that it really boils down to a vote, posing as a petition, in which only one "side" gets to vote. And that goes against everything that Wikipedia has enshrined in a culture ofWP:CONSENSUS. It needs to be more of a discussion, and a discussion that lasts more than a day or so. Making it expeditious isn't a good enough reason, nor is the fact that nothing really bad has happenedyet. I'd like to see a couple of days of discussion, before anyone other than the petition initiator can add their signatures to the petition. --Tryptofish (talk)00:35, 22 October 2025 (UTC)[reply]
Support J – This process does nothing to encourage administrative accountability; it simply encourages mob justice. Administrators will inevitably create enemies in the course of their daily job, and we all know this. Let's not be coy about the political nature of Wikipedia editing. After a few years wielding that vaunted dustman's mop, the rank-and-file administrator will almost certainly have twenty-five editors champing at the bit to enact a public humiliation when the time is right. Those who disagree with the petition are not even granted a voice in the matter. Why subject our administrators to this farce? Whither that well-known piece of Wikipedian wisdom, 'Wikipedia is not a democracy'? I agree in principle that administrators are dustmen, and that their tools should be readily removed when problems arise. I do not believe, however, that this process is the right way to do it. We have ArbCom, the elected representatives of the community, who at least have an obligation to honour the principle of due process. Abolish this black stain on Wikipedia history, and leave justice to those who are capable of serving it with care.Yours, &c.RGloucester —☎01:51, 22 October 2025 (UTC)[reply]
I is forWP:INACTIVITY, which should not be grounds for a recall petition because complying with the actual, written policy should not be grounds for being desysopped. In practice, I expect this to mean those who think the INACTIVITY policy should be stricter will have to find some other excuse first ("I asked him about a routine admin action from six years ago, and it took him three months to reply") or just be vague about it ("I personally don't trust this admin with the tools any longer").WhatamIdoing (talk)02:07, 22 October 2025 (UTC)[reply]
Support A - "Process is working well, no changes needed". I haven't seen miscarriages of justice so far. Counterintuitively, recall is probably helping add additional admins; it's easier to support a candidate if you know they can be recalled if they turn out to be problematic. --A. B.(talk •contribs •global count)04:48, 22 October 2025 (UTC)[reply]
I'm very much asupport A kind of person. I note that (a) every single successful recall petition was supported by highly-regarded sysops; (b) every single successful recall petition was for a sysop who'd exhibited genuinely problematic behaviour (bearing in mind the community thinks sysops should be active in order to keep their knowledge of custom and practice current); (c) the only recall that should have failed, did fail and got withdrawn promptly; and (d) sysop behaviour has noticeably improved now that there are consequences. This process is working perfectly and it's one of the best things we've ever done.—S MarshallT/C08:41, 22 October 2025 (UTC)[reply]
And,oppose K. Ofcourse admins should get a voice in this. Every single successful recall has been supported by admins whom the community respects, and if there isn't a respected admin who thinks we're over the bar for a recall !vote, we probably shouldn't be holding one.—S MarshallT/C21:46, 24 October 2025 (UTC)[reply]
I'm not sure if I read your comment correctly, but I'm pretty sure option K pertains only to admins participating in RfC's aboutamending recall, nothing about participation in the process (recall) itself.fanfanboy(blocktalk)22:13, 24 October 2025 (UTC)[reply]
Oop, yes, I misread that! ... But now that I've re-read it I still oppose K. You've got to give people a voice in discussions that affect them. To deny them that voice is oppressive and I think ethically untenable.—S MarshallT/C07:50, 25 October 2025 (UTC)[reply]
@Fanfanboy: Speaking of which, you haven't voiced an opinion on K. Are you neutral on it, or would you like to !vote on it? I'd ping ever !voter about it, but there's a lot and I'm a bit busy at the moment.QuicoleJR (talk)17:44, 25 October 2025 (UTC)[reply]
I would say I am neutral on it, butleaning support (both sides make great arguments). I feel like K should be a separate proposal altogether, though, instead of being lumped with the rest of the options. And to be honest, I need to rewrite my !vote so I'll probably do that later.fanfanboy(blocktalk)17:52, 25 October 2025 (UTC)[reply]
Support B, D, E, & I. Vote threshold should be increased to 50 and time limit reduced to 14 days. Sometimes, I'm a bit wishy-washy regarding an admin I barely know, but at the same time not wanting them to get recalled until I get all the facts. "I" for "inactivity" per WhatamIdoing.Oppose A & J at all costs. The process has so many flaws yet it prevents messy and long ArbCom cases.Mox Eden (talk)09:53, 22 October 2025 (UTC)[reply]
Support A/Open to E to 2 weeks/Oppose All Others I think the process is working relatively well. As someone who was in an extended dispute resolution, the this can be a stress in real life. The tensions is likely even higher here both because the admin obviously didn't initiate the effort and it's really a waiting game as the signatures get added. I'm open to shortening the window to two weeks but, based on how quickly the petitions have been signed, I'm not sure this would make much of a difference in practice. -RevelationDirect (talk)10:47, 22 October 2025 (UTC)[reply]
Support Change in Petition process. No I do not think the 25 deciders survey is working, see selection bias. To me this present process should be similar to a 'motion to call the question' or a 'discharge petition' with a majority or slight over majority to succeed. We should not silence one side in this process, when we are doing this to one person, or force one side to be bystanders (see bullying). And if we want an esteemed group of users to decide, we should create a board, not this.Alanscottwalker (talk)11:26, 22 October 2025 (UTC)[reply]
Support A, otherwisenot opposed to B on the condition that by allowing an Endorse option it doesn't negate or change the petitions requirements itself; it is only in an attempt to influence editors not to sign, if there is strong support for the admin being recalled, effectively grouping these supportive comments from the general discussion to it's own section below signatures. So regardless the petition still functions on a signature basis per A and not broken. As for more/less signatures and more/less time (C-F) I see no basis for changing this. At present all recalled admins have not succeeded in passing an RfA, therefore we don't know yet if we need to extend or shorten either requirement. In response to J, admins shoulddo better at finding suitable candidates now we have streamline prcoesses for adminship via the elections. Abolishing recall, when it hasn't functioned incorrectly yet (bar one withdrawn petition) is simply too soon to consider, we'd need a documented pattern of problems to justify that. In reality for every recalled admin there is probably a dozen suitable candidates for election.CNC (talk)12:54, 22 October 2025 (UTC)[reply]
Support D, E, G, and/or H. The process needs to be more deliberative and less subject to responses by a small faction of the community. -Donald Albury13:57, 22 October 2025 (UTC)[reply]
Support G & H, oppose A & J:Mz7 hits the nail on the head with regard to the balance of power in the process -- the petitionis the desysop, and we should move that power to the RRfA.Separately, I think exploring a change to the petition structure would be worthwhile; maybe something like having support and oppose in the petition and requiring it to reach a net support number within the seven days (say 25). Many admins are resigning instead of running RRfA, and I think that's a failure of the petition: we should try to make the it a better barometer of whether an RRfA has a chance of passing or not, rather than just a formality.Giraffer (talk)14:47, 22 October 2025 (UTC)[reply]
Support B outright and D &/or E, and possiblly G I'm not altogether happy with any of the recall petitions we've seen so far; as with rather too many things here, it seems too much like a pile-on with not much incentive for discussion or deep thought. AsGiraffer says above, the numbers of admins resigning is a failure of the process ~LindsayHello15:25, 22 October 2025 (UTC)[reply]
Support G & H, and in particular I supportUser:Mz7/How to fix administrator recall § Proposed solution.If this fails,support B by requiring that recall petitions remain open for the full petition period of 30 days (or however long the time period eventually is) and allowing signaturesagainst recall to subtract from the 25 signatures needed to initiate a recall. Best,KevinL (akaL235·t·c)15:36, 22 October 2025 (UTC)[reply]
Support D and E, oppose B, G, H I, strong oppose J. I agree with people supporting A that overall recall has so far worked very wellin practice, no matter its flaws people are pointingin theory; getting rid of the process altogether would be unthinkable to me. I do think though that 30 days is way too long, 14 days would be much better, and that 25 signatures is not enough relative to the size of enwiki, where 50 would make more sense (I would like be fine with any amount higher than 25 in case ofWP:BARTENDER close). Regarding formal supports, I agree with every opposer of B: completely counterproductive and against the very logic of starting with a petition before aWP:RRFA (informal expressions of support in other places to the admin concerned already happen and are obviously fine). Any other complication of the process at petition or RRFA stage to me is currently unwarranted and potentially harmful.Choucas0 🐦⬛⋅💬⋅📋15:47, 22 October 2025 (UTC)[reply]
Support A as this relatively new process appears to be working ok. Personally I avoid discussions about individuals' conduct but this process appears to be working, judging from the table atWikipedia:Administrator_recall/Lists#Closed_petitions. Were that to be showing churn around recalls and successful Re-RFAs I might take a different position, but it looks fine for the moment.AllyD (talk)19:27, 22 October 2025 (UTC)[reply]
You seem to be saying that everything is working fine because administrators are being recalled, without looking to see whether you agree those administrators should have been recalled, nor even attempting to engage with the lack of re-RFAs (and hence lack of successful ones) being one of the problems? This is only half a step up from "I haven't looked for any problems, therefore I can't see any problems, therefore there are no problems", which is obviously fallacious.Thryduulf (talk)20:56, 22 October 2025 (UTC)[reply]
Support J, alsoSupport D -The purpose of a system is what it does. This process is not a recall system. It is a 25-supports-means-desysop system. If that is what people in this community actually want (and it is what this process does) then it is a different community to what I thought it was. Even if we areWP:NOTAVOTE, it's goes against plain logic to have a system that is always a one-and-done process where no opposition to the motion can be heard.
I fully intend to bring a closure motion at the next recall "petition" (it'e not a petition, it's a vote) that is as palpably pointless as the one brought against Night Gyr. I hope people will support it.FOARP (talk)21:13, 22 October 2025 (UTC)[reply]
EDIT: I'm also OK with the adminship-revocation-request process discussed, and literally anything that would reduce the mob-justice nature of this system.FOARP (talk)08:22, 23 October 2025 (UTC)[reply]
It is a 25-supports-means-desysop system.: Well, it's only a desysop if the person being recalled doesn't take up the RRfA. If they aren't going to pass the RfA even with the reduced threshold, recall has done its job.
No-one is taking the RRFA. And why on earth would they even try?
This system was imported from DE wiki without any real thinking about how it would work in a a system where RFA is an “are you spotless and perfect?” test and there’s a massive “no smoke without fire” mentality.FOARP (talk)05:38, 23 October 2025 (UTC)[reply]
Maybe I should use "if you can't stand the heat, get out of the kitchen" instead, which as heartless as that may sound is the unfortunately consequence of being an admin, and more or less how admins responded when recalled so far. Other editors might start a petition against you, heck you might even have to go through an RRfA to retain the bit. I'm not really judging this as good nor bad, but rather the fate of having elevated privileges among a large community. It comes with heightened accountability so yes there will be collateral damage, but no this hasn't occurred yet.CNC (talk)12:46, 24 October 2025 (UTC)[reply]
Support E (~2 weeks),D if not E, and potentiallyG per Mz7's proposal or something like it. Petitions to date show that getting 25 signatures within a day is possible in some cases, but it can sometimes take much longer. A shorter window would expedite the process, which I think should be to everyone's benefit, while weeding out the more marginal cases. I favor Mz7's proposal overall, but consensus to implement something new like this has proved extremely elusive in the past. While we're at it, making RfA more tolerable might help addressAdministrators who could pass RRfA may choose not to try. Anybody else getting deja vu? —Rutebega (talk)21:47, 22 October 2025 (UTC)[reply]
Support A, This vote is purely from an anon user who mainly reads Wikipedia and looks at the behind-scenes stuff from afar so feel free to revert/disregard it. I support the current system as is and believe it finally gives regular users a means to rectify admins who have gone off the rails without having to go through endless threads on ANI or a torturous Arbcom process. Honestly, looking at the recall cases so far, the only questionable one I would say is Night Gyr and even then, for an admin who so little uses the tools, the aftermath is negligible either way. Cheers.115.64.183.57 (talk)00:22, 23 October 2025 (UTC)[reply]
Splitting my !vote into multiple bullet points for clarity:
Support A Honestly, if no change were to result to recall, I think I would be fine with how this processes works, although any process can be improved. I don't believe recall is "flawed" in the negative sense, more like "imperfect" as in "nothing is perfect but that's ok" and I can get behind some of the proposed improvements to the process, as expressed in my !votes below.
Comments on B I think having editors expressing support should be allowed on a petition, but I strongly oppose having those votes be counted against those signing a petition or for there to be consensus for the petition to succeed. I see the petition as a way to raise an issue with an admin's conduct. If we are dealing with an admin who has popular support from the community, I am concerned that any users raising concerns of misconduct might get drowned out by those who preemptively support the admin without carefully analyzing the evidence that is cause for concern, leading to those concerns being buried. I think the following RRfA should really be were consensus is necessary for any desysop to occur. Now if the signature requirements were dramatically lower, as suggested by Barkeep, then I could somewhat see myself supporting B as getting a net of 5 signatures should be easier than 25. CNC's !vote about option B is more in line with what I expect for this option to take effect.
Weak Oppose C, Support D 25 signatures feels too low and can be gathered fairly quickly. I remember having an intention of signing a recent petition, only for it to reach the target before I could have a chance to get on my desktop and log in. I would support raising it no higher than 50 signatures, that way we not doing more than doubling the requirement, although I'd also something in between 25 and 50 like say 40 which would be my preferred target to have. I'd be fine with 30, but I'm not sure if the 5 extra signatures that are required will cause any impact.
Support E, Oppose F 30 days is also too long, petitions are ending far sooner than that. I think we should lower it to 14 days, roughly half the current time of the petition phase, and if its still too long we can consider 7 days, but not any less.
Open to G, Support H I would be ok with a RfDA process as laid out by Mz7 in place of a RRfA (with the caveat of 50% support instead of 60%), that way we really do need a consensus to desysop instead of the petition actually being a de-facto desysop which I don't think was the intent.
Strong Oppose I.a (as proposed by Tamzin) I really don't think limiting signatures to 90 day intervals is a good idea. This is far stricter than the 5 simultaneous signatures requirement, what I.a would mean is that if two petitions are ongoing (which as far as I can tell hasn't happened or isn't common, yet should still be planned for just in case), users would have to choose which of the two petitions to sign, and depending on the conduct involved, that comparison of the two situations might be too complex to decided and may lead to an over correction of discouraging participation of petitions. I could also see a scenario of someone signing a petition for what might be conduct that falls just below our standards, but then another petition within the 90 days starts for conduct that isfar below expectations, and that could lead observers wondering "why would this user support a recall for conduct that frankly wasn't that egregious, and yet they wouldn't support a recall for this other unacceptable conduct?"
Strong Oppose J Having a community check on admins is important to ensure admins are responsible for their actions, and I don't think the current is failing at all, let alone at the level that warrants scrapping it altogether.Gramix13 (talk)00:31, 23 October 2025 (UTC)[reply]
Strong Oppose K To topic ban admins from recall RFCs should only be done if there's evidence of disruption, and I don't really think I've seen any strong evidence for this. I wouldn't even classify this RFC as evidence to assume good faith of all participants. This would also be a fairly wide net to cast for such a topic ban. We also have admins participating in the recall petitions themselves, and these can be very important voices to hear about the concerns raise about an admin's conduct to give validity to the complaint. So taking away their ability to give input on a process they participate in, to me, goes against the collaborative spirt we are trying to build here on Wikipedia by having a topic ban rooted in distrust over a wide category of users (the admins) who are all guaranteed to disagree about what's the best way to recall an admin for misconduct.Gramix13 (talk)22:12, 25 October 2025 (UTC)[reply]
Support J all the way. Theextreme deontological attitude that the Wikipedia community has for some reason adopted has already cost us enough good admins who lost the bit for making a few missteps that were greatly outweighed by all of the hard work they've done on balance (such as Kudpung, RHaworth and Athaenara), and that waspre-recall. Suffice to say that it was already far too easy to get desysopped before this absurd policy was pushed through. And for the record I am not licking admins' boots; what I have said also goes for any other editor who has butted heads with the Wikipedia community at times but is mostly a hard worker whose contributions are a boon to the project.Passengerpigeon (talk)01:03, 23 October 2025 (UTC)[reply]
I strongly agree withBarkeep49's comments in the opening vote, notwithstanding my strong opposition to arbcom being the only route for desysop. (For various reasons, high among them that it takes a very high level of know-how for someone to successfully launch an arbcom case, combined with my belief that the people most likely to be wronged by admins are the ones least likely to have the knowledge of how to challenge them.) Therefore, to my great surprise, Istrongly Support G. AN threads against admins being shut down prematurely has bothered me for some time, both before and after I became an admin myself, and I thought that the recall petition would be a useful counter to that problem. However, far from being a backstop against frivolous recalls, petitions have ended up becoming thede facto desysop action in itself. Consensus, or at least strong support, in an AN thread to begin a "request for desysop" seems to me a much better approach than the simple vote-based petition we have presently. However, I still worry about AN threads against admins being shut down prematurely, and so would recommend some limits on closing threads, eg, "if someone has started a subthread proposal with intent to desysop, the thread cannot be closed within 24 hours". Similarly, Istrongly Support H, following the general gist ofMz7's "request for desysop".Oppose B as written; if we're doing supports during the petition phase, what we're doing is an RRFA - let's just go straight to RRFA then, and get it over with.Lukewarm on C, D, E, F. I don't really think that tinkering with these particulars will significantly change how this works, but I wouldn't oppose it. However,Support I, in the sense that if we retain the petition system, we ought to address the issues raised byCryptic in the discussion below.Outright Oppose A, J. --asilvering (talk)02:35, 23 October 2025 (UTC)[reply]
Support E, I, H, and maybe D. My preferred solutions are: 1. Recall petitions should last a week, or at most 14 days. The current period is too long. 2. A recall petition must stay open for the full duration regardless of how many signatures it has received, unless the recalled admin requests it be closed early after reaching the threshold. This would encourage greater engagement from the admin being recalled and encourage apologizing and making amends. 3. Previous discussions on the admin's user talkand at a noticeboard (AN or ANI) must be a requirement, and they must both stay open for a certain minimum duration (I'd prefer 7 days and 3 days each). We have a bad habit of closing noticeboard discussions against admins early, forcing people towards recall when that is not the best solution. 4. I think RRfAs should be required to reachconsensus to desysop rather thanno consensus to remain as sysop, per Mz7. This means a majority in favor of desysoping. 5. I don't think we need to raise the number of signatures required, but we need some kind of activity requirement for petition-signers per Cryptic below. 6. We may want to exclude activity alone as a reason for recall. Perhaps this is better phrased as "require evidence of misconduct" 7. We could look into shortening the immunity periods, also per Mz7, though as they have not been an issue yet I'm not sure if that's necessary. 8. I would also support GLL and co.'s idea below, that the lower RfA thresholds should be valid for a longer period (6 months?) after a recall petition, to encourage recalled admins to reflect, improve, and come back. tldr; per Mz7.Toadspike[Talk]06:50, 23 October 2025 (UTC)[reply]
J as first preference, followed byD, E, H and I. As others state, a recall is at present ade facto desysopping. It is very easy for someone who does admin work in contentious areas to attract 25 detractors. As such, the existence of recall as-is exercises achilling effect pushing admins away from doing contentious work. We also don't need people bringing into recall their own personal inactivity standards as an end-run around gathering consensus to change our existing policy. Accordingly, my preference is to move away from recall completely as a failed experiment, but if we must keep it, then the following changes would be appropriate.
The majority of petitions initiated to date have hit 25 within a day or two. The current structure promotes haste over thought, pile-on over discussion, numbers over consensus. Therefore, the process should change to separate the moving of a petition from gathering of support. I would be in favour of athree-day hold: discussion only from when the petition is commenced, and only after 72 hours can signatures be added. This would allow for rational thought and consideration, as well as the recallee being given a fair chance to be heard.
A recall shouldn't be a first or second step, andproper engagement on talk page and AN should be a prerequisite.
To make sure that there is real community support for the recall,raise the number of required signatures to 50.
For similar reasons,RRFAs should require consensus to demote, not a lower consensus to retain the bit.
The availability of an admin election is a lottery at present depending on when a recall starts. To remove this, the lower re-election % required should be offered to a recalled admin standing at admin election within the 6 months after a recall closes successfully. (The recallee would not retain sysop status during that time.)
Also fine with the Mz7 proposal and similar. I would prefer change to no change, and would not want the good proposals to die for no consensus over which of them to enact.Stifle (talk)09:44, 23 October 2025 (UTC)[reply]
Oppose C, F, J. Given that there has never been a petition which failed due to not reaching the signature threshold in time, I don't see any particular reason to lower the signature threshold or increase the time needed. Only one petition lasted for longer than two weeks, six of ten closed within 24 hours and one more closed within 48 hours. I'd be open to seeing the threshold raised or the time limit lowered. I'm not opposed to some other process being developed, but without seeing what alternative process the community could agree on nor am I going to supportG. I don't see the point of B: if editors want to encourage an administrator for whom a petition is currently open, they can do that on their talkpage; turning the petition into a !vote is just duplicating the work which would be done in the RRfA. I'd potentially be open to scrapping the two-stage process entirely and just having the RRfA.Caeciliusinhorto-public (talk)09:48, 23 October 2025 (UTC)[reply]
Support A Process has worked well. Fram has expressed my personal thoughts quite well. At most go a bit shorter in time but change nothing else. It's there to say "hey, enough people think there may be an issue we need to see if the rest of the community thinks you should retain the bit.spryde |talk13:01, 23 October 2025 (UTC)[reply]
Support A, mostly. I just wish people wouldn't jump on it quite so fast. The recall opens, people sign it quickly, recall closes. I'm sure the signers aren't just signing willy-nilly and have fully considered it, to be clear. But maybe people feel like, if they want to sign, they have to jump in quickly before 24 other people beat them to the punch. I don't know. But perhaps there would be some value in codifying a minimum time. Something like "The recall will be open for 48 hours or until the signature count reaches 25, whichever is longer, and will be closed as unsuccessful if 25 signatures are not reached in 30 days". People know they have seven days to comment on an RFA, so they don't feel rushed. Might be nice to get some of that "rushed" feeling out of WP:RECALL. Probably still a good idea to cap it at 25, though.Useight (talk)13:16, 23 October 2025 (UTC)[reply]
I suggested a little above that a hold, or discussion period, of 3 days should be in place between the creation of a recall petition and anyone other than the creator being able to sign it. What would you say that that?Stifle (talk)13:21, 23 October 2025 (UTC)[reply]
My understanding is that a community noticeboard requirement is not currently a hard requirement, and attempts at prior dispute resolution is a best practice. One of the things Mz7's proposal does is change this from a best practice to a requirement that there be a recent adverse finding against the admin at a community discussion.Tazerdadog (talk)13:56, 23 October 2025 (UTC)[reply]
Tazerdadog's understanding is correct. Any extended-confirmed editor can start a petition against any administrator for any reason or no reason, with or without prior discussion, as long as it is not within 12 months of a (re)RFA, admin election, them being elected to Arbcom, within 6 months of a previous petition and the user has signed fewer than 5 currently open petitions. The administrator does not even have to have recently edited.Thryduulf (talk)14:20, 23 October 2025 (UTC)[reply]
Hmm, I'm not sure about a discussion period. Might devolve into three days of people just ragging on the person and now (s)he has to dread all the imminent signatures that will land the second the discussion period ends. Might work if we do it right. Clearly we want a mechanism for de-adminning people, but I want it to be as tasteful as we can. A person has been volunteering their efforts for some amount of time, hopefully doing their best, so it'd be nice if we could make the exit graceful instead of demoralizing.Useight (talk)22:45, 23 October 2025 (UTC)[reply]
Support D, E, G, and/or H. There has to be a way to retain a community-driven recall while better supporting admins working in areas that are contentious or have policy ambiguity. My preference would something along the lines of Mz7's suggestion (see also Toadspike), where a key change seems to be "RRfAs should be required to reach consensus to desysop". I'd also like to see changes to the petition in this case (increase signature count, reduce time period).NicheSports (talk)16:01, 23 October 2025 (UTC)[reply]
Support B, D, GNeutral on A but with the caveat that I'm not really sure that we've actually had enough discussions yet to be doing more than guesstimating here... It could in fact be the case that nothing is broken even if improvements can be made.Horse Eye's Back (talk)16:09, 23 October 2025 (UTC)[reply]
Support H, and failing thatD orJ. In my view, 25 signatures is an inappropriately low bar for desysopping someone, and the recall system should not be retained in its current form. Rather, before removing any user rights from an admin it ought to be necessary to establish a regular community consensus for this, and no rights should be removed until it has been shown not only that there are 25 or more users who think that this should happen, but also that this is the consensus view. I would be in favour of replacing the recall petition with a discussion which follows our normal consensus-building norms, which runs as long as it needs to until a consensus can be established, and which involves participation equally from those in favour of the desysopping and those against it.Dionysodorus (talk)17:17, 23 October 2025 (UTC)[reply]
Neutral - I'm neither running for administrator (I'd never get enough support), nor seeking to recall an administrator. PS - Let me know, how this RFC turns out.GoodDay (talk)18:56, 23 October 2025 (UTC)[reply]
Support A broadly, with some tepid support forE. I think you can argue the overall period is lengthy enough to be unnecessary based on the real-world recalls that have occurred. But otherwise, I'm not seeing the point of process tweaks. If people actually have case examples where they think there was a miscarriage of justice beyond the aforementioned, that would be instructive, but I don't think the cases described are examples of recall failures.Der Wohltemperierte Fuchstalk18:58, 23 October 2025 (UTC)[reply]
Support A. I believe the process is working well and as intended. I'm disappointed in the number of admins who are arguing to neuter the process in one way or another. Accountability is a good thing. ~~Jessintime (talk)00:16, 24 October 2025 (UTC)[reply]
Support A or E. I have yet to see an argument against the current system that I find convincing. It does well to remember that adminship is a privilege, not a right. If the community opposes someone being an admin, the deciding factor shouldn't be whether they already have the tools. If you are worried about the number of admins, then the solution is to recruit more editors and grow the editor base. That's a far more important conversation to have than recall, but editor-growth discussions aren't nearly as dramatic or exciting and don't get the same turnout.Thebiguglyalien (talk)🛸00:52, 24 October 2025 (UTC)[reply]
A: When reviewing the recall results so far, the system appears to be working as intended, and I have seen no indication that it will fail to keep working as intended in the future. The current requirements are reasonable for demonstrating adequate concern to require an RRfA, and the RRfA process is reasonable for demonstrating if the broader community still has confidence in an admin. I don't believe the addition of futher bureaucracy, in the form of prerequesites or otherwise, will benefit the process. Oppose any change.fifteen thousand two hundred twenty four (talk)02:18, 24 October 2025 (UTC)[reply]
I'd like to proposeOption K: topic-ban administrators from initiating or !voting in any RFC to amend the recall process. This is the umpteenth discussion where the large majority of participants who support abolishing recall (or amendments that effectively accomplish the same) are administrators, with the majority of non-admin participants finding the process to be working well. I believe the administrators in this discussion are participating in good faith, but allowing a single user group -who represent less than 1% of active Wikipedia users - to overrule a community process meant to held them accountable isaterrible look. Admins need to recognize that they areWP:INVOLVED participants and recuse themselves from these RFCs and if they will not do that, the community should do it for them.2601:540:200:1850:F43C:C448:7974:22BD (talk)04:08, 24 October 2025 (UTC)[reply]
If administrators are <1% of active users, then they'll easily be out!voted by the other 99%. But considering there were multiple admins who signed the most recent recall petition, I don't see why their input is any less valuable. Recall benefits admins too (one bad apple yadda yadda yadda).Nil🥝04:39, 24 October 2025 (UTC)[reply]
By the nature of their work and the project space pages they frequent, admins are more likely to be aware of and !vote in wiki process discussions than a typical active user, so they generally make up a disproportionate share of !votes in process-related RFCs. This is mostly fine - there is plenty of viewpoint diversity among the admin corps on other issues - but it becomes a problem when admins are disproportionately participatingand favoring one side of a debate, across many different discussions. In theWP:BADLOOK RFC I linked above, 30 of the 89 RFC participants were administrators, who overwhelmingly (73%) !voted to make recall more difficult by reducing the petition period to 7-14 days (similar to option E above).2601:540:200:1850:F43C:C448:7974:22BD (talk)05:10, 24 October 2025 (UTC)[reply]
To be clear - I do not mean to imply that admins are intentionally coordinating their !votes here or in other recall discussions. However, I do believe that admins, as individuals, are more likely to oppose the recall process and are more likely to support changes that make recall more difficult, which affects the !vote balance in these RFCs which may not represent a broader community view about the proposed changes.2601:540:200:1850:F43C:C448:7974:22BD (talk)05:21, 24 October 2025 (UTC)[reply]
SupportOption K in addition to my vote above supportingOption A. I note thatOption K allows admins to participate in recall petitions--it just prevents them from starting RFCs to gut or remove the process.AugusteBlanqui (talk)07:49, 24 October 2025 (UTC)[reply]
Support A With no prejudice to a shorter timescale and more signatures. I have never liked that there is no 'support/oppose', but note the process has not so far failed. BestAlexandermcnabb (talk)05:49, 24 October 2025 (UTC)[reply]
Support A. I'm not saying that there is no reform that might be worthwhile, but the evidence that there is any problem is very thin. A whopping 1% of admins have been recalled in the first year of the process. More than three times as many have had their admin access removed for inactivity in the same period. In neither case is this evidence of a problem with the process of removal. If recalled admins were routinely winning subsequent RRFAs or admin elections, thenthat could be an indication of a problem with the recall petitions. But that isnot what is happening. --RL0919 (talk)07:47, 24 October 2025 (UTC)[reply]
Support A. Something tells me that certain people are feeling awfully miffed that despite all the hemming and hawing, the recall process has yet to produce a single clear miscarriage of justice. Now it's down to theory-crafting about the RRFAs that might have been, tsk tsk...Dr. Duh🩺 (talk)12:25, 24 October 2025 (UTC)[reply]
Support G/H/I What we seem to have wound up with is a weird mash-up of the dewiki process and enwiki processes, which has lurched along without going off the rails yet (dispite the multiple discussions overWP:INACTIVITY it spawned) but I can't say it really seems to be working "well". I see multiple proposals in the discussion so far that I think worth exploring.User:Mz7/How to fix administrator recall is one: if we're going to have an enwiki-style discussion, let's do that from the start instead of having what's effectively an oppose-section-only pre-RFA. Or we could go the opposite direction by returning the petition to "We the undersigned believe it's worth asking the question whether this admin still has the trust of the community" withno discussion, only signatures, and have the actual discussion if the petition passes. And then probably still change re-RFA (and RFA itself, for that matter) to be less emotionally driven, but that's a long-standing intractable problem.Anomie⚔16:22, 24 October 2025 (UTC)[reply]
E as first choice. I agree with others above that in our highly active community, 30 days is a long time to leave a petition open. My gut feeling is 7 days (the length of an RfA) is an appropriate timeline. 3 of our 10 recall petitions took longer than that to accumulate 25 signatures, though that includes the first two petitions when perhaps there was some hesitation to engage in the new process. I'd also support shortening the window between petition and Re-RfA to 7 days. All that said, long petitions are rare (7 of 10 closed within 48 hours) and re-RfAs rarer still (1 in the books; 1 on the way) so I'm also content if we stick withA and let the process continue to run.Ajpolino (talk)02:18, 25 October 2025 (UTC)[reply]
Support A, mostly - There has been no evidence that there is any problem, and as such no changes need to be considered at all.Interested in K - not necessarily ready to support this outright at this point, because I don't necessarily agree that admins should be removed from discussions about changing recall just by virtue of being admins. However, there is a big problem with how admins are coming and acting like their personal fear of recall is a problem - it's not. To be quite blunt, if you're scared of getting recalled for taking an action, then it's probably not an action you should be taking unilaterally and without prior discussion in the first place - or at aminimum it's an action you should immediately take to a noticeboard for wider evaluation and discussion. I furthermore highly, highly doubt any administrator is ever going to be recalled for one or even a few controversial/borderline decisions - especially decisions that there was clearly a reason to "shoot first, ask later" - as long as they appropriately seek others' opinions at a minimum after the fact, and abide by the consensus of that discussion. And if they are recalled anyway, they have a high chance of passing a RRFA if they still hold the trust of the community.I could see a reduction of the recall timeframe to 15 days (option E) - but on one condition - that there is some manner in which to extend that 15 days if it would be warranted. A couple cases in which I could see it being warranted is if the recall was started early on in a community discussion about an admin or an action they took, and that discussion is still going on at the end of the 15 day period. The community shouldn't be "penalized" in my opinion for starting a recall petition early in a discussion process, which is what would happen if it's shortened significantly, and is why I can't support anything shorter than 15 days. I'm also not sure how the extension would best work - I guess the easiest way would be that any user (whether they are supporting the recall or not) should be able to request the bureaucrats to determine if the recall should be extended and for how long, but I appreciate what others have said about adding more tasks to them that they may not be willing to do.Alternatively, what about allowing earlyclosure in lieu of shortening all petitions by default? I am imagining this would be something like "if discussion of the administrator's actions on any noticeboard have died down, and there have been no new supports for the recall in the last 24 hours, the recall should be closed as unsuccessful". The problem I see with this (and why I'm not proposing an actual additional proposal yet) is that "died down" is vague. But that may be beneficial - since many discussions don't ever end up getting formally closed at all, so it would enable whoever gets this ability to early close to determine whether discussions have died down to the point that more time is not necessary. This, in my view, would help - it'd remove the "sword" hanging over the admin for 30 full days (barring withdrawal) even after the community has finished discussing them, while also not shortening from 30 for instances in which people are holding off supporting (or deciding not to support) pending further discussion in those discussions and/or further review of other actions.Almost done here,fine with option B - I can't really say I'm massively in favor/support for it, but I wouldn't mind it - so long as it's just a way for editors to show their support for the admin/opposition of the recall and it doesnot increase/change the number of votes to recall that are required to force the RRFA/election. Specifically allowing support for the admin in the recall vote phase would basically remove all arguments of "but the admins just resign cause they don't know how many people support them so they don't even bother RRFA". If an admin is recalled, gets the 25 votes, but also has 50 editors who've shown up expressing that they'd support an RRFA if it becomes necessary, then there's no valid argument that the admin didn't want to bother with it because they didn't know they had support. If the admin in this case still chooses to not run for RRFA, that's their right.Lastly,fine with option H so long as the changes made are to make it less of a "gauntlet" for the admin. Two changes I could see myself supporting are potentially a slight reduction in the minimum standard to keep the bit at RRFA/election, and allowing the administrator to postpone the RRFA/election for a decent length of time (or indefinitely) - in other words allow them to delay it but keep the lower standards for keeping the bit when they do eventually run - but they will lose the bit in the meantime. This would, imo, alleviate the concerns that admins feel "rushed" to decide and to form their statements/etc to run RRFA in the allowed timeframe. It would also further mitigate the issue of "admins form enemies by virtue of their duties", i.e. a slight reduction (ex: to 50% being sufficient and 40-50% being crat chat) would mean that people who havealmost half of the !voters' support still have a chance to retain the bit if the crats feel that, after discounting vendetta-type !votes, they should retain the bits.Hopefully this all makes sense and gives some food for thought. I'll try to respond if anyone has questions for me but I'm very, busy IRL right now. If anyone feels that this would be better formatted/understood as bullet points or something please feel free to change this from paragraphs without checking with me first. Regards, -bɜ:ʳkənhɪmez |me |talk to me!05:06, 25 October 2025 (UTC)[reply]
Support B & E To an extent, it feels like admin recall has become a bit of a space where wedge issues with one person can remove an otherwise-acceptable admin. Having a space for support & shortening the time can remove some of the bias against admins.JuxtaposedJacob(talk) | :) | he/him |05:08, 25 October 2025 (UTC)[reply]
Support A and K. Surely if there was even the remotest truth in the claim RECALL has been used frivolously, maliciously, or has some structural flaw, we would have already seen one if not more of the successfully recalled Admins go immediately to reconfirmation and pass easily. It surely has to be because, in all cases, issues were identified that can only be rectified with a sustained period of editing as a mere editor. And the people recognizing that fact most clearly, are surely the recalled Administrators themselves. It certainly doesn't remotely hold water that they would just be too busy, too scared or too jaded to do such a thing. They can certainly claim they have too many enemies, but surely if they're not willing to even stand to see if their enemies can pull the wool over everone else's eyes in the forensic environment of RfA, we're entitled to view that as merely an excuse. And if they're refusing to do it just to teach Wikipedia a lesson in what they've lost, well, good riddance to bad apples, and no reason to think RECALL isnt working as deaigned there either.Gordon Maximo (talk)10:30, 25 October 2025 (UTC)[reply]
Support G per Mz7. In particular, I agree with his observations that desysop happens at the point of cetification; that a petition can be signed without argumentation; and that RfAs are prepared for, but RRfAs cannot be.Arcticocean ■13:03, 25 October 2025 (UTC)[reply]
Support A because it seems to me like it's working as intended. If A fails, a distant second would be Mz7's proposal, although I'd rather have it at 14 days instead of 7. Also,weak oppose K since I don't think it's fair to remove the opinions of admins from the equation just because they are admins, and it IMO is against the spirit of Wikipedia. If there is any actual evidence that admin participation in these RFCs is causing problems, I'd be willing to reconsider. Also, I don't know if an option added so late in the RFC can get consensus here, and it would probably need a different RFC.QuicoleJR (talk)16:55, 25 October 2025 (UTC)[reply]
I believe that admins participating in these RFCs is causing problems because, unlike a regular RFC where policy-based !votes are weighted, an RFC tochange Wikipedia policy is much closer to a straight-up headcount.
By my count, there are 90 editors who have !voted in this RFC so far (33 admins and 56 non-admins). Option A is supported as a first choice by 34/56 non-admins (61%), either alone or in combination with other options. If this RFC were closed based on non-admin input it would be a consensus for A. However, administrators have overwhelmingly voted against Option A, with only 6/33 admins (18%) supporting. They account for the majority of !votes to weaken or abolish recall despite admins representing less than 1% of active Wikipedia editors. Their participation is probably enough to shift the close from a consensus for the status quo into at least 'no consensus' territory.
I understand why people are saying that admins should have some voice in this discussion, but they shouldnotbe able to dictate the outcome by sheer force of numbers which is what is happening right now. The structure of the RFC process stacks the deck in favor of admins who want to amend or abolish recall and I suspect this is the main reason it took 15+ years for the community to adopt such a process in the first place.2601:540:200:1850:CC47:61C6:19C6:6028 (talk)22:23, 25 October 2025 (UTC)[reply]
I support E (shortening the recall period to any period in the interval [7 days, 15 days], inclusive) and D (raising the number of signatures required; I am agnostic on the precise details and would like to be counted as support for whatever number here might gain consensus); I oppose A, C, F, and J. Independently, I support Mz7's proposal (whatever letter than stands for). --JBL (talk)17:34, 25 October 2025 (UTC)[reply]
Support G My feelings are similar to the ones expressed by Barkeep and Mz7, I agree with Mz7's observations. I think RECALL should serve as a small barrier from frivolousness before a full community decision should be reached and not an already condemning vote. Additionally I think that every admin how has done a tough decision such as a large RFC close or the likings will have 25 people unhappy with their judgement and still admins can and should be making tough decisions and should also be able to feel comfortable doing so. I also support Mz7's proposal to change to an RfDA, if the outcome is "no consensus" an admin has not lost the trust he earned in my opinion.Squawk7700 (talk)00:07, 26 October 2025 (UTC)[reply]
Amendment: A loose idea just formed in my mind and I'm not sure at all that it could work but I want to share it anyways. As stated above in my opinion the RECALL should be the first step just making sure no frivolous stuff happens that forces an admin into a long painful but totally unnecessary process. Also as stated above, I think one will find 25 opposers for every active admin. So the idea was something along the lines of, someone could propose/nominate an admin for RfDA/RRFA and it automatically happens unless X people oppose the nomination. This would allow for Supports without having to have a kind of pre-rrfa. But of course I this could run into the very same issue; one could find X supporters for any admin which would be a lot worse and I have not yet found either the right number of voters or another way to prevent this.Squawk7700 (talk)00:15, 26 October 2025 (UTC)[reply]
I appreciate the attempt at brainstorming ideas on alternatives to our current petition system, but I don't believe this one will work out for the concerns you mentioned. I'd prefer always having 25 supports bringing an admin to RRfA where we as the community can judge the complaints being made than to have 25 opposes blocking any attempts at recalling an admin for misconduct. I'd much prefer having a direct RRfA over an opposition-based petition (i.e. what you are suggesting here), but that runs the risk of frivolous recalls, hence the need for support-based petitions (i.e. our current if imperfect system).Gramix13 (talk)00:34, 26 October 2025 (UTC)[reply]
I don't think that's necessary at all, I don't see any ill will from your proposal and I didn't intend to comment on it as entirely negative. Ideas that don't work in brainstorming may lead to ones that do, so keeping this thread here might be helpful for anyone looking back at this RFC in the future. WP:MUTUAL, in my reading, is forunproductive comments like incivility, and I think there's something productive that can still be gleamed from this even if it doesn't work out (yet).
And in case my tone wasn't clear, I don't hold any grudge towards you, the opposite is more true, I think coming up with ideas, even flawed ones, can be helpful! If you find a novel way to make this all work, that could be useful to improving recall. I hope my comment didn't come off as harsh towards you and my apologies if it did.Gramix13 (talk)00:58, 26 October 2025 (UTC)[reply]
SupportC D Generally I think the system is working well and I support it existing. However, I do think it can be improved and creating a higher number for recall would be a good idea so it requires more support from the community to recall and prevents it being a smallish number who decide on if to recall or not. I do also agree with Tewdar that alerts should be sent out to the communtiy for recall petitions like RFA do. I also would support removing the 5 sig limit(which I believe Tewdar also proposed.) All editors in good standing should be able to sign a recall petition not have a arbitrary limit.GothicGolem29 (talk)16:33, 26 October 2025 (UTC)[reply]
Support A We need a recall process, this one's working despite various misconceptions about it, and there's no case for making changes that would have selectively prevented any particular petitions so far from passing while letting others through.Strong oppose B: we already have a discussion section; turning petitions into votes would elevate them into RRFAs/AELECTS, meaning that any single ECR editor could by initiating a petition launch an immediate full-scale vote on the admin. (It may be instructive to note that the recall process for the UK legislature is similar to our current process, in that an election may be triggered by a petition, but petitioning is not a process of voting for and against.)Strong oppose C and E: so far there's no need to make it easier to recall.Mild aquiescence for D or F, depending on the number tbd, but not both, but as petitions generally reach 25 in far less than 30 days there's no indication that any difference would be made by anything but an extreme amendment, or that such a change would be beneficial.Oppose G: petitioning is an appropriate process for initiating recalls.Open to hearing specific proposals for H or I, though if we have a vexatious run of fruitless proposals, we might need to call a halt to them.Strong oppose J: the community should be able to recall admins as well as appoint them and it shouldn't be seen as a lifetime appointment.Strong oppose K: admins are members of the community, many of whom have already participated in recalls in just as diverse away as Wikipedians in general, and we should value their perceptions as much as every other editor's, not disenfranchise them on appointment.A pox on RFCs with so many disparate options as this one.NebY (talk)19:21, 26 October 2025 (UTC)[reply]
A. The limited set of certified petitions show that the process is effective at filtering for RRFAs where there is a probability of desysoping. The process isn't unfair to admins, the community's just been very disciplined in starting them (save for one that was withdrawn).Mach6100:46, 27 October 2025 (UTC)[reply]
To me the biggest issue so far seems to be that a relatively small number of people with particularly strict standards can make up a sizable portion of the 25. (And I say that as someone with standards that are stricter than the median.) I'm not sure if that's yet caused any undesirable recalls—it may have hastened them, but most recalls have been so fast that I think they would have gone through anyways—but it concerns me as something that could lead to problems over time. I wonder if a good Option J here would be something like "A user may not sign a recall petition (except as initiator) if they have signed one in the preceding 90 days". --Tamzin[cetacean needed](they|xe|🤷)14:42, 21 October 2025 (UTC)[reply]
I'd endorse replacing the "sign no more than 5 concurrent petitions" clause with Tamzin's. That clause is a vestige from when we thought recall would look very different. Only concern is possible bookkeeping hell.Tazerdadog (talk)14:57, 21 October 2025 (UTC)[reply]
I don't love this proposal. It's perfectly plausible that two well-founded recall petitions could take place in the same three month period and it could well make sense to countersign both. I wouldn't want to have to engage in game theory about timings before presenting a petition.—S MarshallT/C14:13, 22 October 2025 (UTC)[reply]
The tension these seemed to come down to, in my biased opinion as a participant, is that in principle it would probably make sense to exclude apurely inactivity-based rationale as grounds for recall, but the two inactivity-related recalls so far have involved gaming the system, and it would be a much slipperier slope to exclude gaming. And while I do think there was gaming in both of those cases, if we just banned purely inactivity-based rationales, surely anyone looking to recall for inactivity would just cry "gaming" even if there wasn't any. --Tamzin[cetacean needed](they|xe|🤷)14:59, 21 October 2025 (UTC)[reply]
As a mostly non-participant, my personal (and probably also biased) opinion is that a lot of those discussions may have come down to some people thinking thatWP:INACTIVITY should cover everything, rather that being a bright-line rule likeWP:3RR is toWP:EDITWAR. Another major thread I noted was questioning the extent to which a minimally active admin (even a gaming one) is actually a problem, with the "not a problem" viewpoint holding that they're around enough to (hopefully) avoid "inactive account compromise" and they're not running into "taking action that is out of touch with current practices" because they're hardly taking any actions at all, while the "is a problem" viewpoint seemed to hold that "not using means no need" and "theymight decide to be more active without getting back in touch with current practices" (and also some "anyone who became an admin 15+ years ago is suspect because they didn't pass under the current higher standards", sigh).Regardless, the discussions do reflect some concern thatWP:RECALL as it exists is open to a small group of people forcing their viewpoint, in this case that people who want a high threshold for admin activity can force an RRFA, and if the low-activity admin decides to bother running the gauntlet at all the support may be too lukewarm for it to pass.Anomie⚔15:37, 21 October 2025 (UTC)[reply]
Regarding INACTIVITY, I currently think the policy does not fully meet community expectations, and improving that interaction would remove some of the heat-and-sound around these RECALLS. It was my intent to run some scripts to collect data. And then propose superceding the current policy with just "Inactivity thresholds require 1 admin action within the last 12 months" +appropriate checks and balances.
I find myself unclear as to whatThere should be some way of enabling supports during the petition phase means. Is "supports" meaning "support for the admin", which would effectively be "opposition to the recall"? That seems to be how voters so far have interpreted it.Anomie⚔14:58, 21 October 2025 (UTC)[reply]
I went ahead and reworded (supports --> support for the admin). Please revert if that wasn't the understanding of any participant so far.Tazerdadog (talk)15:12, 21 October 2025 (UTC)[reply]
@Tazerdadog, "support for the admin" to me sounds like "help for the admin", not "votes in opposition to the recall". I may be in favour of help for the admin, but whether I want a pre-election is a different question. —Kusma (talk)16:28, 21 October 2025 (UTC)[reply]
I was trying to make the statement as unambiguous as I could with the smallest tweak I could. There's definitely a pretty fundamental issue inside of option B on how you allow both sides to express opinions without getting a Pre-RfA RfA. I think we probably have too many !votes in now to change the wording unless there's a serious issue - if you see that serious issue though, I'd encourage you to fix it sooner rather than later.Tazerdadog (talk)16:39, 21 October 2025 (UTC)[reply]
Why no option to increase the amount of time an admin has to re-RfA after a recall? Looking at the one petition that actually ended in a re-RFA, and I think more space between "really stupid admin action" and "RfA" would have been a positive - Graham could have pointed to improvements in the way he handled issues, and the community would have had time to sit back and judge whether or not that was sufficient. For the inactivity ones, it gives the inactive admin time to either raise their activity or, if they weren't active because they were sick or had irl responsibilities, address that. Have an automatic desysop after 30 days, two weeks, whatever - but is there any reason why the RfA with a reduced pass threshold can't happen 90 to 180 days later? (Arbcom would still be around for emergencies)Main worry with increased signatures is that, assuming for every signatory there's another person who won't sign, but believes the person shouldn't be an admin & would !vote so on an RfA (based on several private conversations, I believe that's about fair), then we'd start off any re-RfA with 80 to 100 oppose !votes (using Tamzin's 40 to 50 signatures requirement) and that's not.... that's not going to go well.GreenLipstickLesbian💌🦋15:11, 21 October 2025 (UTC)[reply]
As far as I know, the short RRFA period is so admins can show "the recall was wrong" as in "it didn't represent the actual consensus of the community". If you need to improve, change, ... and thus need a longer period, then there is no reason why your success percentage should be lower than e.g. for someone who failed RFA1, improved, and has a go at RfA2.Fram (talk)15:14, 21 October 2025 (UTC)[reply]
Fully agree with the first paragraph of this. If you want to use the election in 4 months, fine. If you want to demonstrate personal growth between an ugly petition and asking for the bit back, great! That's what I'd expect a good admin following best practices to do, it also removes the awkwardness where an election isn't a real option for an admin 4/5ths of the time.Tazerdadog (talk)15:20, 21 October 2025 (UTC)[reply]
+1, This seems to be one of the most impactful changes to RECALL imo. Having an RRFA happen a longer time period after the recall petition, as well as allowingWP:AELECT an option for all such admins, would significantly decrease the temperature of the process, but still allow admins clear avenues to return.
Interesting. Yeah one of the reasons I thought the RRFA option was worth a try was the 60% threshold. I'm not sure what I would've done if I'd had the option to take it later but still be desysopped within a maximum of 30 days (because I always could've resigned at any time). My particular situation was bizarre for many reasons, the easiest to sum up here being (a) the timing, which couldn't have been worse due to long-standing RL plans in December and (b) my importer rights, which at time of writing Ishare with only one other person ... I would never have thought in a million years of bundling them with history-merging abilities (which was one of the sysop features I was desperate not to lose with de-adminship) until that possibility was brought up in my re-RFA (also seethe relevant entry in my personal Wikipedia timeline).Graham87 (talk)08:23, 22 October 2025 (UTC)[reply]
Regarding B, the solution to admins not opening RRfAs that doesn't turn the petition into an RRfA in itself (I remain surpised there is a strong feeling that it is desirable to create a system where any user can immediately start an RRfA on any admin) is to automatically open RRfAs. That does have its own downsides, which is why I presume it was not initially chosen, however some could be ameliorated. In the case that at admin might presumably not want to be forced into an immediate RRfA (we have an example now of wishing to join in the scheduled election, among other potential reasons), you could make RRfA opt-out rather than opt-in. That an admin might have to answer the RfA questions under unusual time pressure would perhaps be taken into account by voters if said answers were short or absent.CMD (talk)15:55, 21 October 2025 (UTC)[reply]
I think this idea, skipping the petition and going straight to the RRFA, is an interesting counterpoint to the people opposing option B for the possibility of it turning the recall petition into an RRFA-before-the-RRFA. Without going back to re-read the original RFC that createdWP:RECALL, I wonder to what extent the idea behind the petition was that it would be a simple check on frivolous RRFAs rather than the "just the Oppose section of an RRFA-before-the-RRFA" it seems like it has turned out to be.Anomie⚔16:17, 21 October 2025 (UTC)[reply]
Scrapping the petition stage really should be what option B is, makes it a bit clearer. If there is a petition stage, I'm not sure there is a practical difference between "simple check on frivolous RRFAs" and "just the Oppose section of an RRFA-before-the-RRFA" in terms of design, although in terms of appearance the more signatures required the more it will shift towards the latter. On the former, from the samples available 10% of the petitions have been stopped at this checking stage, and I'm pretty sure I recall at least one other that I am not sure would have made it out of that stage if further issues had not occurred while the petition was open.CMD (talk)16:51, 21 October 2025 (UTC)[reply]
I'm not sure there is a practical difference between "simple check on frivolous RRFAs" and "just the Oppose section of an RRFA-before-the-RRFA" in terms of design If we really want it to be a simple check that at least 25 people support there being an RRFA, we could forbid any discussion or evidence in the petition at all. Just signatures.Anomie⚔17:24, 21 October 2025 (UTC)[reply]
Anomie That (Having no discussion during recall petitions) was precisely one of the key components of the Original Phase I proposal, but the community rejected it in Phase II. Now that we've seen a year of recalls, the community can gauge better what worked and not, but I do believe all proposals that improve RECALL must necessarily "reduce the temperature" of the process. I think a "no discussion" option should very well be discussed.Soni (talk)00:54, 22 October 2025 (UTC)[reply]
Soni can probably offer the most insight but I suspect most, if not all, of the early proponents of what would becomeWP:ADRC did believeit would be a simple check on frivolous RRFAs. There was definitely significant discussion as to whether the discussion would just serve as a preliminary RfA but we concluded it would be better than just going straight through RfA or allowing people to make claims with no section for rebuttals. Additionally, there was some discussion as to whether signing a petition indicates 'I would vote oppose' or 'I think this should go to RRfA, even if I might support'. In practice, I suspect very few signatories have used the latter interpretation—certainly most don't vote support.Sincerely, Dilettante16:59, 21 October 2025 (UTC)[reply]
Dilettante Memory is a bit shoddy, but the petition process was indeed intended to filter out all the frivolous RRFAs in a "lower stress" setting. Admins would go through RFA afterwards anyway, but introducing a lower temperature "This admin does have concerns raised for them" check before the RRFA itself was a better approach than Arbcom or such. Hence, the petitions process.Soni (talk)00:54, 22 October 2025 (UTC)[reply]
I've done an analysis of the users signing petitions atquarry:query/98343. Of particular note, there were eight users who signed at least four petitions; twelve users with under a hundred mainspace edits this year (two with none at all, including one who signed four petitions); and one user who is currently blocked for sockpuppetry. —Cryptic16:06, 21 October 2025 (UTC)[reply]
two with none at all, including one who signed four petitions good grief. I hate to suggest minimum activity rules, but maybe we should institute minimum activity rules. --asilvering (talk)10:58, 22 October 2025 (UTC)[reply]
dewiki's process (on which ours was supposed to be based) does have minimum activity rules (de:WP:SB asks for 2 months, 200 article space edits, 50 of them in the last 12 months). The "50 mainspace edits in the past year" rule would disenfranchise some people who are extendedconfirmed. —Kusma (talk)12:07, 22 October 2025 (UTC)[reply]
It would be ironic to have higher edit requirements than those needed by an admin to avoid "inactive" desysopping, so I guess having at least 100 edits in the last 5 years would be a good activity requirement?Fram (talk)13:06, 22 October 2025 (UTC)[reply]
I do think voting rights and inactivity desysops are separate issues, but I don't really want to introduce a special class of voting rights only for admin recall. Note that dewiki uses the same criteria for all votes (and they use voting more than we do). The anti-metapedian "count only mainspace edits" is also a bit questionable given how many admins are fairly metapedian in their approach (but it would at least tell people that editing their user space is not enough). —Kusma (talk)14:03, 22 October 2025 (UTC)[reply]
I think complex suffrage rules are a bad idea because they are hard to check. We should have an easy-to-check rule such as "!voters must be extendedconfirmed", then call it a day. –Novem Linguae(talk)14:52, 22 October 2025 (UTC)[reply]
I agree that complex suffrage rules are hard to check, that voting and inactivity desysops are separate issues, that it's not great to introduce a special class of voting rights only for recall, and that it's ironic to have higher edit requirements than those needed by an admin to avoid an inactivity desysop. But I just can't square the idea that, for example, we expect prospective RFA candidates to have strong content understanding (GAs, often), but are happy to let people who have no interaction with mainspace at all decided who ought to be desysopped. I don't mean to say "someone who doesn't participate in mainspace editing shouldn't have a say in adminship", exactly, but this disconnect seems to me emblematic of the broader issue with the petitions - I just don't think they reflect how we make community decisions on English Wikipedia, and I think that's a problem. --asilvering (talk)02:24, 23 October 2025 (UTC)[reply]
I've been pondering option B. The concern about turning the recall into an RRFA-before-the-real-RRFA is a valid one, but on the other hand having the recall be just the "Oppose" section of an RRFA isn't great either. 30 days of getting dumped on, then you have another 30 days to decide whether to open yourself up to potentially another week of it in the RRFA? Ugh. OTOH, glancing through a few of the past recall petitions, I see some people had used the discussion section to offer support. Documenting that option (so people doing it don't have to worry about getting shouted down with "save supports for the RRFA") may be all option B really needs to be.Anomie⚔16:08, 21 October 2025 (UTC)[reply]
My personal advice to any closer is to avoid relying on the concept of a bartender's close as much as possible. I understand why this idea is attractive. I feel, though, that it provides a disincentive for participants to work out a best compromise through discussion, and it sets up the evaluation of consensus to be challenged on the basis of the closer imposing their own solution. Now it may be good idea to start moving towards a model where a conciliator can weigh the voices and find a middle ground solution that leads to the greatest overall satisfaction (even if that means the least amount of dissatisfaction). I think, though, in order to ease the transition from the current consensus-based decision-making traditions, the community should discuss this approach first and establish that there is support for a conciliator role.isaacl (talk)16:51, 21 October 2025 (UTC)[reply]
I'd just like to pull out the business about sysops living under a constant Sword of Damocles where they could be recalled at any time for any reason. It's most clearly articulated byThryduulf when he says "It is a problem that 25 people can effectively desysop an admin before they're even aware that there is a recall process."
That's how it is, Thryduulf, for people who aren't sysops. Normal editors are under a Sword of Damocles 100% of the time. Except that it's worst for us:one person can siteblock me before I'm even aware that they think there's a problem with my edits. Welcome to Wikipedia.
In my case the one person was a sitting arbitrator, and they did it without warning. The first time they edited my talk page was when they put up a block notice. And mine isn't an unusual experience. It's actually quite normal for people who accidentally cross a sysop who's tired and not reading straight.
There was no consequence for the blocking sysop. There never is.
What problem? Nobody has established that thereis a problem with recall. If there's a problem with recall, then show me the person who got recalled but shouldn't have.
What Mz7 has established is that there is a problem with fear of recall, and I started this subheading to talk about that fear. I want to do so in the context of the basic asymmetry between how easy it is for you to block me and how hard it is for me to recall you.—S MarshallT/C12:06, 22 October 2025 (UTC)[reply]
I think the part you miss is that you can ask for a review by slapping a unblock template, admins have no recourse if 25 people decide to petition to remove you (besides going through rRFA which is almost garuanteed to never pass).Sohom (talk)12:55, 22 October 2025 (UTC)[reply]
I don't think it's almost guaranteed to never pass. I think that all the people who've been recalled,should have been recalled and all but Graham87 knew their RRFA was doomed from the start, so they mostly didn't bother. I think that if you or Thryduulf went through the same process, then your RRFAs wouldnot be doomed from the start at all.—S MarshallT/C13:31, 22 October 2025 (UTC)[reply]
I don't buy that for a single minute. Any RRfA would by default start "in the hole" at 0/25/0 (assuming all petitioners voted nay) which would make retaining the admin rights next to impossible given the fact that they not only need to have 70+ percent to pass, but also need to overcome a by-default 25-nay deficit to do so. This is easier said than done regardless of who the administrator is. If anything,Graham87 showed the community that RRfA is redundant with the actual recall petition - it passes, your RRfA is doomed, and so there is no point participating in a process that is guaranteed to fail. —Jéské Courianov^_^vthreadscritiques14:57, 22 October 2025 (UTC)[reply]
Regardless of whether the reason is good, it still points to the actual RRfA - the point where an admin has to defend their actions - being completely redundant/unnecessary. Why bother with an RRfA when it's patently clear you're not going to pass, especially if emotions are running high because of the recall? This also isn't a matter which you can let sit; cunctate for too long and you've effectively172'd yourself out of adminship regardless. —Jéské Courianov^_^vthreadscritiques15:29, 22 October 2025 (UTC)[reply]
"almost garuanteed[sic] to never pass"
Yeah, citation needed.
Last year'sArcbom elections, which are kinda, by their nature, looking at people who incredibly active in project space administration (where it's apparently very easy to make enemies), and where people are holding them to a much higher standard than regular admins, and who even may strategically vote against people they trust, and we see that every single one got over 50% approval - even Beeblebrox, who was controversial to say the least, and all but he passed with over 60% approval. The pattern hold in2023, 2021, 2020, 2019, and 2018, which is when I stopped looking.
Well, you say, maybe Re-RFA would be different- then we need to look atWWT's andHF's as well as Graham87's - and yes, Sohom, I know you're aware of those.[47][48]. And, okay, yeah, I'll concede those are a little different - Graham87 had several adverse ANI threads closed against him in the previous months, had several opportunities to course correct and instead continued making the kinds of blocks that were getting him in trouble during the recall petition, while WTT and HF did not. But no, I don't think you can look at one RfA and conclude that the others would "never pass", not when 2 out of 3 re-Rfas that year did.
Similarly, while an unblock may give you a chance to appeal - in all but one of the cases[49] I listed in my Bbb23 evidence involved an unblock appeal, at least one other admin looked at the unblock appeal and left it in place.[50][51][52][53][54][55]. Unblock admins look all day at bad faith actors who lie to them, they are not a good place to overturn unfair blocks. S Marshall would be fine, but that's because lots of people know him and like him. Random account with no userpage?Some day, somebody needs to write an essay about how the "what if it was me" mindset shapes these discussions - admins who make a lot of blocks or deletions think "well, what if I make a bad one and I get recalled?", ignoring the fact that, for all but one case, it hasn't just been one bad decision (seriously, y'all need more self confidence), and non-admins say "but what if it was me that was blocked", fully cognizant that, yeah,reversing an admin action is not always easy. (The fact that that doesn't apply to the average VPP participant, is, well, a matter for another day)GreenLipstickLesbian💌🦋16:19, 22 October 2025 (UTC)[reply]
I think the biggest issue is that Graham87's RRfA going so deep underwater had amajor knock-on effect on later recall petitions. Whether it's fair or not, and irrespective of the merits and facts of the case, the fact the first petition led to a doomed RRfA very likely influenced the other successfully recalled admins and convinced them that any RRfA attempt was going to meet the same result. —Jéské Courianov^_^vthreadscritiques03:40, 23 October 2025 (UTC)[reply]
Yes, I have noticed you think that, Jéské Couriano.[56][57][58][59][60] I do understand where you're coming from, and I do concede that fear is not rational, but I disagree - there were other factors that were more influential to the decision not to go through a re-RfA, such as a hisoty of sanctions, an an apparent lack of desire totalk about admin stuff or a realization that the petition hit the threshold so quickly that any RfA would not pass. (Just saying, getting Wikipedians to agree on something is like herding cats. If you get a twenty five of them to agree onanything in less than 24 hours, that would be aWP:SNOW decision in literally any other venue. Most admins are trained to respect blizzards above all else)GreenLipstickLesbian💌🦋08:10, 23 October 2025 (UTC)[reply]
A not unique reaction... And one that both sides here seem to interpret very different... One seems to view retiring as proof that the admin was only in it for the thrill of the tools not the good of the project and on the other side its seen as proof that this process is brutally driving editors in good standing away from the community permanently. Perhaps we could split the difference if we treated it less as a punishment and more as a democratic procedure which included thanking the admin for their service, highlighting their best contributions (their worst were likely highlighted in the recall), and welcoming them back into the realm of non-admin editors with a celebration.Horse Eye's Back (talk)15:55, 23 October 2025 (UTC)[reply]
Here's another idea. It could be because the admin lost the spark and started seeing Wikipedia as more of an obligation. With the removal of the bit, the admin no longer sees any reason to continue working on something they don't enjoy working on anymore.fanfanboy(blocktalk)17:39, 24 October 2025 (UTC)[reply]
Thats a very fair point, I take it all within the context that ragequitting/retiring seems to be a rather temporary phenomenon most of the time... I would be easier to name all the retired editors who actually retired than the retired editors who either un-retired or still edit despite a prominent claim of retirement on their user page.Horse Eye's Back (talk)18:31, 25 October 2025 (UTC)[reply]
I would go even further to say that anyone who is so attached to their admin bits that they consider the possibility of losing them to be a "Sword of Damocles" situation shouldbecome less attached to them, one way or another. I don't know to what extent the whole "janitor" thing has ever been true--it might well have always been a polite fiction--but we are certainly straying further and further from it, to our detriment.Writ Keeper⚇♔13:30, 22 October 2025 (UTC)[reply]
S Marshall, I think any number of admins, including the former ones recalled for inactivity, have far less of a margin of mistake than you do. You are an active member of the community who does important and highly visible work which garners you a large amount of respect. That respect means that if some admin were to attempt to sanction you there would be pushback such that it seems likely that the sanction either would not pass (if put up for discussion) or would be reversed (if it was). However, I would think that a sanction would become more likely to pass or stick if the people whose voice who respect you and would defend you against such a sanction, carried no weight. Best,Barkeep49 (talk)15:20, 22 October 2025 (UTC)[reply]
Thank you for those kind words. You're right to say that I'm one of the vested contributors that Wikipedia likes to pretend it doesn't have. I have the credibility that comes with a username that people know, and I'm accultured to Wikipedia so I know what tone to take with people. As you rightly say, it inoculates me against some of the behaviours that some sysops freely display with less accultured, less vested editors. Please could you clarify your final sentence? I'm afraid I haven't been able to follow it.—S MarshallT/C15:46, 22 October 2025 (UTC)[reply]
Sorry for not being clear. What I was trying to say is that in the scenario where some admin is out to get you because of some honest mistake you made, I think the current processes make it unlikely that if proposed it would get consensus and if it were enacted without discussion that it would stick. However, I think that's true because the discussion would give appropriate weight to those who would defend you as it would to your critics. Right now, in the petition process, the critics are the only voices given any weight and admins have so far been less willing to go to the second phase of the process (2 out of 10 times) than in the model we copied from. Best,Barkeep49 (talk)16:08, 22 October 2025 (UTC)[reply]
The recall petitions I've read have all been preceded by discussions on Talk Pages, ANI, and elsewhere--usually where the admin in question has enjoyed the support of other admins. So there has been plenty of defense before the recall. In fact, it was this circling of the wagons, the admin choruses of 'but they do valuable work so overlook the abuses,' that led to the recall process in the first place.AugusteBlanqui (talk)16:21, 22 October 2025 (UTC)[reply]
I've certainly made honest mistakes while editing Wikipedia, and also stupid mistakes. But exactly 0% of the blocks in my block log are because ofmy mistakes. I got site-blocked once in 2008 by sysop error that she immediately reversed, and once in 2012 inthese circumstances. I've also been blocked once in 2021 from one user talk page because Mjroots took it on himself to invent a novel and ill-conceived blocking rationale that I never bother to challenge because I was never going to edit that page anyway.
If those blocks had needed 25 signatures in advance before being enacted, they would never have got through. Not a single one of them.
This is why I reject the contention that 25 signatures is somehow a low threshold for sanctioning someone. It's an extraordinarily high threshold for what's intended as the start of a process. I mean, if I brought a case to Arbcom asking for a desysop, and it hadtwenty-five independent signatures on it, then Arbcom would definitely take that case. I guarantee it.
I'm not surprised at all that in the limited number of cases where we've got 25 signatures for recall, it's been justified and the sysop (having stood back and taken a look at the diffs) has thrown up their hands and admitted defeat. That's healthy.
What's missing here is any example of a person who got desysopped by this process and shouldn't have been. Produce one of those. In the absence of that, I think Mz7's suggestions are trying to solve a problem we don't have.—S MarshallT/C16:50, 22 October 2025 (UTC)[reply]
What's missing here is any example of a person who got desysopped by this process and shouldn't have been is not the standard you laid out originally. The standard you laid out wasThe Sword of Damocles over my head is on a far thinner thread than the one over yours. Nuff said. This is what I rebutted. That said, I do not think 25 people should, without any chance of discussion or opposition, get to rewrite our inactivity rules. Best,Barkeep49 (talk)02:03, 23 October 2025 (UTC)[reply]
They don't, and haven't. If people choose not to run for RRfA, that's their business. The consistent refrain is that people choose not to run for RRfA because their RRfAs would inevitably fail, but if they can't pass an RRfA, why should they be an admin?Writ Keeper⚇♔02:24, 23 October 2025 (UTC)[reply]
The consistent refrain is that people choose not to run for RRfA because their RRfAs would inevitably fail I've never heard this from anyone who didn't actively support desysopping the admin in question. What I hear from everyone else is that people choose not to run for ReRFA because why would anyone voluntarily submit themselves to a week of criticism and abuse at RFA after they've just had days or weeks of criticism and abuse in the form of a recall petition?Thryduulf (talk)02:47, 23 October 2025 (UTC)[reply]
Look, if 25 independent people came to me in the same month to say, "Listen, S Marshall, we've lost confidence in you and we don't want you to close any more RfCs", I woulddefinitely stop closing RfCs. Becauseof course I would! Completely step back, and leave all discussion closes alone until I was clear that I had the community's confidence again. 25 independent people in the same month is quite an extraordinary number of people considering the limited number of active Wikipedians nowadays. I can't understand the contrary view at all. When 25 independent Wikipedians say the same thing in the same month how can you possibly just brush that off?
If we were at block review, 25 independent "endorse" votes looks like a snow close for a site ban. It's a crystal clear signal that the community has totally had enough. If we were at Arbcom, 25 independent people certifying the need for a case is a slam dunk red flag that a case needs opening.
I mean, people do get annoyed with S Marshall. One person or two people having a go at me for one of my closes is justTuesday. I've definitely annoyed more than 25 people with my closes, but they're sure as hell not all coming to me in the same month to say stop doing it and if they did, I'd totally step back.—S MarshallT/C03:13, 23 October 2025 (UTC)[reply]
But: Would you? Should you? Forany 25 editors? Even if the 25 editors are a couple of people who are mad at you because this afternoon because the closing statement you posted this morning is the opposite of what they voted for, and their loyal friends? Context matters, and I'd hope that you'd take the "sore loser" aspect into account when deciding whether the complaints warrant such a response.WhatamIdoing (talk)03:58, 23 October 2025 (UTC)[reply]
Yes, I think I would and should.
I'd likely start a post mortem in some central venue to ask: what went wrong? Had I just royally screwed up? I mean, if the community largely thought I hadn't, and this was just a case of outraged redditors all registering accounts in order to brigade me, then I'd likely start back up again. But while that discussion was going on I definitely ought to stop, shouldn't I?—S MarshallT/C04:35, 23 October 2025 (UTC)[reply]
I am not sure why you talk about 25independent users. They are not independent. They read each other's comments, and it is not uncommon that they write smth like "I was not going to sign this, but the arguments of X who pointed out a major mistake in judgement of Y convinced me". And of course X pointed out smth which they perceive as a Y's major mistake in judgement but they were not interested or did not have time or whatever to go and see how characteristic for Y this mistake is, and what does actually the rest of contribution of Y consists of.Ymblanter (talk)10:18, 23 October 2025 (UTC)[reply]
This was notable particularly in the Night Gyr fiasco, where the reason for desysopping morphed part way through from inactivity to that fact that Night Gyr hadn't responded ... to the petition ...FOARP (talk)12:16, 23 October 2025 (UTC)[reply]
"Given that they have edited since the launch of this petition and thus are or should be aware of it but have not replied, I think a revocation is justifiable" - This was an argument cited as convincing by a number of the participants.FOARP (talk)14:36, 23 October 2025 (UTC)[reply]
Lack of responsiveness to criticism was one of the points made in the original petition: it wasn't a new issue brought up part way through. The specific argument by WellingtonBay about not having responded to the petition itself was cited as convincing by one signatory, who had already signed the petition two full weeks before WellingtonBay made that argument.
By contrastLevivich's argument about a pattern of ADMINACCT issues was cited as convincing by eight of the subsequent ten signatories (nine if you count QoH's "per EggRoll", which in turn cites Lev). The point that it was part of a pattern had already been alluded to by several prior participants: three specifically cite the fact that NG had not responded to a single post on their user talk page since 2007. Including the original petition.
You may or may not think that the concerns raised in the NightGyr petition were reasonable, or that they rose to the level of meritting desysopping – if I were god-emperor of Wikipedia I'm not sure I would have desysopped on the basis of the arguments made – but it's not true that lack of responsiveness was a new argument that came about partway through the petition, and it's not true that lack of responsivenessto the petition specifically was ever the primary justification for people to sign the petition. Yes, a couple of people did cite lack of responsiveness to the petition specifically, but both of those also cited either inactivity or more general concerns about responsiveness.Caeciliusinhorto-public (talk)15:47, 23 October 2025 (UTC)[reply]
Lack of responseto the petition being seen as a clinching argument (you'll note the petition stalled part way through, this was seemingly the argument that got it over the top) isnecessarily an argument that wasn't made at the start of the petition.FOARP (talk)19:37, 23 October 2025 (UTC)[reply]
a sysop who's tired and not reading straight Can confirm. In my case, I had only been around for a few months, I asked a regular (now vanished) to stop marking non-minor edits as minor, and they responded by reporting me to AIV. Gave me a heart attack, but I was unblocked by the blocking admin within minutes with the apology of "sorry, I was reading too many tabs" (paraphrased). Just goes to show how easily it is for most editors, especially newcomers, to be shown the door.QuicoleJR (talk)18:17, 25 October 2025 (UTC)[reply]
seemingly got it over the line in what sense? If you removed the zero people swayed by Wellington Bay's vote into signing the petition, it still would have got over the line. If one vote can be credited with getting it over the line, it's Levivich's which was, as I already said, explicitly cited by eight subsequent signatories. Nor was Wellington Bay's signature the one which re-started people signing the petition after it stalled on 4 July; they were the seventh to sign the petition after signing resumed on the 11th. Even the one vote you cite – which in no way got the petition over the line except in the trivial sense that as the petition is closed once it reaches the threshold, removing any of the votes would drop it back below the threshold – does not cite non-responsiveness to the petition as the primary issue!Caeciliusinhorto (talk)20:09, 23 October 2025 (UTC)[reply]
@FOARP if by "this system" you meanWP:RECALL, then I would support removing it pending significant reforms along the lines of those I've proposed and those Mz7 has proposed (after further workshopping).Thryduulf (talk)21:30, 22 October 2025 (UTC)[reply]
The OP didn't provide a link to the process in question so here it is:Wikipedia:Administrator recall. This could use more background but the point of the process seems to be as described byrecall election: to "remove an elected official from office". The mechanics of petition, RRfA and the rest are just means to an end – the removal of dysfunctional admins. The process seems to be working as intended and no-one has produced a counterexample.
It seems obvious that, in these cases, most subjects did not proceed to an RRfA because they expected to lose and so chose to avoid further humiliation. This seems to be a good thing as, if an RRfA were started regardless, the resulting pile-on would generate unnecessary drama and bitterness. The current option softens the blow rather than insisting on such awalk of shame.
"The process seems to be working as intended" - Please show evidence that this was ever intended to simply remove admins with 25 votes (not !votes,votes). All of the discussions up until this system was brought in had the petition as simply a sense-check/filter before the main decision. Instead it's all decided there, every time.FOARP (talk)11:37, 23 October 2025 (UTC)[reply]
It was intended to recall admins who would fail to pass an RfA, the fact no recalled admins have succeeded so far is not a sign of being broken but a sign of functionality. We haven't even started to have admins recalled who have passed an RRfA in order to revise the parameters better. The fact community consensus hasn't re-affirmed such a petition yet is not a sign there isn't consensus, only that it hasn't been tested yet.CNC (talk)12:02, 23 October 2025 (UTC)[reply]
This is railroaded-prosecution system where the result is pre-decided by the time the convict gets to court, and so pleads guilty every time rather than go to a full trial.FOARP (talk)12:23, 23 October 2025 (UTC)[reply]
It was intended to recall admins who would fail to pass an RfA, this is completely and fundamentally incorrect in every respect. The petition was intended to be a sense-check with the sole purpose of preventing frivolous ReRFAs where there would be no chance offailing. It was intended that every successful petition would result in a re-RFA that some administrators would pass and others would fail.Thryduulf (talk)12:31, 23 October 2025 (UTC)[reply]
That's a blatant lie. When I proposed the petition process, I was very well aware that some admins will choose to not go through RRFA. That happens during Arbcom all the time. And in case of at least one recalled admin, it happened in the past before happening again in Recall.
Of course, in an ideal world, more admins will attempt to RRFA, and some of them will succeed. We should workshop ways to make the RRFA itself less stressful to make that happen more. But nobody in the making of recall, best i can recall, thought to force literally every admin through RRFA, kicking and screaming, against their will.
" I was very well aware that some admins will choose to not go through RRFA" - We're you aware thatall of them wouldn't? If so, could you let us know what next week's lotto numbers are?FOARP (talk)14:39, 23 October 2025 (UTC)[reply]
That's all completely irrelevant to what I said, please try reading it again. What you were thinking when you proposed a petition process is something irrelevant to both what I said and to what the community approved.
The petition process, as approved by the community, was intended to prevent frivolous reRFAs - nothing more, nothing less. Of course nobody suggested forcing admins to stand again, and the desysopping if they don't was to there to ensure they couldn't just ignore the request to stand at RFA again. The RFA is what determines whether someone has the support of the community or not - the petition is explicitly and intentionally not a consensus process.
If you think this is an attempt to rewrite history then you are either failing at reading comprehension or not here in good faith. I don't know which I prefer.Thryduulf (talk)14:40, 23 October 2025 (UTC)[reply]
It was intended that every successful petition would result in a re-RFA that some administrators would pass and others would fail.
This was still not true then, and I hope this is still not true now. The only way to guarantee it after a successful petition is by forcibly making the admin go through an RFA, whether they want it or not.Soni (talk)14:50, 23 October 2025 (UTC)[reply]
Or, you know, not having this process because, when it isn't actually resulting in any RRFA's, then it isn't working as it was supposed to.FOARP (talk)15:06, 23 October 2025 (UTC)[reply]
(edit conflict) You're right, I should have been more cautious to your reading bad faith into my contributions here. Accordingly, I'll rephrase: It was expected that there would be a mix of successful and unsuccessful petitions. It was intended that nearly-every successful petition would result in the admin standing for re-RFA. It was expected that some re-RFAs would be successful and some would be unsuccessful. It was not expected or intended that in less than 48 hours 25 editors could drive a fellow editor away from the project completely without any attempt to see whether those editors views matched the consensus of the community.Thryduulf (talk)15:07, 23 October 2025 (UTC)[reply]
There's a lot of passive voice in your post so I'm not sure who had these expectations and intentions. I don't see them in the policies or the discussions that created them.AugusteBlanqui (talk)15:14, 23 October 2025 (UTC)[reply]
I'm surprised you can tell the passive voice apart from the passive aggressive voice, lol. Although I can see why Thryduulf would be so sensitive about "It was intended to recall admins who would fail to pass an RfA" because they almost certainly fall within that category, almost no chance of passing a modern RfA.Horse Eye's Back (talk)15:20, 23 October 2025 (UTC)[reply]
If you think that I don't have the consensus of the community to be an administrator, then go ahead and start dispute resolution proceedings against me, citing your evidence that I'm a net negative to the project as an administrator. Or you could just jump straight to a recall petition, nicely illustrating one of the flaws in the system as implemented.Thryduulf (talk)15:31, 23 October 2025 (UTC)[reply]
I notice that you don't appear to disagree that you wouldn't be able to pass a modern RFA. I have no interest in there being less admins, I think we're understaffed as it is... But I think its important to point out that you have a clear conflict of interest when it comes to how to interpret this, and that your chosen interpretation is in line with your conflict of interest. What Thryduulf the Admin thinks the meaning and intent is also happens to be the meaning and intent which is most useful to Thryduulf the Admin. Do you see the issue here?Horse Eye's Back (talk)15:41, 23 October 2025 (UTC)[reply]
RFAs are uncertain processes. I honestly have no idea if I would pass one, because I never went through one. I went through AELECT, where no-one asked any actual questions or expressed any actual concerns, yet somehow I still ended up with circa 100 oppose votes.FOARP (talk)15:56, 23 October 2025 (UTC)[reply]
MyWP:ORFA wasvery positive, but there are apparently 106 editors in good standing on Wikipedia who thought in October 2024 that I should not be an admin (admittedly versus 268 who thought otherwise), and I don't even know their reasons for voting the way they did, so who's to say that 25 editors could not be gotten together?
In Oct 20246 of 11 successful candidates had >100 oppose votes, then in Jul 2025only 2 of 9 and the mean oppose dropped significantly. I really don't think that it's comparable to an equivalent RfA/RRfA which presents significantly different numbers for successful candidates. AELECT is clearly more difficult than RfA so don't be thrown off by anonymous votes that wouldn't sign a petition publicly, let alone chime in at ANI etc.CNC (talk)10:26, 24 October 2025 (UTC)[reply]
In the October 2024 AELECT, we had a sizeable minority of editors voting against anyone whom they ran out of time to research. Instead of "I don't know, so I won't vote" for that person, it was "I didn't plan enough time to research this person, so I will assume they're bad and vote against them"WhatamIdoing (talk)23:33, 24 October 2025 (UTC)[reply]
Not quite. There were 18% less votes overall, down from 659 to 541, so the abstentions and the oppose votes decreased proportionately. A couple of candidates dragged the mean support up, but that came from a notable decrease in oppose votes, not from abstentions which remained balanced.CNC (talk)08:37, 25 October 2025 (UTC)[reply]
I have no idea whether I would pass a modern RFA, because modern RFA is an unpredictable hell-hole that bears little relation to the process as it was when I passed near-unanimously in 2005. There are a small number of non-admin editors in generally good standing who I would feel confident saying would not pass an RFA if they stood today. There are exactly zero editors (admins or otherwise) in any standing who I would feel confident predicting they would pass an RFA today. There are many that Ihope would pass, but that's not the same thing.
If there wasn't such community opposition to voluntary reconfirmation RFAs then I would have stood for one at some point in the past few years. As it stands I have no interest in people opposing me because they object to the idea of admins verifying they still have the trust of the community when not being forced to (and make no mistake, some people will oppose candidates at reRFA simply because it is a reRFA) which is completely irrelevant to whether I do or do not hold the community's trust.
As for the conflict of interest, that's identical to the conflict that literally every administrator on the site has and exactly equivalent to the conflict of interest that every non-adminstrator has in the same process, making it utterly meaningless. It is also not a "chosen interpretation" it is the only interpreation that logically follows from the facts as far as I am aware of them.Thryduulf (talk)16:14, 23 October 2025 (UTC)[reply]
I agree that modern RFA is not ideal and perhaps even broken... Which leaves us in something of a chicken and the egg situation, perhaps if we fixed RFA the recall process would be easier to figure out. On the other point "exactly equivalent to the conflict of interest that every non-adminstrator has in the same process" that simply isn't true because one has a position of power and prestige to lose and the other doesn't. Thats like saying that the politician and the voter have exactly equivalent conflicts of interest when it comes to whether or not that politician should stay in office.Horse Eye's Back (talk)16:21, 23 October 2025 (UTC)[reply]
On your first point, it was hoped by at least some people that the existence of recall would be what fixed RFA on the basis that it would make adminship less of a big deal, and several others were less hopeful but felt it wouldn't hurt to try (I think I was in this camp). Unfortunately that hasn't proved to be the case, but I don't see that as being related to how recall has turned out in practice versus how it was intended to work.Thryduulf (talk)16:36, 23 October 2025 (UTC)[reply]
If you'll pardon my tangent, Thryduulf, I know I've said that I think most re-RfAs would pass. I don't think you would, though, sorry - your last 500, nonminor mainspace edits (most of which are redirect or template gnoming related[61]) bring us back over a year, which isn't actually an issue, except for the fact that you've not built up a reputation as somebody who does a lot of encyclopedia editing. Instead, I'm hazard a guess most people know you from talk or projectspace discussions- which you habitually comment more than anybody else, and accuse anybody who says something you disagree with of not answering your question, not refuting your arguments, or being disconnected from reality.Quick anti-aspersion defense, from the past few months:
this conversation - you've made 18 comments, including saying that people who disagree w/ you were disconnected from reality[62] - to which I'm going to respond w. your other commentwhat is not acceptable is you claiming that evidence-backed views that differ from yours are contrary to reality which you madeliterally in response to somebody who called you out on your first reality comment.
WP:VPR#RFC: Adding featured and good content status to the tagline - you have made 43 comments, by my count over, quite literally, if we should tack on half a dozen words to a banner thatregular people do not read -[65] + saying that people were responding to you but not refuting your arguments.[66] (which, using the same argument you've used here- how do we know they haven't been refuted until a closer judges that? Schrodinger's Wikipedia Consensus cuts both ways)
edit summaries referencing other editors relationship to reality[67] (some false positives)
Night Gyr recall- you made 54 comments, well above anybody else who wasn't bludgeoning[69] and, when asked about it, asked if others would like toshut up w. the esno need to make multiple requests for people to answer the question if they just answered the questionb[70]
Sanctionable bludgeoning? No idea! But you can't do stuff like this & expect to build up good will. (I say this, not as a moral judgement- I talk too much myself at the best of times, :P )GreenLipstickLesbian💌🦋18:19, 23 October 2025 (UTC)[reply]
@AugusteBlanqui I read those expectations and intentions very clearly in the significant majority of the comments that resulted in RECALL. If you don't, then maybe you could start by showing some evidence that something else was intended.Thryduulf (talk)15:33, 23 October 2025 (UTC)[reply]
You didn't expect admins would just fuck it off if 25 editors signed a petition? I kind of expected that mainly to be honest, not much else.CNC (talk)15:21, 23 October 2025 (UTC)[reply]
Looking at the first example ofWikipedia:Administrator recall/Graham87, it seems that the initiator provided lots of links to issues and previous discussions. Its closer likewise provided lots of links. I've not looked through the other cases to see if they followed this example but would expect any respectable petition to do something similar.Andrew🐉(talk)09:58, 23 October 2025 (UTC)[reply]
Petitions also don't need to be respectable.
A petition can be opened against any admin, based on any reason, and the issue is decided once 25 votes are amassed. I'm only being semi-unserious when I say that"FOARP is a filthy deletionist who smells" would probably get to 15 votes at least, possibly 25, and the RRFA would be a whole bunch of editors !voting"Neutral - need to see more evidence about FOARP's bodily odour before I decide either way".FOARP (talk)11:45, 23 October 2025 (UTC)[reply]
With all due respect, FOARP, you seem to be arguing against some hypothetical recall that might be called, instead of the actual cases and the examples at hand.
Plenty of editors believe that the recalls that have happened so far were correct decisions. You may disagree.
FOARP's comments are much closer to the reality of recall than many of the comments from those who think there is nothing wrong with the current situation. Especially with regards to the inactivity petitions which, intentionally or otherwise, are applying a much stricter activity requirement than the one that has community consensus. While their language is emotive in some cases, I see absolutely no evidence that they are here in anything other than good faith (and I say that as someone who has had distinct concerns this regard about some of FOARP's comments regarding other matters).Thryduulf (talk)14:26, 23 October 2025 (UTC)[reply]
As someone who called out your misinformation literally a couple minutes ago up thread, I just don't take you for a neutral arbiter of reality, sorry.
I understand that both of you hold very strongly held views on RECALL, but either you are just refusing to accept that other people may also have valid perspectives. Or we are both looking at two very different Wikipedias.
I'm remembering an adjacent RFC closed by @Tamzin which has a very stark divide between admins and non-admins. I can't recall what RFC it was, but I still remember the close for how starkly different the two perspectives were. How are we both looking at the same process and come to this disparate a conclusionSoni (talk)14:39, 23 October 2025 (UTC)[reply]
You have not called out any misinformation by me. You have simply claimed that my view is wrong because it doesn't match your preferred viewpoint. There are multiple different perspectives here, and that's understandable, but what is not acceptable is you claiming that evidence-backed views that differ from yours are contrary to reality. Please desist with the accusations of bad faith.Thryduulf (talk)14:46, 23 October 2025 (UTC)[reply]
Soni is correct that the literal statement is incorrect: it wasn't assumed that every petition attaining the threshold number of supporters would result in a re-request for adminship, but that some admins might cede their privileges (just as some admins have said, if enough people raise concerns with their actions, they would resign as admins). It is also true, though, that the petition process was designed to be a precursor for substantial discussion to be held during the re-request. Current practice is that the community is proceeding straight into substantial discussion in the petition.isaacl (talk)15:37, 23 October 2025 (UTC)[reply]
I want to note that while I think certain things are wrong, I am calling this a check-in for a reason. I probably should have linked to the page that listed the 10 recall petitions to date, but otherwise, I intentionally was trying to allow editors wide latitude about how it's going, including by offering clearly mutually exclusive options. Best,Barkeep49 (talk)20:17, 23 October 2025 (UTC)[reply]
Another link that seems to be needed isWP:BARTENDER to explain what is meant by a "bartender's close". That's an essay, not policy, and OP's reference to this seems to be a blatant violation ofWP:RFCNEUTRAL. The problem of resolving this multiple-choice morass arises because the RfC has been framed badly, contrary toWP:RFCBRIEF. Tsk.Andrew🐉(talk)08:01, 23 October 2025 (UTC)[reply]
Yeah. This RFC probably should have been workshopped into like 10 individual RFCs that ask specific, actionable questions such as "should recall be repealed?", "how many days should a recall run?", "what are the requirements to vote in a recall?", etc. Once the workshop was finished, then the finished questions and options could have been presented for !voting. Ah well. –Novem Linguae(talk)09:15, 23 October 2025 (UTC)[reply]
Note that this entire mess is the product of such a decision-making process, where a small group of editors, based on assumptions about how the system would work that have not proved correct, pushed this through.FOARP (talk)11:39, 23 October 2025 (UTC)[reply]
These were also my thoughts. Even trying to remember the 9 different options is difficult enough for !voting, let alone trying to follow the discussion. It's unlikely there will be consensus for anything at this rate.CNC (talk)11:48, 23 October 2025 (UTC)[reply]
Note afollowup request for comments discussion was workshopped starting last November and heading into this year. The election of theleekycauldron to the arbitration committee stalled the effort and it didn't proceed. (*) There's a hard balance to strike, because the number of people who will engage in workshopping ten RfC questions is typically considerably smaller than the number of people who hold opinions on them, making it hard to reach agreement on the RfC questions. So sometimes it may just be better to have a broader request for comments discussion that essentially workshops proposed changes. Unfortunately, it's not very easy to tell which approach is most suitable for a given situation.
(*) Of course, there is a reasonable argument that a review at the start of 2025 was a bit soon, and that having a review now, after a year, allows for more data to be taken into account.isaacl (talk)15:23, 23 October 2025 (UTC)[reply]
As a further bit of evidence, I was just checking my watchlist and noticed thatGraham87, who was the subject of thefirst case, seems to be still editing quite amiably. That case seems to be a good example of the process working well as they went most of the distance and only withdrew and resigned when the outcome seemed settled. And now they seem to have taken that outcome in good heart and moved on with their other good work. This stoic, "no big deal" attitude should be encouraged and applauded. As another example, founder Jimmy Wales has had their privileges criticised and curtailed over the years but he's stillstaying the course, "One of my fundamental beliefs is that Wikipedia should always stand ready to accept criticism and change..."Andrew🐉(talk)17:20, 24 October 2025 (UTC)[reply]
Above, many editors who are opposing recall completely or want to either turn it toothless or change it into some RRFA itself, seem to question what recall was intended for. So, let's check this.
Wikipedia:Requests for adminship/2024 review/Phase I#Proposal 16: Allow the community to initiate recall RfAs introduction: The intention of recall was "the community will be able to revoke the permissions of an administrator pending a new RfA", because "There is no means to remove permissions for administrators who have lost the trust of the community" except Arbcom. Recall was never intended to be some vague, non-binding discussion that some admin may need, perhaps, some check, no biggie. It was explicitly intended for admins who had (or seemed to had) lost the trust of the community. Only one has so far decided whether they really had lost that trust, the others realised they had no chance of passing (e.g. the inactivity ones) and/or had other reasons not to run: that's up tothem, or to issues with RfA itself, not up to the recall process.
I don't think there was much doubt in the mind of the proposers or closers of these proposals about what exactly was proposed. When 25 extended confirmed editors express their concerns whether an admin still has community support, the admin loses his toolset unless they go to RfA again. The "de-adminning" was a clear, major part of the proposals, not some unintended consequence we are now stuck with.Fram (talk)13:21, 23 October 2025 (UTC)[reply]
I will pull outWikipedia:Administrator recall/Night Gyr as the "unintended" case here. Back when I was following the discussion, I perceived two distinct waves, the first wave representing the first rationale that for all intents and purposes did not reach consensus and a second rationale that strung together a set of small mistakes that together with the old rationale found enough to de-admin a user. This makes me wonder whether if there was actually any "loss of trust" before the recall itself.Sohom (talk)17:11, 23 October 2025 (UTC)[reply]
I think a lot of my disappointment with recall comes from it being originally advertised as "based on the dewiki process". That process (where recall petitions against every admin are open outside of certain grace periods, and recall votes seem more independent of each other) is a lot slower and calmer than what we have here. Our recall petitions look more like old-styleuser RfCs, just without the dissenting views and a right to reply. That admin recalls end in desysop is fine, but the level of drama is not. —Kusma (talk)18:42, 23 October 2025 (UTC)[reply]
Are there clear reasons for the difference? Is the procedure significantly different? Is it a difference in temperament and culture? Or is it just happenstance, as we haven't had many cases yet?
And is the difference significant or just cosmetic? Your insights might help us here, please.
I am not very steeped in dewiki culture, but I am a native speaker and have observed their processes quite a bit (mostly from the outside). My gut feeling is that the difference is related to some deep wikicultural differences: dewiki did not have such a strong "polls are evil" anti-voting culture as enwiki from the start, and they still use voting in many places, not enwiki's weird blend of discussions and voting. Their RfAs and re-RfAs and recall petitions are closer to straight voting than ours, which takes away some of the drama and lowers the temperature. —Kusma (talk)19:46, 23 October 2025 (UTC)[reply]
@KusmaI think a lot of my disappointment with recall comes from it being originally advertised as "based on the dewiki process". That's because it was originally closer to dewiki process, until it got blended with enwiki's priorities on "Discussion is important".Phase II RFC had discussed every single aspect of recall, and chose to explicitly allow discussion in the Petition process instead of being a straight voting.
I still believe that disallowing discussion in the petition process would reduce the drama of recall significantly. If that's not feasible, I think we would benefit from other ways to reduce temperature through the recall process.Soni (talk)04:50, 24 October 2025 (UTC)[reply]
I don't think we can disallow any type of communication between editors, but we could force it off the recall pages. We won't be able to police off-wiki discussions.
For a fairly extreme version, imagine that the person initiating it is allowed to post a couple of diffs or links to logs, and that nobody else is allowed to post anything except their signature. Would we get more editors checking the admins edits/comments/actions themselves, instead of responding only to what someone else claimed said? That might be a good thing. What would we lose with such a system?WhatamIdoing (talk)05:16, 24 October 2025 (UTC)[reply]
Reasoned debate, is what we'd lose; although experience suggests we wouldn't, and it would mainly just move to talk pages or somewhere in project space. But my main objection to this suggestion is the game theory of it. "Ooops, I screwed up. I'd best use one of my other accounts to start a recall petition against myself that's got shaky reasoning and really terrible evidence, so nobody else can present the diffs."—S MarshallT/C10:00, 24 October 2025 (UTC)[reply]
Isn't discussion what the RRFA part of the process is supposed to be for? Under the original model, the petition part was just to make sure there were at least 25 editors who think the discussion should happen.Anomie⚔13:52, 24 October 2025 (UTC)[reply]
Clearly not! What we're getting iscloture when self-selected closers end the debate, often after less than a couple of days. Their motive tends to be a mercy killing; but by doing so they prevent the supporters from changing their minds and withdrawing their support.—S MarshallT/C10:26, 25 October 2025 (UTC)[reply]
I agree on this – I would prefer recall petitions to have a short, fixed duration, rather than be closed as soon as they hit 25 signatures. That would allow for more self-reflection from the admin being recalled and perhaps more time for things to cool down and alternative resolutions to be found.Toadspike[Talk]03:19, 26 October 2025 (UTC)[reply]
Every single day, we see new accounts gaming the system to become "extended confirmed" in order to obtain various tools and benefits. It is equally certain that there are accounts created for such purposes that are not so obvious in their efforts to reach that status. At the same time,The Signpost has reported on efforts by outside organizations to disrupt Wikipedia through various means, including doxxing of editors. We would be suicidally naive to think that entities intent on damaging Wikipedia would not exploit the vulnerabilities inherent in enabling a relative handful of manufactured accounts to undermine the trust and safety structures of this project through targeted recall efforts against the admins most likely to counter their efforts.BD2412T19:29, 23 October 2025 (UTC)[reply]
This conspiracy theory works both ways. If malign parties wish to subvert Wikipedia then they would want to aim high by gaining admin powers. We have steadily lowered the bar and now have more open admin elections. To maintain effective checks and balances, we need methods of undoing such mishaps.Andrew🐉(talk)20:25, 23 October 2025 (UTC)[reply]
I'm quite familiar with Lourdes as I was the first person tooppose their RfA. But I was almost alone as the final score in that RfA was 207/3/1. This demonstrates that the community is far too trusting and gullible at RfA and so provides little protection against bad actors. The recall option is therefore needed to help correct such mistakes.Andrew🐉(talk)22:25, 25 October 2025 (UTC)[reply]
If we're considering well-funded bad actors, then personally I think the more fruitful and direct path would be to build up a farm of editors making good edits, establishing their reputation. They could then gradually participate in discussions to make decisions that subtly favoured their employer. The real way to control content is to outnumber editors opposed to the employer's viewpoint; admins have no ability to override what is decided by the self-selected portion of the community that shows up to a discussion.isaacl (talk)23:36, 23 October 2025 (UTC)[reply]
While I recognize that BD2412's point is valid, I would expect these admins to be likely enough to pass a RRFA. I've supported Admin Recall for a long time, and survivedone attempt to recall me under my chosen criteria. I also almost lost my bits inan Arb case, resigned them anyway, failedRFA3, and then succeeded withRFA4. I still think A is the right choice at this point.SarekOfVulcan (talk)19:55, 23 October 2025 (UTC)[reply]
"I would expect these admins to be likely enough to pass a RRFA - Since thus far no-one has passed RRFA, nor has even one full RRFA been held, what is this based on?
You're thinking an RRFA would just be the same as a normal RFA, instead it's more like when FRAM tried to get his bit back after getting desysop'd by the foundation: lots of people are going to say "no smoke without fire" and either oppose or stay neutral.FOARP (talk)07:56, 24 October 2025 (UTC)[reply]
I was speaking particularly towards recalls initiated by coordinated bad actors. With Fram, there was an element of "well, it's the foundation" that wouldn't apply in this case.SarekOfVulcan (talk)13:56, 24 October 2025 (UTC)[reply]
See because I agree with Fram that the intent of this process was, clearly, to have a mechanism to desysop admins is precisely why I think there should be a mechanism for people who think the admins are doing good work to argue against that desysoping. Right now what we're effectively saying is that admins need to avoid upsetting 25 people if they want to keep on being admins. I'm concerned this creates a set of perverse incentives.Simonm223 (talk)14:02, 24 October 2025 (UTC)[reply]
But given that ReRFAs are not happeningsomething is clearly wrong. Reasonable minds can (and evidently do) disagree on what that something is, but it is unarguable that the process is not working as intended.Thryduulf (talk)14:26, 24 October 2025 (UTC)[reply]
But given that ReRFAs are not happening something is clearly wrong: What if they realize they are never going to pass for the reasons they were desysopped and give up? How is that wrong in any way?Wikipedia:Requests for adminship/Worm That Turned 2 shows that passing these is technically possible if you are in good standing. And mind you, WTT is an arb and has participated in several contentious cases.ChildrenWillListen (🐄 talk,🫘 contribs)14:37, 24 October 2025 (UTC)[reply]
Perhaps recall is not being deployed as widely as envisioned when designing a safeguard against frivolity, and the 25 editors who might feel WTT is not good admin material in a non-frivolous manner are not creating recalls for whatever reason.CMD (talk)14:48, 24 October 2025 (UTC)[reply]
The discussion above has done a good job at taking the temperature of the community on recall and generating ideas for proposals, but I don't think it is structured in a way that is good at actually measuring the consensus for/against each of them. I'd like to break out the proposals that seemed to gain traction, and give them a space for refinement, and eventually a space to see if we have consensus.
Note: Please treat this section as an idea lab/RFCbefore - I'm not looking for bolded !votes yet, I'm trying to make sure that the right ideas are put in front of the community properly in their best possible form.
I see 3 ideas that should probably get an up or down discussion:
Reducing the time a petition stays open from 30 days to 14 days (input helpful on number to poll)
Raise the number of signatures needed for a petition to succeed from 25 to 40 (input helpful on specific number)
There are 3 other proposals that could be discussed, but got weaker receptions
Allow an admin to start a RRFA or stand in an election anytime within 6 months of a petition closing. Administrator access would still be removed after 30 days.
Limiting petitions signers to 1 petition every 6 months
Having a slowdown at the start, either preventing signatures for the first day or so, or requiring all petitions to be open for the first couple days or so.
Any thoughts about which ideas should be polled, or the specifics of any idea, or the mechanics of this (can I just add a section on the bottom and ping everyone when we're ready to go?) would be welcome.Tazerdadog (talk)17:19, 23 October 2025 (UTC)[reply]
I think that if proposals depend on each other, they should be put together as one proposal instead of having a case where one sub-proposal passes, but the other fails. My preference is multiple polls, each with the idea and a support/oppose-discussion, such that they are all independent proposals on their own merits.
Inactivity is one of the things a lot of editors have decently strong opinions on, I just don't know if it'll be appropriate handling them in same space of proposals. I had planned to flesh out "Inactivity thresholds require 1 admin action within the last 12 months" as a proposal to replace WP:INACTIVITY, as an ideaL.Soni (talk)17:26, 23 October 2025 (UTC)[reply]
Yep, I was going to structure it as 3-6 sections with a support/oppose/discussion. Are any of these proposals dependent on each other/in need of a merge?Tazerdadog (talk)17:33, 23 October 2025 (UTC)[reply]
I would think that the idea of having opponents of the petition play a role in the first round got sufficient support that perhaps something along those lines should be included.Wehwalt (talk)19:55, 23 October 2025 (UTC)[reply]
No, because then you have to have the discussion twice, instead of a short vote on whether there needs to be a discussion followed by the actual full discussion.SarekOfVulcan (talk)20:00, 23 October 2025 (UTC)[reply]
It did get a fair amount of support. How would you word a proposal in a way that puts the idea forward in it's strongest form? I think it needs to have a lot of specifics hammered out (which to be fair is exactly why this section exists).Tazerdadog (talk)20:34, 23 October 2025 (UTC)[reply]
Probably something along the lines that if the admin can show at least as many supporters as the number that signed the petition, that the petition does not advance. If proponents of recall can't even get a majority of those expressing a preference, then probably a substantial number of people are going to support the admin in the second round. Obvious timeframe details to be worked out, I'm just speaking generally.Wehwalt (talk)16:38, 24 October 2025 (UTC)[reply]
"Extended confirmed" participation is not enough. We know that there are malicious accounts that game the system to achieve that status, undoubtedly already more than 25 or 40. We need a better barometer of account trustworthiness in this regard than having made a still relatively small number of edits in a relatively short period of time, which any reasonably clever bot could do.BD2412T19:33, 23 October 2025 (UTC)[reply]
@Staraction: Some number of administrators in the mix would be good, perhaps a minimum of five. I know that this will draw the objection that admins will cover for their own, but a quick perusal ofWP:ANI archives will demonstrate that this really does not happen, certainly not with any kind of uniformity. I would requireall participating editors to have at least a year on Wikipedia (thirty days is basically a waiting period, not a useful measure of participation). An admin subject to the process (or any other editor) should be able to challenge the validity of participation of editors who do appear to have gamed the system to reach an EC number of edits. Finally, to prevent "revenge" voting, I would disqualify from participation any editor who had been subject to an unequivocally good block by the admin sought to be recalled. Admins need to be able to make clean blocks for edit warring and other actual misbehavior without concern that such activity alone will result in votes to recall that admin.BD2412T00:47, 26 October 2025 (UTC)[reply]
One thing I suggested in a previous discussion (I don't remember where) was requiring that all signatories (except the initiator?) be uninvolved with regards to the subject of a petition. Something like, if you were an arbitrator would you have to recuse from a case about the subject? If yes, they you cannot sign the petition. I don't recall the idea getting much discussion last time beyond a few knee-jerk opposes to the idea of excluding anyone from signing a petition.Thryduulf (talk)12:06, 26 October 2025 (UTC)[reply]
I said this in my !vote earlier, but I think that something along the lines of "Having a slowdown at the start, either preventing signatures for the first day or so, or requiring all petitions to be open for the first couple days or so" would be a very good idea. Personally, the way I see it, having a period of a few days at the start, during which only the initiator of the petition could sign, but all editors can discuss the situation, before the signing would begin in earnest, would transform the process into a genuine discussion, as opposed to a petition which can start and end in less than a day. I think that would be all-upside, with no downside. Even those editors whose opinions have been Option A would not be "giving anything up", except maybe some ill-founded sense of urgency. --Tryptofish (talk)21:46, 23 October 2025 (UTC)[reply]
I wonder if there is any possibility of giving bureaucrats some role as a check on the democratic excesses of this process. For instance, bureaucrats could hold a 'cratchat' once the petition is closed to determine whether any extenuating circumstances require further consideration. Perhaps they could refer such cases to ArbCom or some other community process for further examination.Yours, &c.RGloucester —☎00:31, 24 October 2025 (UTC)[reply]
The process that I am referring to is the petition, not RRfA, which might as well not exist. Bureaucrats could be given latitude to pause petitions or otherwise refer to them to ArbCom for review. Some kind of certification process to hold the 25 editors accountable is necessary, especially considering that there may be objections lodged by other parties that require further examination. There is no other situation where 25 votes are sufficient to override any and all other opposition.Yours, &c.RGloucester —☎08:06, 24 October 2025 (UTC)[reply]
The bureaucrats provide the teeth in the current process. Notice that the key clauses use the word "may" not "must". If they thought that a petition was suspect or inadequate then they could just sit on their hands and decline to act. PerWP:NOTBURO, it's not a mechanical process. See alsoWP:IAR which happens to beunder discussion elsewhere.Andrew🐉(talk)08:55, 24 October 2025 (UTC)[reply]
The risk with some proposals to address certain concerns is that they exacerbate other concerns. For example, there are views above that RRfAs are not started because it is felt 25 opposes is a significant hill to climb. Increasing signatures to 40 near doubles that, so it's trading off certainty of the petition with viability of the RRfA. However, the "anytime within 6 months" seems to not raise such a consideration. People will have different periods of reflection, and some may be longer than 30 days (especially if that 30 days includes not only reflection, but also preparation for the questions etc.). I trust bureaucrats to be able to notice keep track of any different passing percentage requirements.CMD (talk)01:57, 24 October 2025 (UTC)[reply]
I already shared by thoughts about the essayhere. I'm not opposed, nor do I think it would change a great deal of the outcome by implementing such an obvious improvement.CNC (talk)18:15, 24 October 2025 (UTC)[reply]
Discussion: Restriction on even discussing caste/community topics under extended-confirmed rule
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.
Hello,
I would like to raise a concern regarding theextended-confirmed restriction that applies to caste and community topics related to South Asia.
The current enforcement practice not only prevents editing by users with fewer than 500 edits but also prohibitsany discussion about factual accuracy or sourcing on talk pages. In effect, even asking, “How can this be verified?” or “Where can I submit a reliable source?” is treated as a violation.
From my perspective, this amounts to acomplete silencing of discussion about certain topics that are important for historical and cultural accuracy. It means that knowledgeable contributors who may not yet have high edit counts — but who have access to reliable sources or firsthand understanding — are unable even to raise questions for others to consider.
I understand that the rule was created to prevent disruption, but the current application seems to suppress genuine participation and verifiable truth. It appears inconsistent with Wikipedia’s foundational principle thatanyone can edit and thataccuracy and verifiability are community responsibilities, not privileges of seniority.
I would like to invite comments on whether this restriction can be refined or adjusted so that editors under the extended-confirmed threshold can at least:
Submit reliable sources for review, or
Ask factual questions on talk pages under supervision or mentorship, rather than being completely prohibited from participating in discussion.
I believe this would protect against disruption while still allowing the encyclopedia to benefit from accurate and well-sourced community knowledge.
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.
Addition:"Administrators may choose to further delay running in an RRFA or administrator election by up to 6 months after the recall petition is closed: they will be temporarily desysopped in the interim upon declaring such an intention. The temporary desysop will be reversed if they retain adminship within 6 months by the means described below: otherwise it is made permanent."
Removal:"; they may grant slight extensions on a case-by-case basis"
Additional background: A recent recall petition and the administrator's subsequent request to be allowed to run in the nextadministrator election, which would start outside the 30-day window specified in the policy, led tothis extensive thread at thebureaucrat's noticeboard. I see no clear consensus thereas to whether the specific delay in this instance is permissible, or as to how to handle this situation in the future. Rehashing this conversation for each subsequent recall seems to me to be undesirable.Vanamonde93 (talk) 19:55, 25 October 2025 (UTC) Addendum: it has been brought to my attention that in this instance there appears to be 'crat consensus to permit an extension.Vanamonde93 (talk)04:05, 26 October 2025 (UTC)[reply]
Support, as proposer. As Inoted at BN, the community clearly intended for administrator elections to be a path for retaining adminship. However, only offering it to those admins recalled within the arbitrary window of 30 days before each call for candidates feels inequitable. Given the tendency for regular candidates for adminship to choose EFA over RFA, I suspect this matter will come up again, and we will have further lengthy discussions about how much delay is permissible, which this proposal will eliminate. It also gives recalled admins more time to choose their path and reconsider their approach before asking to retain the tools, while simultaneously restricting them from taking bad admin actions.Vanamonde93 (talk)19:55, 25 October 2025 (UTC)[reply]
Noting that the emergence of 'crat consensus to allow UtherSG an extended timeframe to run in the coming admin elections only strengthens my desire to enact this, because it highlights the potential for difficulty with longer delays, and creates the possibility that an administrator's popularity will affect the community's perception of the delay. Obviating the need for an extension is the most equitable solution.Vanamonde93 (talk)04:05, 26 October 2025 (UTC)[reply]
Oppose Per the maximJustice delayed is justice denied, it seems best to act expeditiously rather than spin things out. Six months seems quite a long time and I don't like the idea that an RfA candidate would retain the right to a discount on the % required for success for so long when other candidates, who hadn't given cause for complaint, were not given this advantage. If someone is too busy to attend to an RfA then they can just resign and try a regular RfA later at a time of their choosing.
Note also that there's a procedural problem with this RfC.WP:RFC states"There is no technical limit to the number of simultaneous RfCs that may be held on a single talk page, but to avoiddiscussion forks, they should not overlap significantly in their subject matter." This RfC obviously overlaps significantly with theRecall check-in RfC above. Tsk.
Oppose Isupported reconfirmation by election to avoid the confusion of an admin that preferredWP:AELECT needing to resign to access it during their temp desysop. However, like many expressed in the initial approval of this option, we should not extend the admin's lenience at RRFA and AELECT just to ensure an election occurs within their limbo. If someone really prefers elections, they can pursue it like any other user.ViridianPenguin🐧 (💬)22:26, 25 October 2025 (UTC)[reply]
Mostly support. Recall only works when it is fair to all parties, and allowing someone to wait until the next admin election is fair. Allowing crats discretion to extend is fair. Sticking to rigid arbitrary deadlines is not - why would we penalise someone for starting an RFA on the 31st day vs the 29th day due to personal circumstances?Thryduulf (talk)22:27, 25 October 2025 (UTC)[reply]
Weak support (prefer 3 months) I understand and don't oppose the general idea of giving an admin some additional flexibility around the timing of their RRfA. That said, 6 months is a long time; I would support a shorter window for this extension as a first preference.2601:540:200:1850:CC47:61C6:19C6:6028 (talk)22:55, 25 October 2025 (UTC)[reply]
If the goal is to allow admins to use the election process to RRfA, perhaps that could be spelled out as an exemption to a 3-month limit: "The temporary desysop will be reversed if they retain adminshipwithin 3 months by a Request for Adminship (RfA)or at the next regularly-scheduled Administrator Election, regardless of date: otherwise it is made permanent."2601:540:200:1850:CC47:61C6:19C6:6028 (talk)23:02, 25 October 2025 (UTC)[reply]
That's a fair concern. I chose 6 months to ensure the window would always encompass an admin election. EFAs are supposed to be held every 5 months, plus some wiggle room with scheduling.Vanamonde93 (talk)23:02, 25 October 2025 (UTC)[reply]
Support for 2 reasons. First the community has been uniformly happy with giving administrators the option to reconfirm via election. This proposal prevents that from being an empty option 4/5th of the time. Second, it gives an admin the option to step back, address a concern, show some personal growth from the process and then reapply for adminship. The current system of a RRFA in the immediate shadow of a petition-generating controversy feels difficult to pass, and transforms 25 signatures from a statement of concern to a de facto permanent desysop. As a pleasant side effect, this should also give clarity to the crats, who would otherwise have hard decisions anytime a candidate wanted an extension for running in an election.Tazerdadog (talk)23:27, 25 October 2025 (UTC)[reply]
Support, though I agree with S Marshall that "until the next election" is probably the better way to phrase this. We should make it as painless as possible recalled admins, and this is a step towards that goal. The admin is desyopped in the interim, so there is no chance of further misconduct with the tools.HouseBlaster (talk • he/they)01:44, 26 October 2025 (UTC)[reply]
Support Although I agree withS Marshall andHouse that until the next election is the better wording. This is a reasonable proposal that will enact the communities will to allow ALECT for recall by giving more flexibility for Admins to stand at the next election.GothicGolem29 (talk)03:27, 26 October 2025 (UTC)[reply]
Oppose. Six months is a long time on the internet, and would allow whatever issues that led to the recall petition to quietly fade from memory. They of course would still be welcome to run in an election, they would just have to follow the same rules as us normal folk. ~~Jessintime (talk)03:50, 26 October 2025 (UTC)[reply]
Support, for either RRFA or AELECT, with the temp desysop. Worried that the petition makes admins do RfAs at an inconvenient time? This solves that! Worried that the petition was started by a bunch of bad faith socks? Now you've got potentially 6 more months to prove that, bring the evidence to the community, and watch some SPI blocks get droppedbefore they show up to RfA. Worried that your favourite vandal and sock blocking admin had gotten too jaded and wish there was an option between having them ignore community concerns and removing them permanently? Then Vanamonde's administrative leave plan may be just the thing you're looking for! More seriously, I do get the concerns around giving somebody desysopped for cause more time for the community to forget (lol, we're Wikipedians, we dig up books from the 1930s about abandoned settlementsfor fun), and I really do understand that there's an inherent unfairness in turning away a potential new recruit who hit 65% approval rating while letting somebody who was desysopped for cause 180 days ago sail through at 55%, which I really don't like, - but at the end of the day, I don't actuallywant to desyop admins.I want good admins. I believe that incentivizing a long period of reflection and a period of time without tools, where you have to run every single admin action past your peers instead of cutting corners, can only be a good thing.GreenLipstickLesbian💌🦋04:19, 26 October 2025 (UTC)[reply]
Support for both RRFA and AELECT. This was proposedin the earlier discussion, and I wholeheartedly endorse this. This proposal retains accountability for the admins (they lose their bits) while reducing the "temperature" of RECALL. If an admin is sufficiently flawed, the voters will inevitably bring out their mistakes anyway. But this allows any good admins having a "bad time" to have a gap to improve their behaviour and prove themselves to the community. If passed, I also think this should retroactively apply to every admin who resigned instead of RRFA in the last 6 months.Soni (talk)04:32, 26 October 2025 (UTC)[reply]
Very weak support for AELECT I agree with S Marshall that it should be "until the next election." Ioppose for RRfA unless it's only 2-3 months, in which case it would also be avery weak support.fanfanboy(blocktalk)05:06, 26 October 2025 (UTC)[reply]
Weakish Support - This feels like tinkering around the edges of a bad system, but anything is better than nothing in this case. This definitely should not preclude other changes or indeed getting rid of the whole mess of an RRFA system.FOARP (talk)06:07, 26 October 2025 (UTC)[reply]
Support per many others, especially GLL. I'm not sure if the "next election" wording is better than a hard limit (6 months), since the former varies with time, which is a criticism of the current system. It would also mean the time limit for an RfA and AELECT could be different, which is odd.Toadspike[Talk]02:09, 27 October 2025 (UTC)[reply]
Musing on your final point, does it matter if the RFA and AELECT deadlines are different (this is genuine question)? You've also got me thinking about the minimum times between petition closure and the stand/don't stand decision deadline. I'll put my comments about that in the discussion section below.Thryduulf (talk)02:49, 27 October 2025 (UTC)[reply]
Support. I think there probably needs to be some tinkering after the fact to make it more concise and flow better with already there since it's weird to say you have 30 days and then at the end of the paragraph say that actually, it's effectively 6 months (presumably if declared within the 30 days?). I would honestly just make it opt-out instead of opt-in if the point of this is to make it easily for recalled admins to "rehabilitate" themselves to use a criminal justice term. It gives the admin time to schedule a potentially busy week for an RFA/admin election so they can put their best foot forward on how to address the inevitable questions and allows sentiments to cool off for both the admin and by the community. It also allows the admin time to continue to edit and show that they're addressing the issues raised in the recall (e.g. tagging and declining CSDs properly if overzealous CSD deleting was an issue). Maybe if memory is an issue, just make it a link to the recall petition mandatory. --Patar knight -chat/contributions06:46, 27 October 2025 (UTC)[reply]
AsStifle pointed out, specific proposals got a bit lost there, as tends to happen with a general temperature-taking exercise. This proposal isn't limited to AELECT though.Vanamonde93 (talk)18:30, 26 October 2025 (UTC)[reply]
In the voting section, several editors have commented about setting the next admin election as the deadline for an admin who is the subject of a certified petition to decide whether to initiate a new RFA/AELECT with the reduced passing percentage versus a fixed deadline (whether that is the current 30 days or something longer). The next election could be as long in the future as almost 6 months (nominations closed just before the petition is certified) or as short as (in theory) minutes but more realistically a few hours - all of which could be in the middle of the night in the subject's timezone or during some other period where they are unable to look at Wikipedia. This means an admin could go from being in apparent good standing to desysopped with little or even no warning at all. Obviously in extreme cases the crats would uncontroversially use their discretion and not insist on the literal meaning of "next election" (doubly so if there was any indication of gaming the timing of the petition or its closure). However given the ongoing discussion about discretion in UtherSRG's case, if we're going down the movable deadline we need to put some guidelines in place for the minimum time before the deadline. Hopefully even those who see nothing wrong with the current system can agree that 5 days or less is unarguably not fair on the admin, but what if the close of nominations is 29 days after the petition was certified? If those choosing RFA get up to 6 months, does that mean that's the minimum someone choosing AELECT gets? With the possible exception of those opposed to any recall procedure in principle, I can't see anyone agreeing that 11 months (6 months minimum, plus up to 5 further months for the next election) is within the spirit of the process. Where in the middle of the extremes does consensus lie though? It needs to be long enough to enable the admin to make a considered decision and, if they choose to stand, to write a good nomination statement but not so long that an admin who is actually and actively causing harm to the project can be reasonably curtailed. I should stress that this is explicitly not trying to influence consensus either way regarding this option, I'm literally just surfacing questions that need answers before it could be implemented.Thryduulf (talk)03:22, 27 October 2025 (UTC)[reply]
It is largely to avoid these sorts of questions that I proposed an unchanging six month window that should always encompass an admin election that's more than a few hours after recall.Vanamonde93 (talk)04:48, 27 October 2025 (UTC)[reply]
AELECT is too young a process to know how often it will end up running over time.
Thryduulf, I might be able to support a year-long window. It might be nice if de-sysopped folks took a little while to reflect on what went wrong and whether they want to re-commit to a community that just rejected them. A decision made while emotions are still running high might not be the best for anyone.WhatamIdoing (talk)06:28, 27 October 2025 (UTC)[reply]
Leaving programming code and substituting Anchor templates inside section headers
I feel a wider audience is needed to sort out a rather tangled and confused issue.
Back in August and September the guideline on how to insert{{Anchor}}s into section headers changed to prescribe substitution:WP:ANCHORSUBST. These changes were also incorporated into policy:MOS:SECTIONANCHOR. To meUser:FaviFake is bludgeoning through a very unwelcome change, and generally acting as if this is a done deal. These changes werenot preceded by a consensus-building discussion. FaviFake has repeatedly argued as if his newly made changes are the "status quo", as if a lack of consensus should be taken to mean his version should be left intact.
Substitution has a number of advantages and disadvantages. Wwhen I (and many others) reacted to one of the disadvantages (which to me is a fatal flaw); that substitution leaves ugly programming code (=== <span></span></span>Header name ===) with the argument that we surely aren't greeting newbie users user hostile programming coderight in article text (visible when editing the article), several long (very long) discussions erupted, where this disadvantage was counted to be just one out of many points to consider, rather than an immediate grounds for reversal. So now I am inviting you all to engage in whatever way you feel appropriate:
@CapnZapp This is the third discussion you've opened about this matter;the previous discussion was still active as of yesterday and received over sixty comments. According to therelevant talk page guideline, one should[a]void starting the same discussion on multiple pages, which fragments discussion.There are many inaccuracies in your message, which I hope are unintentional. Most importantly, the guidelines (specificallyMOS:RENAMESECTION,MOS:SECTIONANCHOR,MOS:HEADINGLINKS,WP:TARGET, andWikipedia:WikiProject Automobiles/Conventions § Section anchors) have been recommending substitution for many, many years, even before I joined Wikipedia. In the other ongoing discussion at the MOS talk, many editors have explicitly supported substitution over transclusion, so I don't understand why you're suggesting I'mbludgeoning through a very unwelcome change. The disadvantages of each method are listed atWP:ANCHORSUBST and they are the reason the guidelines have recommended substitution for such a long time.If you wish to radically change them by recommending transclusion instead, then I suggest you clearly say so.FaviFake (talk)15:06, 26 October 2025 (UTC)[reply]
WP:ANCHORSUBST does not list the disadvantages of substitution. For example, it doesn't mention the risk that substituted anchors will be deleted, either as well-meaning cleaning away of stray HTML that's presumed to be the product of some bug, or quite unintentionally because they're completely invisible in VE.NebY (talk)15:19, 26 October 2025 (UTC)[reply]
Would you strike your assertion above thatThe disadvantages of each method are listed at WP:ANCHORSUBST, given that WP:ANCHORSUBST only lists disadvantages of different locations for substitution, and does not list any disadvantages of using substitution at all?NebY (talk)16:06, 26 October 2025 (UTC)[reply]
The rest of the sentence readsThe disadvantages of each method are listed at WP:ANCHORSUBSTand they are the reason the guidelines have recommended substitution [...] (emphasis supplied). I think it's clear I'm only referring to the disandvantages of theother methods; guidelines don't recommend a practice based on the practice'sdisadvantages.FaviFake (talk)16:14, 26 October 2025 (UTC)[reply]
What's the community consensus on articles consisting mosly of data?
For example,Demographics of Germany (special:permalink/1318928375) - there are 23 tables in this article, 4 description lists, 3 MediaWiki charts, and countless images of population pyramids/graphs/maps/etc.
The answer depends on which subject you're talking about.Less than Zero (soundtrack) looks like mostly data to me (plus ~150 words in the lead), and I'd expect people to scream if I suggested that it's aWP:NOTDATA violation to have a page that is mostly a list of data (e.g., how many seconds long each song is).
