The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.
If you wish to propose something new that is not a policy or guideline, use Village pump (proposals). Alternatively, for drafting with a more focused group, consider starting the discussion on the talk page of a relevant WikiProject, the Manual of Style, or another relevant project page.
For questions about how to apply existing policies or guidelines, refer to one of the many Wikipedia:Noticeboards.
If you want to inquire about what the policy is on a specific topic, visit the Help desk or the Teahouse.
This is not the place to resolve disputes regarding the implementation of policies. For such cases, consult Wikipedia:Dispute resolution.
Latest comment: 7 days ago93 comments46 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Support for this proposal reached 60%, so I think it has rough consensus. Supporters felt it would streamline the bureaucracy, and treat all desysopped admins fairly and not limit their options due to an accident of timing. Opponents generally felt it was OK to use the regular thresholds, and one even wanted to make a 6-month desysop period mandatory.
A substantial number of supporters asked that the deadline be changed from 6 months to the next election. This future-proofs the deadline in case there are changes to the election schedule, and makes the deadline to choose RRFA or election the same for a given candidate. Then there was discussion that bad timing could mean someone is permanently desysopped and miss an election window all in the same day. A sensible fix was proposed, to make the deadline "30 days or the next election, whichever is later". A couple of participants had divergent suggestions, but if there's no objection from the majority of supporters who didn't express a preference between 6 months vs. the next election, I'll incorporate these amendments in the close. Therefore the language to be added (which I clarified in response to questions asked in this RFC) is:
"Administrators retain the right to run in a delayed RRFA or administrator election with the reduced thresholds described below until the time of the first admin election after the 30-day post-close window (whether they choose the election or the RRFA). They will be desysopped upon declaring such an intention or at the end of the 30-day post-close window. After this longer period expires, thresholds for re-gaining adminship become the same as for new candidates."
And removed:
"; they may grant slight extensions on a case-by-case basis"
Let me know if I messed up that re-wording or you really did want a hard 6-month deadline!
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 next administrator election, which would start outside the 30-day window specified in the policy, led to this extensive thread at the bureaucrat's noticeboard. I see no clear consensus there as 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 I noted 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 maxim Justice 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 avoid discussion forks, they should not overlap significantly in their subject matter." This RfC obviously overlaps significantly with the Recall check-in RfC above. Tsk.
Oppose I supported reconfirmation by election to avoid the confusion of an admin that preferred WP: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 adminship within 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 with S Marshall and House 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 dropped before 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 settlements for 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 actually want 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 proposed in 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." I oppose for RRfA unless it's only 2-3 months, in which case it would also be a very 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
Support principle but not for 6 months until RRFA. It's reasonable to allow the re-appointment discount for a little longer, giving the admin time to consider what happened, whether they want the bit and how to go about it. But per S Marshall and others, only until the next election if choosing AELECT and only for 3 months, not 6, for an RRFA. We do, after all, want memories of the events, discussions and petition to be reasonably fresh and comparatively accurate (which may favour the candidate or may not). Three months also happens to be a little more than the average time from a petition passing to the next AELECT, on current timing. NebY (talk) 16:41, 27 October 2025 (UTC)Reply
See my comments below about "until the next election" - that could be just under 6 months away, it could be minutes, it could be anywhere in between. Thryduulf (talk) 17:32, 27 October 2025 (UTC)Reply
Yes, I'd seen those comments. That's three months on average, but I also note Vanamonde's comment above, "EFAs are supposed to be held every 5 months, plus some wiggle room with scheduling.". NebY (talk) 17:43, 27 October 2025 (UTC)Reply
"On average" is fine in the abstract but not when it comes to an individual administrator. What matters then is how long there is until the actual next election - if nominations close imminently that's very very different to the next election being 2-5 months away. Thryduulf (talk) 17:55, 27 October 2025 (UTC)Reply
Perhaps you haven't read my full support comment. I do support allowing the discount at the next AELECT. However, I don't support allowing the discount for an RRFA for up to 6 months and support up to 3 months instead, for the reasons I stated. I then noted - and it's regrettable if my noting it misled you as to the previous points - that 3 months is also (a little more than) the average discount period created by allowing the discount at the next AELECT. NebY (talk) 18:07, 27 October 2025 (UTC)Reply
I have read your full comment, and I still think that you're missing the point that I'm making. I cannot think how to say what I've been saying any differently though, so I'm just going to hope someone else can. Thryduulf (talk) 18:18, 27 October 2025 (UTC)Reply
I view this as largely academic (since starting with 25 opposes dooms a RRFA from the start, and I suspect that's by design); but it doesn't make sense for there to be a longer possible wait time if you choose to use the venue that, so far, has always resulted in much less scrutiny. —Cryptic16:48, 27 October 2025 (UTC)Reply
Support per Tazerdadog. This gives all recalled administrators the option of running in the next WP:AELECT rather than being forced to go use WP:RFA as their reconfirmation process unless they get lucky, and it also lets both the recalled admin and the community take a step back, reflect, and approach the RRfA after some introspection, rather than being forced to do it immediately after some controversy. Mz7 (talk) 04:53, 28 October 2025 (UTC)Reply
To avoid confusion regarding whether or not the admin is being elected or re-elected when their first request used the open viewpoint process, personally I suggest staying with the term re-request for adminship, which can proceed either through the open viewpoint process, or the election (or secret ballot) process. isaacl (talk) 00:44, 29 October 2025 (UTC)Reply
I would say the best way to avoid confusion is to have REELECTS the term for admin elections and RRFA be the term for RFA. This is because it matches each process better with RRFA referring to the process involving RFA and REELECT referring to the process with the Admin Elections. GothicGolem29(talk)15:53, 29 October 2025 (UTC)Reply
Yes, but that isn't a compelling reason to reduce accountability. RfA will be difficult whether it happens sooner or later. Delaying it only serves to remove it from the reasons Recall was initiated and certified and those reasons should be a key component of those processes. Iggy pop goes the weasel (talk) 14:57, 29 October 2025 (UTC)Reply
those reasons should be a key component of those processes. Yes and no. They should be a component of the processes, but only in the context of their adminship as a whole. "Occasional mistakes are entirely compatible with adminship" is an oft-repeated principle at arbitration, but finding 25 signatories to a petition in the immediate aftermath of an isolated controversial decision is likely going to be very easy, so there needs to be a period to allow tempers to cool and ensure that the ReRFA is a fair reflection of the admin not just of one incident. However, it is equally likely that the cause for a petition is ongoing chronic inappropriate adminning (with or without an easily-pinpointable final straw), and in that case there shouldn't be too long a gap between petition and ReRFA. This means that the timescale needs to be a balancing act between these competing directions and also remain fair to both petitions and the admin. I don't think 30 days is long enough, but contra WAID I do think a year is too long. If admin elections were not a thing, I'd probably be suggesting 3 months, but admin elections are a thing and the community consensus was strongly in favour of both a 5-month schedule and allowing admins who are the subject of a certified recall petition to choose to stand in an election. We cannot control when petitions are certified relative to the admin election schedule, so to ensure that the community consensuses are respected without unfairly forcing admins to stand immediately after a petition closes we have to allow the election interval plus circa three weeks, which in round numbers is 6 months. Thryduulf (talk) 15:37, 29 October 2025 (UTC)Reply
Nothing under the current system prevents the context of their adminship as a whole being discussed or taken into account at RRfA or AElect, two processes by which all are able to identify their support or lack thereof. The discussion sections of Recalls have proven this. Iggy pop goes the weasel (talk) 19:39, 29 October 2025 (UTC)Reply
It's correct that nothing currently prevents that, but it does discourage that. The discussion sections of recall are irrelevant by design. Thryduulf (talk) 19:48, 29 October 2025 (UTC)Reply
Oppose - six months is too long, and enough with coddling troublemaker admins. They can run for RFA anytime they want, and they can stand in any election. 30 days at a reduced threshold is already a lot of leeway. Nobody else whose perm gets pulled gets this kind of indulgence. Levivich (talk) 16:01, 29 October 2025 (UTC)Reply
It's coddling because they get the benefit of the lower pass thresholds six months later instead of just 30 days later. I appreciate that the proposal would prohibit tool use during the six months, I think that aspect is good of course, but still, six months is too long. If an admin wants to run six months after their recall petition is certified, they can just do so, at the normal thresholds. I think it's coddling because you're giving them a six month window for a full community review of their actions while enjoying the lower threshold privilege. Nobody gets this. I didn't get to delay any of the arbcom cases where I was a party by six months to a time that was convenient for me. The last one happened over Christmas and New Years, nobody gave a crap that this was bad timing. I get having a little leeway like 30 days, but I don't see why admins should get so much leeway as six months. Imagine an ANI thread and the reported editor says "can we talk about this in six months? I promise not to edit the article in the meantime." Nobody gets this privilege on Wikipedia, no reason to give it to admins. Levivich (talk) 16:59, 29 October 2025 (UTC)Reply
It isn't accurate to say nobody gets this "privilege": I can think of at least three admins who received similar grace periods, when desysop cases were opened by ARBCOM and suspended until such a time as the admin chose to resume them. It's not accurate to say we don't extend the privilege to editors either. We have certainly closed noticeboard reports based on a voluntary commitment to stay away from a particular conflict. Now maybe you think that's coddling too, and I won't argue with that. But there's certainly precedent. And I will emphasize for anyone following along at home that the "privilege" is only the lower passing threshold, not a retention of the mop. Indeed the proposal will likely reduce the length of time that an admin can hang on to the tools after a successful recall petition, by obviating the scenario we just had and limiting that grace period to 30 days plus the length of RRFA/AELECT. Vanamonde93 (talk) 19:21, 29 October 2025 (UTC)Reply
Oppose I don't believe that AELECT has proven itself to be fit for the task of the recall system. It produces admins, but I don't really think the evidence is there that the marked lack of scrutiny isn't a problem. Affixing two new systems to each other isn't a good idea. Stick with 30 days for an RFA. Parabolist (talk) 22:35, 29 October 2025 (UTC)Reply
@Parabolist: AELECT is already an option. But only if the 30-day window after the closure of a recall petition overlaps with the call for candidates of an AELECT or - as happened this week - the bureaucrats grant a discretionary delay. I am seeking to abolish that discretionary delay, which is primed for inequities. Vanamonde93 (talk) 00:47, 30 October 2025 (UTC)Reply
Right, but extending this window essentially guarantees the choice of AELECT. The inequity is that poorly timed (by my personal standard) recalls can allow for less scrutiny in how the tools are reconfirmed. So this solution does solve that, but by making everyone have the worse outcome. For the record, I'm against the crats allowing the extension they're allowing in this case, so I'm at least consistent! Parabolist (talk) 00:58, 30 October 2025 (UTC)Reply
Acknowledging that our data about AELECT is still limited, I genuinely do not think admins would necessarily choose to participate in AELECT over RFA. As I see it the major difference is in voter anonymity. It's an open question whether editors would be more likely to support a recalled admin if they are anonymous. I suspect it depends on the popularity of the admin and the nature of their transgressions. You're entitled to your opinion of course. Vanamonde93 (talk) 16:37, 30 October 2025 (UTC)Reply
Support mainly because if I had had the chance, I'd have chosen an administrator election instead of the classical RfA process, and because I'd prefer a re-election to a re-RfA. Whether this can be discounted as a biased vote with a conflict of interest, or given additional weight as one made with experience others lack after having experienced both RfA and ACE, I don't know. ~ ToBeFree (talk) 01:38, 30 October 2025 (UTC)Reply
If they want the lower threshold for success that the community consensus says they are entitled to, then they can only do this if an admin election happens to be scheduled within about 30 days of the petition being certified. As elections only happen every 5 months, that's only a (very approximately) 20% chance. Thryduulf (talk) 04:06, 30 October 2025 (UTC)Reply
Though given the level of discretion hasn't been said fully as far as I know that does mean the 20% figure you gave could change a fair ammount(to the point where I would say there isn't a percent even very aproximately given the level it could change.) GothicGolem29(GothicGolem29 Talk)16:37, 30 October 2025 (UTC)Reply
The level of discretion is not formally bounded, but given the comments at BN regarding the current case I'd be very surprised if it were extended much further. For the sake of argument, if we assume that the crats said an extra 20 days was acceptable but 21 days was not (I think this is more generous than it would be in reality) then that gives a 50-day window during which admins can nominate themselves for AELECT with the reduced threshold. The duration of the nomination window is not specified in the policy but it has been 7 days every time so far. So the 50-day and 7-day windows need to overlap, and let's generously assume that every part of the 50 days is equally useful (in reality it won't be due to real life commitments, not having prepared a nomination statement in advance, etc). The 50 day window can occur at any time, the 7-day window occurs only once every 5 months - so a maximum of three times a year.
If my maths is correct (and I'd really like someone to double check if it is) then there are 414 possible 50-day windows with at least 1 day in a non-leap year. Only 21 of those overlap with a nomination window, which is actually very slightly over 5% - and thats with very generous assumptions. Thryduulf (talk) 17:49, 30 October 2025 (UTC)Reply
Oppose and propose instead that any admin who receives 25 signatures for RECALL is immediately desysopped, and prevented from running for admin again until 6 months has passed, after which they may run again for admin (with no reduced pass threshold). Tewdar 15:01, 30 October 2025 (UTC)Reply
The problem with this idea is that 25 signatures is a very low threshold for an immediate desysopping, especially when there could potentially be hundreds of other editors who disagree. I think it's the perfect compromise to have a relatively small number of editors be able to *trigger* the recall process, but then give an opportunity for an RRFA or AELECT. While I acknowledge its shortcomings, the current arrangement is far superior to your suggestion, in my opinion. Mr. Starfleet Command (talk) 03:57, 9 December 2025 (UTC)Reply
Oppose per Levivich. The current system does not need amendment. If a former admin wants to request re-adminship after 30 days, they are welcome to do so at RfA (under the regular thresholds). Ajpolino (talk) 19:07, 1 November 2025 (UTC)Reply
Oppose. If you prefer AELECT over RfA, then you can wait, just like everyone else. If not having admin rights for a few months is unacceptable for you, then you should not be an admin. Thebiguglyalien (talk) 🛸02:13, 2 November 2025 (UTC)Reply
Sorry, I could've been clearer. My opinion is that a desysopped admin, even "temporarily", is just a regular editor and I've yet to be convinced that special considerations need to be given. Thebiguglyalien (talk) 🛸16:22, 2 November 2025 (UTC)Reply
Support One of the pluses of RfA is you can choose when it happens. RfA is one of the most stressful things I ever did (on par with taking the bar exam). This is a volunteer project afterall, and we are struggling to recruit and keep editors. Giving folks a little more leeway to choose a time that fits their life best is humane and sensible. CaptainEekEdits Ho Cap'n!⚓20:45, 2 November 2025 (UTC)Reply
Support I find it a little weird that whether admins get to run in an election with the lower threshold depend solely on whether they happened to be recalled at the right time. While I'm not suggesting anyone has done so, it could easily lead to concerns an editor has chosen to start the recall precisely at a time to prevent an admin chosing election. More significantly, one of the concerns expressed by those opposed to the way recalls are currently working is that a successful recall means that the admin is going to be permanently desysoped in part because their chances are already low and in so much as they might have a chance with the reduced threshold, the stress of doing so when the former admin is effectively required to run an RRfA in an emergency rather than at a time of their choosing means the reduced threshold is basically pointless. Frankly, I'd prefer an immediate desysop upon successful recall and the admin then getting 6 months to decide whether to try to confirm their adminship than the current system (by which I mean they have to start an RfA or enter an election). While I appreciate even under the proposed change if the timing is off an admin might still have to run an election in an emergency which isn't ideal it strikes a decent balance although I wouldn't be opposed to extending it to 9 months to give an admin the chance to not have to run for an election in an emergency. Although I appreciate this does mean memories of the problems with an admin will be less fresh, I still feel it's a decent balance noting also most recalls seem to have been for longer term problems. Nil Einne (talk) 13:26, 10 November 2025 (UTC)Reply
Support Allows admins an additional choice in how to proceed. If actions that led to a recall petition are very problematic, there are other options we have as a community. --Enos733 (talk) 16:43, 17 November 2025 (UTC)Reply
Support Having an explicit procedure in place for the extension is better than the approach used for the most recent recall petition. I prefer 30 days or the next admin election, whichever comes later per Mr. Starfleet Command below to a blanket six-month period. mdm.bla02:54, 19 November 2025 (UTC)Reply
As Stifle 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
I don't fully understand the implications. Are admins that have been defrocked by recall barred from future RfA if they are not re-confirmed within the time window? If not, what would be the purpose of the additional phrasing regarding temporary etc.? It sounds needlessly complicated. ~2025-31522-63 (talk) 20:01, 22 November 2025 (UTC)Reply
Thanks for elaborating, Mr. Starfleet Command. I read your comment below and on reflection, with every compassion I have, I'm increasingly leaning towards what I said above - let me elaborate further: that (1) recall should be solidly designed in such a way that (2) we don't feel we need to give failed admins soft landings, and (3) we, as a community, commit to promoting admins that can act and communicate better than the ones that have been recalled. Perhaps more importantly, incentivising quick re-application takes away the time for reflection that the recalled person may need. ~2025-35544-03 (talk) 22:52, 24 November 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
Small point: it might be better not to frame recall petitions as rejection by the community; formally speaking at any rate, that would come at an RFA or AELECT. Seeing a petition that way might even be making emotions run higher. Otherwise yes, taking time to take stock should be encouraged, assisted and if possible normalised. NebY (talk) 12:49, 27 October 2025 (UTC)Reply
How about this: the deadline is 30 days or the next admin election, whichever comes later. That way, an admin is always guaranteed at least 30 days time to initiate an RRFA, but also has the option to stand for AELECT if they so choose. Desysopping would still occur after just 30 days. Mr. Starfleet Command (talk) 00:21, 18 November 2025 (UTC)Reply
I would accept this idea over the status quo, but it's still more complex wording than what I suggest, and has the effect of making the timing of an RRFA contingent on the timing of an EFA. Vanamonde93 (talk) 22:18, 19 November 2025 (UTC)Reply
I don't understand what this would accomplish: since the editor would be desysopped after 30 days, they'd be a non-admin editor entitled to run during the next AELECT like any other editor even without this change in wording. Schazjmd(talk)22:49, 19 November 2025 (UTC)Reply
@Schazjmd: The difference would be that, with this wording, they would be able to run with the lower passing threshold, whereas otherwise they would be subject to the normal threshold. Whether this is desirable is a separate question, and IMO should be the main topic of discussion here. Mr. Starfleet Command (talk) 01:10, 20 November 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.
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.
This request for comment proposes deprecating the Associated Press Stylebook as a naming authority within WP:USPLACE. The current guideline ties certain U.S. city article titles to whether the AP Stylebook lists them as not requiring a state name, a practice that dates back to Wikipedia’s early years. However, this external dependency conflicts with Wikipedia’s self-governed policy hierarchy and with the way other countries’ naming conventions are structured. No other national convention relies on an outside publication to determine article titles. This discussion invites editors to consider whether Wikipedia should instead base U.S. city naming solely on internal principles such as WP:TITLE, WP:COMMONNAME, and WP:PRIMARYTOPIC, supported by verifiable usage data such as pageviews and clickstreams.
Proposal
Deprecate the Associated Press Stylebook as a naming authority within WP:USPLACE. Future decisions about the inclusion or omission of state names in U.S. city article titles should be based solely on Wikipedia’s internal policies and verifiable usage evidence.
Replace the existing paragraph:
"Cities listed in the AP Stylebook as not requiring the state modifier in newspaper articles have their articles named 'City' unless they are not the primary topic for that name."
with:
"Cities are titled by the most common and unambiguous name used by readers and reliable sources, in accordance with WP:TITLE and WP:PRIMARYTOPIC. The inclusion or omission of a state name is determined by actual disambiguation need, not by external style guides.""
Add an explanatory note:
"References to the AP Stylebook in earlier versions of this guideline are deprecated. Wikipedia naming conventions should rely on internal policy and verifiable data, such as reader behavior or reliable source usage, rather than on external editorial manuals."
Background
The current wording of WP:USPLACE incorporates the Associated Press Stylebook as part of its reasoning for which United States cities are exempt from the “Placename, State” format. This reliance on an external publication is unusual within Wikipedia’s system of self-contained policies and guidelines. Other country-specific naming conventions (for example WP:UKPLACE, WP:CANPLACE, WP:NCAUST, WP:NCIND) rely only on internal policy principles such as WP:TITLE, WP:COMMONNAME, and WP:PRIMARYTOPIC.
Rationale
The AP Stylebook was created for journalistic brevity, not encyclopedic clarity. Wikipedia’s naming standards are designed for reliability and reader intent, not for newspaper copy.
No other country’s naming convention cites an external editorial manual as authority. The United States should not be an exception.
The AP list of cities without state modifiers is dated and arbitrary, reflecting mid-20th-century newspaper familiarity rather than modern global recognition.
Wikimedia’s pageview and clickstream data provide transparent, empirical evidence of what readers mean when they search for a city name.
This change aligns WP:USPLACE with WP:TITLE and WP:PRIMARYTOPIC, ensuring that the same principles apply worldwide.
Intended outcome
Consensus to remove or deprecate references to the Associated Press Stylebook from WP:USPLACE and clarify that U.S. city naming follows the same internally governed, data-based principles used for other countries. TrueCRaysball💬|✏️18:07, 10 November 2025 (UTC)Reply
I strongly oppose something as broad as The inclusion or omission of a state name is determined by actual disambiguation need, not by external style guides. While I may agree with the principle that we needn't rely specifically on only the AP for which cities have standalone names, I believe nearly all US cities should still include the state name in the title, even if the city is the primary topic for that name or disambiguation isn't needed. Even if we could retain our discretion to deviate from the AP in particular in some circumstances, I see no issue with the current practice and this method helps avoid pointless move debates while maintaining consistency. I'd rather extend this practice of including a state name in the title to other countries, rather than the other way around. Reywas92Talk18:31, 10 November 2025 (UTC)Reply
Isn’t that the entire point of a Village Pump discussion? To craft something better that we can all agree to through consensus? The AP standard is written for journalists, not encyclopedias, and in my view it has no place in our naming conventions. TrueCRaysball💬|✏️19:21, 10 November 2025 (UTC)Reply
I've shared my opinion, others are welcome to contribute. I see no strong reason to change the current consensus, and even if the wording were changed not to prioritize just the AP, I strongly believe we should not start proposing to remove state names from other titles, which would be a huge waste of effort over something that works fine as it is. Reywas92Talk19:31, 10 November 2025 (UTC)Reply
Oppose per Reywas. This reads like a solution in search of a problem. I have no objection to deviating from the AP in individual cases if someone can demonstrate a benefit from doing so, but as a general rule everything is working fine as it stands and I see no benefit to changing it after this many years without problems. Thryduulf (talk) 19:51, 10 November 2025 (UTC)Reply
Oppose – There is no evidence of a problem with the existing scheme. It is clear, a long-standing consensus, and based on a reliable source. Implementing this change will result in the need to reconsider the article titles of thousands of pages, for no good reason, resulting in a waste of valuable editor time. See WP:TITLECHANGES and WP:BROKE. What will the reader gain from this change? As far as I can see, nothing. If the text of the guideline needs to be rewritten, that can be arranged: WP:CONSISTENT is one element of our article titles' criteria. As mentioned above, it is already possible to deviate from this guideline when consensus exists. Yours, &c.RGloucester — ☎00:32, 11 November 2025 (UTC)Reply
Oppose Regardless of its intent, the AP Stylebook is still reputable, and our usage of it to help inform our guidelines, as others have stated, has not caused any issues as far as I'm aware. Lazman321 (talk) 04:08, 11 November 2025 (UTC)Reply
Comment - Several of the opposes here rely on "if it ain’t broke, don’t fix it" reasoning or the assumption that editors can already make exceptions. However, that ignores the reality of how this actually functions in practice.
Every city move discussion in the United States is automatically opposed or SNOW-closed on the basis of WP:USPLACE, even when strong evidence and consensus-building attempts are presented. That means editors cannot meaningfully discuss exceptions. The policy itself shuts down the conversation before it can happen. My own RM of Orlando, Florida from last year is one of many examples.
Additionally, the claim that "it works fine" does not hold up when data says otherwise. Clickstream analytics show that thousands of readers type terms like "Orlando" expecting to reach the Florida city, only to land on a disambiguation page and have to click through. That is, by definition, a navigation failure. It proves the system is broken for readers. Not just editors.
The workload objection is also a red herring. A simple "grandfather clause" could apply: existing titles remain until a discussion is individually initiated. No one is proposing a mass retitling campaign.
Finally, the AP Stylebook is written for journalists, not encyclopedias. Its inclusion in our naming conventions has no policy basis and should not function as an unchallengeable authority. We have robust internal guidelines like WP:COMMONNAME and WP:PRIMARYTOPIC that already handle naming consistently and logically without relying on external style manuals. TrueCRaysball💬|✏️04:46, 11 November 2025 (UTC)Reply
That your proposed move was rejected does not indicate that anything is amiss with the guideline. What it means was that you failed to provide persuasive evidence of a 'good reason' to change the article title per WP:TITLECHANGES. In fact, in that RM, you failed to provide any evidence to support your claims, at all. I can see that you are now engaging with empirical data, such as Clickstream analytics. If you think you can make a better case now per WP:PRIMARYTOPIC, you are free to open a new RM discussion. Yours, &c.RGloucester — ☎05:46, 11 November 2025 (UTC)Reply
I think the current guidelines would suggest that the proper RM if you're right about PTOPIC would be Orlando → Orlando (disambiguation), with Orlando turned into a redirect to Orlando, Florida. That way all the readers expecting to reach the city will get there right away, and a hatnote at the city page could send confused readers back to the dab page. It looks like this was last discussed here in May and there was consensus that the city is not the primary topic. Firefangledfeathers (talk / contribs) 14:29, 11 November 2025 (UTC)Reply
Replying here since I realize my oppose was a little snippy and I think this comment makes it clearer what you are getting at. My understanding is that you feel that WP:USPLACE is causing undue knee-jerk opposes to RMs like Orlando, Florida -> Orlando that you think would benefit the wiki. But the actual RFC reads like you asked ChatGPT "write me an RFC that will stop wiki editors from using WP:USPLACE to oppose my RM". That's probably why this RFC is getting so many opposes - we don't like having our time wasted. It would be more helpful to present clearer arguments at your RM next time (maybe share some of this clickstream data you mention). -- LWGtalk17:32, 14 November 2025 (UTC)Reply
Oppose I think there is benefit from nearly all US places having the state added. We also benefit from not discussing (too often) which cities should or shouldn't be exempted, which would definitely happen more if we pull in the list locally. I'd be more likely to support removing the AP list exemption and move the 29 cities to names with states. As mentioned above, primary redirects could still exist for cities whose names are the primary topic for that term. Skynxnex (talk) 19:10, 11 November 2025 (UTC)Reply
One, no one is suggesting removing the "city, state" format. I suggested moving the standard to internal review/consensus for which use the state and which don't instead of relying on an external style guide. Two, the latter suggestion only makes sense if you're gonna do that with every country that also is broken down into counties or states, or even just a simple "city, country" format. Consistency is key here and is the entire premise of my starting this RfC. TrueCRaysball💬|✏️20:33, 11 November 2025 (UTC)Reply
I never said anyone was proposing removing the City, State format. But given we have only 29 localities special cased currently (DC is its own thing), to me the implication is very strongly that this proposal is to allow more places to be named by just their name without state added.
I don't think that all countries need to have consistent rules for populated places. I think the US model might be good to apply to places like Canada and Australia (maybe others?) where the state-level subdivision matters more than in some countries. But in some places I believe it's generally seen as less of a part of the identity/name of the populated place. I think consistency within a country is more important and why I idly mentioned as both a reason to oppose this and maybe weigh people's willingness to rename things like Cleveland to Cleveland, Ohio. I doubt that is likely at this time.
I think you providing some examples of specific US place article titles that would be improved by this change may be helpful. But Myceteae's comment describing reasons why the status quo is probably better helps make specific examples somewhat unneeded. Skynxnex (talk) 01:57, 12 November 2025 (UTC)Reply
Oppose. The current guidance is not broken and does not need fixing. Appealing to an external style guide is not inherently at odds with WP policy and practice. Much of the content in our naming conventions and MOS reflects and is consistent with external style guides and accepted conventions, even when these are not explicitly cited. Furthermore, consensus to adopt a particular external standard is valid. We do this explicitly in several places, such as (the admittedly controversial) MOS:FRENCHCAPS, and numerous naming conventions that refer to specific authoritative bodies to source appropriate article such as WP:NCFILM and WP:MEDTITLE. The whole section WP:USPLACE does incorporate local (US) customs, as does the entirety of Wikipedia:Naming conventions (geographic names). This does result in discrepancies between how cities in different countries are handled, especially in English-speaking regions where WP:ENGVAR considerations prevail. The AP Style guidance is authoritative, appropriate, and represents a specific application of broader guidance like WP:COMMONNAME to a particular subject area. Referring to a respected external source simplifies decision-making, harmonizes article titles, and prevents endless battles about when to drop the state. —Myceteae🍄🟫 (talk) 00:06, 12 November 2025 (UTC)Reply
This RfC fundamentally misunderstands how USPLACE operates. I don't know if it is a misreading of the guideline or something to do with an llm, but it is backwards. USPLACE ignores WP:PRIMARYTOPIC, setting the standard as "Place, State". The AP-exceptions are the only place where WP:PRIMARYTOPIC is considered. The proposed change leads to the opposite impact that the rationale seems to want, so I suggest the RfC is closed as it cannot as proposed actually lead to a consensus for change. CMD (talk) 04:09, 12 November 2025 (UTC)Reply
Oppose I agree with RGloucester that this would lead to a waste of editor time for little to no benefit to readers, with Myceteae that there is no procedural problem with the current situation, and with CMD that this RFC doesn't seem to have a coherent purpose. -- LWGtalk16:00, 14 November 2025 (UTC)Reply
Sympathize. I agree that the AP Stylebook is a pretty arbitrary way to determine which U.S. cities play by WP:PRIMARYTOPIC and which are exempt. I don't recall how I've !voted in the past, but it does seem like a cleaner solution would be to strike the AP stylebook, and either (1) apply WP:PRIMARYTOPIC as normal, or (2) require City, State for every U.S. city. If the argument is that "City, State" is the dominant convention, then there is no reason to have Baltimore coexist with Nashville, Tennessee. It should be Baltimore, Maryland, with Baltimore as a WP:PRIMARYREDIRECT. Or, allow Nashville as an article title (since it already redirects there). Either way would go a long way to eliminate the perennial move requests and RfCs like this one. The status quo is inherently unstable. But it's also very ingrained in Wiki-world. Dohn joe (talk) 21:49, 14 November 2025 (UTC)Reply
Oppose. Wikipedia follows usage in reliable sources. Sometimes usage is unclear but in this case the AP list provides explicit guidance for usage in U.S. RS for U.S. cities. It’s unusual but not a problem. That said, I’ve long held US city article titles should be treated like all others: disambiguate only when necessary. The name of any city is just its name, not including the state name. It’s misleading and endlessly confusing to include the state name when it’s not needed for disambiguation. Redirecting a base name of any US city to a title disambiguated by state name sets a contradictory and confusing standard, leading to countless unnecessary conflicts and debates. Thankfully, most other topic-area-specific naming conventions have been refined to disambiguate only when necessary, but USPLACE remains an unfortunate exception. —В²C☎13:08, 16 November 2025 (UTC)Reply
I understand the impetus to do away with WP:PRIMARYTOPIC, but I think most proponents overlook a key benefit of the policy. The benefit is what it communicates to users about common usage. For example, our article on Paris being at Paris, rather than at Paris, France, conveys the useful information that the term "Paris", alone, normally refers to that city in English. Nobody says, "I'm going to Paris, France in July"; they say, "I'm going to Paris in July". Despite other common uses of the term, including the Greek god, the film, many other cities including the one in Texas, the way we refer to the city in France is justParis. To put it at Paris, France would be misleading about common usage in English. That's what Primary Topic is about; convey common English usage accurately. Let's not lose that. --В²C☎04:07, 20 November 2025 (UTC)Reply
Oppose While I see why you think this should be locally determined by principle, this isn't something that actually really matters that much in my opinion. The main importance is to avoid editors spending huge amounts of time arguing about it, and using an external resource solves that problem perfectly. As long as we have a decision that's ok it doesn't need to be perfect. Mrfoogles (talk) 16:59, 5 December 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.
RFC on the notability of corporate goods and services
Latest comment: 7 days ago47 comments22 people in discussion
WP:NCORP presently states that it is to help "determine whether an organization (commercial or otherwise), or any of its products and services, is a valid subject for a separate Wikipedia article"
Agree - NCORP is meaningless as a standard if it can simply be avoided by turning whatever WP:PROMO article it is you wish to write into a list of the goods/services of the company concerned. It simply does not make sense that you should be able to write a article listing the goods and services of a company (so basically an article about the company) based on local coverage, trade-press, primary news coverage based on press-releases and company announcements, when you are barred from doing so about the company itself or individual goods and services. Basically, there's no reason why we should be able to have an article entitled List of pizzas sold by Phil's Pizza Shop based entirely on press-releases, local news coverage, and trade-press, when Phil's Pizza Shop would be non-notable under such WP:SIRS-failing coverage. Even a straight-forward reading of NCORP, which states that it applies to "any" of an organisation's goods and services, indicates that it was always intended to means lists of the same. FOARP (talk) 11:05, 15 November 2025 (UTC)Reply
Disagree. NCORP is unambiguously about prose articles, the relevant standard for lists is WP:NLIST. Multiple people have told you this in multiple different discussions, it's time to drop the stick. Thryduulf (talk) 12:09, 15 November 2025 (UTC)Reply
Sure, if Phil’s isn’t notable then their pizzas will not be notable. However, what if Phil’s is considered notable? At that point you have to consider why Phil’s is notable.
IF they are notable for their pizza, then a list of their pizzas might be appropriate. However, they might be notable for (say) the architecture of their building… or for some other factor. In which case a list of pizzas is inappropriate.
Apparently this thread was inspired by lists of airline destinations, where the airlines themselves are considered notable (so NCORP is not the issue). The next question is, why are these airlines notable? Are they notable for their destinations? Are they notable for the type of planes they fly? Are they notable for the luxury of their first class service? Etc. Blueboar (talk) 13:23, 15 November 2025 (UTC)Reply
I think you are confusing two different types of "notable for their food". A restaurant may be notable for having good food, but that doesn't mean that the individual items on their menu are notable and deserving of a listing here. However, a restaurant may be notable for having a "super giant pizza challenge", "world's largest cheeseburger", etc. These sorts of things could be worthy of mentioning in the restaurant's article. To take your airline example, the fact that a hypothetical "Flybynite Airlines" exists and has flights to 37 different countries could be notable, but that those flights include an Ottumwa, Iowa to Bamberg, Germany flight is not. At least not within the parameters of this site. --User:Khajidha (talk) (contributions) 16:31, 17 November 2025 (UTC)Reply
NLIST explicitly says Notability guidelines also apply to the creation of stand-alone lists and tables. NCORP is one of the notability guidelines. JoelleJay (talk) 18:27, 10 December 2025 (UTC)Reply
Disagree The concern that we will have a list of products of non-notable companies is completely hypothetical. It also has an easy compromise solution, allow a list of products of company X only if the company itself passes WP:NCORP. Ultimately, we should prioritize the readers in such discussions. A significant part of them use mobile and benefit from shorter and more to-the-point articles. Stand-alone lists are useful so they don't need to spend additional time navigating the parent article. The readers also won't benefit if we remove most of the entries in Category:Lists of products. Kelob2678 (talk) 13:26, 15 November 2025 (UTC)Reply
Partial agree Given that NLIST doesn't necessary require notability of the "products made by company X" be a notable topic nor company X to be notable if the list is, we still want WP:SIRS (sourcing requirements) from NCORP to be respected if we're just creating a list where individual products may be notable. Even if company X is NCORP-notable, a full list of their offered product or services without SIRS-type sourcing will still be a problem in failing the goal of NCORP, which is to avoid using WP for promotion or business purposes. If there is SIRS-type sourcing for every product, great (this to me would be a case for something like Apple iPhones which absolutely do not go unnoticed by the general media). But if such a list is heavily relying on only press releases or similar first-party, dependent material, that's not acceptable. Masem (t) 13:34, 15 November 2025 (UTC)Reply
Close this in favor of Wikipedia:Village pump (policy)/Airport destination lists Do we really need even more wikilawyering from people fighting over that topic? As for the question at hand, WP:NLIST seems the appropriate guideline to follow. If there's any reason that lists of a corporation's products and services can't effectively be handled by WP:NLIST, I doubt we'll find it buried in the airport destination list mess. Anomie⚔15:15, 15 November 2025 (UTC)Reply
Bad RFC While I appreciate that the proposer does note below what induced them to start this, this feels like a roundabout form of forum shopping to get an answer to one question that he can apply to a different one. This question is a bit vague and does not include a specific proposal regarding language on that page. Anomie makes the right points, though I'll note that airport destination sections are very different from standalone airline destination lists in how they're presented and constructed. Anyway, I disagree and don't think the pages in Category:Lists of products or those the proposer has been nominating necessarily need to be deleted under these grounds. If a corporation is notable, it often makes sense to provide what makes them notable, be that what they manufacture or where they operate. We are generally able to address this kind of listcruft already without this RFC. Reywas92Talk17:05, 15 November 2025 (UTC)Reply
It is reasonable for a notable company to describe the types of products or services they offer as described by third-party sources. This is not the same as supporting a list of every product or service offered, unless that full list can be supported by third-party sources. Otherwise, that's likely violating NCORP and definitely violating NOTCATALOG. Masem (t) 20:05, 15 November 2025 (UTC)Reply
But it does square with WP:SUMMARY. These lists of products are properly thought of as sub-articles created as spin outs of the company articles as the list, even if well-curated to avoid becoming a catalog, would be too long for the main article. Can't knee-jerk judge these. oknazevad (talk) 21:55, 15 November 2025 (UTC)Reply
There's no issue with a curated list of products that have been discussed to some depth in secondary sources (not necessarily enough for a standalone article but more than a simple name drop). But the implication here is a complete list of products or services as a separate list, and that's where NOTCATALOG can be a problem. Masem (t) 02:20, 16 November 2025 (UTC)Reply
Agree A partial and generalized list of products a company offers should be included in the main company article. I see no reason why there should be a separate list that's essentially acting as a company version of WP:FANCRUFT to include every single product the company offers. And if you are going to have one, it absolutely needs to adhere to minimum WP:NCORP requirements. Wikipedia is not a product directory, though it appears some would like it to be some sort of catalogue of all goods and services that exist. That is not what an encyclopedia is for. SilverserenC21:57, 15 November 2025 (UTC)Reply
Partial agree In general, I think that the standards of NCORP apply to lists of goods and services. I am not sure to what degree this should also apply to any specific circumstance (such as airline destination lists). — Preceding unsigned comment added by Enos733 (talk • contribs) 00:41, 16 November 2025 (UTC)Reply
No bold, as I'm not quite sure where my comment would fall. NLIST would seem to be appropriate, but if a company fails NCORP I can't see how a list of their products could be notable. I could also see a list of products being covered by WP:NOTPROMO unless there's independent sourcing. -- LCU ActivelyDisinterested«@» °∆t°
Disagree Wikipedia isn't a shop. Does it say we are shop anywhere? We not in the business of listing a catalogue of goods. That has been understood for more than 2 decades. Its been long established consensus since 2016-2017 years that companies don't list their products unless the product is standalone notable per WP:GNG and the company is notable per WP:NCORP. They it can get seperate article that is sourceable to secondary sources. Before that the company had to be notable per WP:GNG before the product could get an article. There was a reason for this, simply that Wikipedia was flooded by company brochure articles that had reams of products listing. Are we looking to go back to that. It was always understood that product listing were WP:PROMO and needed to be removed. They had to pass WP:GNG to be notable on their own before inclusion. NCORP does not apply to list of goods. It was written specifically for company entities only. How is corporate notability applicable to a product? If the company fails WP:NCORP the product isn't notable. scope_creepTalk07:12, 5 December 2025 (UTC)Reply
Disagree, I guess, but the question isn't really addressing the underlying problems. We're handling WP:SIZE splits poorly. If an article about a notable business gets so big that we need to split it, then it should not be easy for an editor take the split-off content off to AFD because they personally don't believe that List of Apple products has been "discussed as a group or set by independent reliable sources". We should also support the creation of {{navigation lists}} (=all/nearly all blue links), even if an individual editor prefers categories or even if they don't value the sources currently in the list. This is all clear as mud in our current guidelines, and that leads to a few editors believing that these pages are officially unwanted, and then getting surprised and feeling frustrated when the community rejects their efforts to get the lists deleted. We need to fix that, but I still don't have any good suggestions for how to do that. WhatamIdoing (talk) 21:41, 7 December 2025 (UTC)Reply
Agree. I don't see how a list article for products and services of a company does not fall under NCORP. We already have guidance on lists that unambiguously serve a navigational purpose and how those are treated by N, so reaffirming that product lists that do fall under N still need to meet the appropriate notability guidelines really shouldn't be contentious. JoelleJay (talk) 18:16, 10 December 2025 (UTC)Reply
This RfC is another episode in the saga about airline destination lists. Most of the recent AfDs regarding them were initiated by FOARP[2]. Earlier this year, the community expressed their doubts about whether WP:NOT applies to them[3]. Now, the issue is being pressed from the WP:NCORP perspective. The change discussed here was boldly added to the guideline[4] and was reverted[5]. In response, we got this RfC.FOARP himself notes, we still have listings of airline services that don't pass either WP:NLIST or WP:NCORP.[6] So why do we even need to subject the lists to WP:NCORP? In my opinion, to make the discussion more focused, it's better to stick to WP:NLIST. Kelob2678 (talk) 13:26, 15 November 2025 (UTC)Reply
"why do we even need to subject the lists to WP:NCORP" - to avoid WP:PROMO content based entirely on press-releases, local coverage, trade-press etc., just simply written as a list rather than as a prose-article. FOARP (talk) 15:04, 15 November 2025 (UTC)Reply
Hi, we were indeed discussing it, but it doesn’t look like there was enough participation since only you and I contributed to the discussion there which was why VPP is probably a better forum. FOARP (talk) 08:27, 16 November 2025 (UTC)Reply
The core question here is the “group or set” requirement of NLIST… are airline destinations as a set notable? To answer that, we need to ask: Are there independent reliable sources that discuss the concept of airline destinations as a set? Blueboar (talk) 14:03, 15 November 2025 (UTC)Reply
The "discussed as a group" requirement does not have wide agreement in the community about what it means. Mostly, people seem to think that of course it supports "my" general view on the deletionism–inclusionism spectrum, whatever that view is. WhatamIdoing (talk) 23:09, 15 November 2025 (UTC)Reply
This reminds me of the discussion that led to ongoing development of the Wikipedia:Directory articles proposal. As a product meeting the standards for having an article does not automatically mean that the associated organization meets the standards, theoretically there could be a company with a list of products that have articles, while the company does not. I don't know if there are current examples in mainspace that we could examine, though. (User:Theleekycauldron/List of projects by Complexly is an example given in the directory articles proposal, though Complexly has a mainspace article.) isaacl (talk) 19:55, 15 November 2025 (UTC)Reply
Thinking about that example further, I guess privately-held, small-shop companies could be a typical use case. A one-person (or small number of people) company could create one or more video or audio channels, for example. The channels could meet the standards of having an article while the company does not, as there often isn't much available public information about small private companies for secondary sources to write about. isaacl (talk) 20:06, 15 November 2025 (UTC)Reply
I came across an example a couple of months back that I unfortunately cannot remember the name of when writing a disambiguation page - a small (Indian iirc) motorcycle manufacturer that makes/made 2-3 unambiguously notable models but is not themselves notable as nobody has written anything in-depth about the company (at least in English). Thryduulf (talk) 20:53, 15 November 2025 (UTC)Reply
That seems so very backwards to me. If a company makes multiple notable products, than that company is notable. WP:NOTINHERETED is a downstream thing, not upstream (like actual inheritance). It is and remains true that just because a product is made by a notable company, doesn't mean the product is inherently sufficiently independently notable for an article. But a notable product does confer notability on the company making it, as the company is notable as the manufacturer of a notable product.
That's exactly how I've always used it and how many of our notability requirements use it. WP:NAUTHOR is entirely about how producing notable works makes the author notable. Similarly with scientists, their notability is based on producing notable research. NOTINHERITED applies to things at a lower level than the thing in question. SilverserenC22:00, 15 November 2025 (UTC)Reply
I only mentioned English as that's the only language I searched for sources in. NOTINHERITED does work both ways, otherwise the parents of notable children would be automatically notable, holding companies would be automatically notable if any subsidiaries are notable, an author of a notable book would be automatically notable, record companies of notable artists would be automatically notable, etc. That's obviously not the case - the subjects of articles need to have coverage in multiple independent reliable sources. Thryduulf (talk) 22:11, 15 November 2025 (UTC)Reply
Books have their own notability standard. What we are discussing is that inherited notability upward does occur in specific topics, such as for authors. If you write books that are notable, that notability is conferred on you, hence WP:NAUTHOR. Which is why generally in discussions about author notability, we require 3 RS reviews of an author's books to say they are notable for having written notable books. Because 3 reviews is the minimum standard for book notability even if a book article hasn't been written yet. SilverserenC23:41, 15 November 2025 (UTC)Reply
Authors are notable through WP:SNG. If the notability were inherited, there would be no need for the SNG at all. But since it is better for the encyclopedia to have articles on academics, the special exception was made for them. No such thing has happened to commercial organizations. Kelob2678 (talk) 13:15, 16 November 2025 (UTC)Reply
True, but I think that when we parse company vs CEO vs products vs subsidiaries, we're overlooking the value of a merged-up article that covers all of these. We don't want an article title like Bob, blue-green widgets, and Big Business, Inc., but we do want a page that lets us write not just about the motorcycles but also a paragraph about their manufacturer.
For CORP in particular, this should probably be called out as an explicitly desirable outcome. CORP articles are particularly at risk of someone saying "Well, the title is just Big Business, Inc., but half the sources are about Bob and blue-green widgets, and what's left isn't quite enough to count as SIGCOV IRS in my opinion, so I'm taking it to AFD." WhatamIdoing (talk) 00:18, 16 November 2025 (UTC)Reply
If there's nothing more to say about a production company than "it produces YouTube channel A since XXXX, B since YYYY, and podcast C since ZZZZ", then I can appreciate an argument that a list article is sufficient for the company, and that it does not otherwise meet the standards for having an article. Nowadays, anyone can privately finance a production company and not make any significant public revelations. isaacl (talk) 22:50, 15 November 2025 (UTC)Reply
Having taken part in a few AFDs of video game studios, I'll second that it is not a popular interpretation of NOTINHERITED at AFD – even if a studio has multiple notable games, AFD consensus is that just the games are notable, not the developers. Nil🥝22:22, 17 November 2025 (UTC)Reply
WP has no concept of inherited notability in general. Some of the SNGs, like WP:CREATIVE, do give the credence that if the creator has multiple notable works that the creator is presumed to be notable, but that does not extend to companies at all (though I do think for companies that are involved in creative product creation, we should have something in this aspect, but this is not the place for that discussion. Masem (t) 02:23, 16 November 2025 (UTC)Reply
What we do have is wide latitude to decide how to cover a given topic... In one context it will make sense to have the stand alone article be about the work with a subsection about the creator, in another the creator with a subsection about the work, and in a third both could merit stand alone articles. Horse Eye's Back (talk) 03:48, 16 November 2025 (UTC)Reply
Having participated in some of the many discussions regarding airline (and airport) destination lists, I think the question is not so much whether NCORP as a whole applies to lists of a company's products and services, but whether NCORP's sourcing criteria, primarily WP:SIRS, should be applied to such lists. If the items on the lists are individually notable then such a requirement would be moot, but does an article listing products or services that are not individually notable require SIRS-level sources covering the list as a whole and/or all items on the list? I think the answer is yes, strict sourcing criteria should apply in such cases, particularly if the list is intended to be comprehensive. Rosbif73 (talk) 15:44, 17 November 2025 (UTC)Reply
This is an absolutely terrible RFC. Badly thought out in an attempt to usurp 20 years of thinking on corporate notability. Its takes no cognizance of the reasons for NPP/AFC, the storm of UPE company articles between 2008-2018, (mostly brochure and native advertising articles with lots of products listings) the promotional aspect of UPE article nor the reasons for the failure of WP:NORG and the reasons for eventually bringing in WP:NCORP, which are all there to read in the archives. scope_creepTalk07:12, 5 December 2025 (UTC)Reply
Latest comment: 12 hours ago275 comments68 people in discussion
I do not know who came up with it or why but suddenly we have a billion new users on every even slightly contentious page, all of whom have no history but who have very clearly edited *very* extensively in the past, making disruptive changes with absolutely no means of controlling it because we've just given them a billion fake IDs Snokalok (talk) 13:13, 3 December 2025 (UTC)Reply
Hot take: the giant, scary “YOUR IP WILL BE VISIBLE” sign was actually a really great deterrent against the NOTHERE. Now that’s gone, they have a different account for each device they’re on, and if they want another one, just clear cookies. Snokalok (talk) 13:29, 3 December 2025 (UTC)Reply
I tend to agree that this change has supercharged contentious editing, and made it exponentially more difficult for the average editor to identify individual abuses of multiple local IP addresses. BD2412T13:40, 3 December 2025 (UTC)Reply
Honestly even allowing IPs imo was a deep and costly compromise between wikipedia’s ideals and the practical reality of keeping the project nice. Temp accounts just surrender the project entirely to chaos. Snokalok (talk) 16:27, 3 December 2025 (UTC)Reply
I don't really understand the need to allow IP editors or temp accounts at all. Maybe early in the project, but accounts are already pseudo-anonymous, free, and easy to create. Reddit, Facebook, and other Websites that depend on user generated content tend to require an account to participate, I don't see why Wikipedia doesn't. My experience has mostly been real editors using them as sock puppets or disruptive edits that are either intentional vandalism or clueless. GeogSage (⚔Chat?⚔) 18:34, 3 December 2025 (UTC)Reply
It’s an idealism thing. Wikipedia doesn’t formally swear by any political ideology, but if one was to assign a label to its ideals, its principals would very swiftly fit the model of anarcho-communism. And that means, among other things, that everyone has a voice and everyone can contribute and decide on content.
Obviously in practice it just ends up being the equivalent of the articles of confederation, where there’s not enough centralized authority or etc, but the ideal built wikipedia in the first place - and it wouldn’t be a small thing to go back on that.
But even so, I think the temp accounts have just emboldened disruptive editors that were previously deterred by having their IP be public. Snokalok (talk) 22:22, 3 December 2025 (UTC)Reply
And the temp accounts also have emboldened constructive editors that were previously deterred by having their IP be public. Most unregistered users are not vandals. SuperPianoMan9167 (talk) 22:47, 3 December 2025 (UTC)Reply
I’ve sort of noticed, as the project gets older, generational divides form amongst editors. Like on GENSEX topics, most of the editors who really strongly push anti-trans povs are those who joined in like the mid-2000s - proper old guard; while those who push the other way are usually those who joined in the 2010s. The 2020s so far have been an even split. Snokalok (talk) 00:04, 4 December 2025 (UTC)Reply
How true is a statement like the biggest problem is our stagnant editor base? It's unclear without seeing the statistical evidence, but for the Arab-Israel conflict contentious topic area it does not appear to be the case. We looked at related issues as part of the ARBPIA5 case. At least in that topic area it is possible to say that, while the unique actor count is pretty steady (Meme check #1), younger accounts appear to play an important role (Meme check #2). So, I'm guessing that if there is some form of stagnancy, it is likely quite heterogeneously distributed across the project. Sean.hoyland (talk) 10:42, 4 December 2025 (UTC)Reply
The idea an IP address was a privacy nightmare is hard to parse. All it establishes is a general area of some kind of user at that time. However having the easy ability to check an IP made it extremely easy for the average experienced user to find out if this is the same person causing more issues via a slightly different location.
@Rambling Rambler, back in the 1990s, if you looked up my IP address, WHOIS would give you my exact home address. I think "a privacy nightmare" is a fair description of that setup. While most ordinary people, editing from their homes or phones, are not going to be in that situation, there still are people for whom the IP address is identifying, and millions more for whom a permanently recorded IP address is one short subpoena to an ISP away from being the next Asian News International v. Wikimedia Foundation case. WhatamIdoing (talk) 21:48, 3 December 2025 (UTC)Reply
It is unlikely IPs would be doing edits that are controversial enough to get sued. The constructive IPs are mostly doing basic fixes and fighting vandalism themselves. Anything more than that and the IP would be incentivized to create an account to get credit for their work. Mikeycdiamond (talk) 12:04, 4 December 2025 (UTC)Reply
On 4 August 2025, the Wikimedia Foundation announced compliance with local Portuguese court orders and subsequently removed content from the Wikipedia articles related to DePaço on both the English and Portuguese Wikipedia projects. Additionally, the IP and email addresses of eight involved Wikipedia editors were disclosed to DePaço, who stated that he would pursue further legal action against the editors.
Only if all eight of those users had used temporary accounts rather than registered accounts, and the temporary accounts were old enough. Anomie⚔13:32, 4 December 2025 (UTC)Reply
I realize that now. I had assumed that IP editors were involved. I was largely incorrect in my conclusion.
The point is that it's weirdly inconsistent to treat IP addresses as sensitive personal data when they belong to registered accounts but simultaneously say that they aren't sensitive at all when they belong to unregistered users. SuperPianoMan9167 (talk) 19:37, 4 December 2025 (UTC)Reply
I've requested too. But I agree with User:Snokalok's original assertion that the whole temp account thing seems like not a very good idea. Was there ever an RfC or some equivalent on this topic? NickCT (talk) 17:04, 3 December 2025 (UTC)Reply
No, it was forced on us by the WMF. Possibly due to Legal, GDPR etc. etc. This is not a great solution at all and hopefully tools will improve or TAIV be granted more liberally.~212.70~ ~2025-31733-18 (talk) 17:30, 3 December 2025 (UTC)Reply
I'm a bit confused by the acrimony against the change, given that TAIV exists. Is the new issue just that new editors without TAIV are filing shot-in-the-dark reports against TAs that need further legwork by admins/TAIVs to respond to? signed, Rosguilltalk18:01, 3 December 2025 (UTC)Reply
For me the issue is that it creates an enormous overhead for normal anti-vandal/anti-abuse work. To be thorough one has to check the history of the editor, so instead of looking at the single IP contribs page, or a /64 for an IPv6, I have to open the temp account contribs, the IP temp account contribs, and the IP legacy edits. This is already suboptimal on a desktop and adds to the time it takes to investigate, but when editing from a phone it's downright horrible. There are ~12,000 blocks a month, the overwhelming majority of them from AIV/TB2. Adding additional time to processing the reports from those noticeboards eats up a huge amount of limited volunteer time. Add to that the large number of vandals that I've seen making a couple edits and either deleting their cookies or opening a new incognito window to grab a new TA with a blank user page which abuses the escalating warnings before blocking method we use and it's a pretty significant headache. ScottishFinnishRadish (talk) 18:11, 3 December 2025 (UTC)Reply
But doing anything from a phone that involves a keyboard is downright horrible, especially with my fat fingers. At least the IP legacy edits will reduce in importance with time. Phil Bridger (talk) 21:16, 3 December 2025 (UTC)Reply
I primarily edit from my phone, so the extra steps are a significant issue. We also need to get hip to (that's what the kids say, right?) the fact that most people access the internet with mobile devices. Making a shitty system even shittier for mobile editors isn't helping us. ScottishFinnishRadish (talk) 22:14, 3 December 2025 (UTC)Reply
Why not write a user script that acts as a better autoblock for TAs (since a regular autoblock is fixed to 24 hours)?
Here's what I'm thinking of:
When blocking a TA, a mobile-friendly dialog comes up that says "Block the TA's IP?"
If it is checked, once the block is placed, the script would perform a normal IP block (anon. only, account creation blocked) on the TA's IP, with the same block duration as the original block, but with a vaguer, generic block summary, such as "abuse from TAs on this range". The only exception would be that an indefinite TA block would result in a 90-day IP address block.
This acts essentially like regular autoblock: the abuser has to change both their IP address and their TA to evade a block. The only differences are that it lasts for longer than 24 hours and that it only applies to one IP address or range. It wouldn't work against proxy abusers but IP blocks don't work on proxy abusers anyway.
It also saves having to open a new tab to block the underlying IP and thus reduces tediousness by automating the IP block. Yes, this exposes a TA's IP address automatically, but that's allowed by policy: admins are allowed to make blocks that, by their timing, imply a connection between an account and an IP. The block summary for the IP is made vague to avoid violating the IP disclosure policy.
Of course, any IPv6 block would automatically extend to cover the /64.
Maybe a template similar to {{CheckUser block}} could be used in the edit summary--{{TAIV block}} might work.
Why is it necessary to check the IP every time? Why not just block the TA? My idea is that an admin would block the IP for the same duration as the TA block using this tool for every single TA block, eliminating the need to check the IP at all. I think non-admin TAIVs doing the TA tracking work instead of admins would work out better.SuperPianoMan9167 (talk) 00:15, 4 December 2025 (UTC)Reply
Because very often there are multiple TAs on the address, and without looking at the history, including legacy IP edits, you won't know the appropriate length for the block. ScottishFinnishRadish (talk) 00:22, 4 December 2025 (UTC)Reply
Then what would be a good idea to reduce this tediousness and prevent disruption besides "require registration" or "ditch temporary accounts", as the WMF has shown no signs of entertaining either idea? SuperPianoMan9167 (talk) 00:28, 4 December 2025 (UTC)Reply
I don't believe the WMF really has a say on if we require an account to edit. Portuguese Wikipedia requires an account. As for alternatives, hash IP addresses instead of using temporary accounts. Permanently assign IP addresses account names as they edit. There's a lot of ways to hide IP addresses that doesn't create a huge burden on editors and admins. ScottishFinnishRadish (talk) 00:35, 4 December 2025 (UTC)Reply
Hashing won't work. IP addresses are fixed identifiers. Given enough large enough data set of hashed up addresses and the corresponding IP addresses, one can either reverse the hash or build a rainbow table connecting the two. – robertsky (talk) 05:24, 4 December 2025 (UTC)Reply
Seems more secure than the TAIV permission which any potential malicious bad actor could circumvent with time.
With temporary accounts, all IP information is discarded after 90 days, and the temporary account's name still remains as an identifier. If we used IP hashes to identify unregistered editors, we'd be keeping that (obscured) IP information forever within the identifier. jlwoodwa (talk) 02:16, 5 December 2025 (UTC)Reply
Only insofar as an IP editor might maintain a single IP, sure. But otherwise, I think having a single identifier for one user is preferable to having many over a short period of time. I have engaged in discussions with TA editors who have unintentionally had new temporary accounts created for nearly every one of their edits. Katzrockso (talk) 02:35, 8 December 2025 (UTC)Reply
meta:Limits to configuration changes#Prohibited changes #3 forbids WMF deployers from assisting with configuration changes that turn off anonymous editing. Ptwiki has gotten around this with a series of workarounds involving mw:Extension:AbuseFilter and some other on-wiki-configurable things. However since the WMF officially forbids it, it means that going in that direction would involve spending political capital and causing tension. Just FYI that there are some challenges/obstacles that make this harder than normal. –Novem Linguae (talk) 00:53, 8 December 2025 (UTC)Reply
I believe that ptwiki's workaround was shut down by WMF Legal (maybe it connected the IP address to the new account in a log somewhere?). They ended up getting the WMF to do it properly, as part of an official experiment that involved a couple of wikis and restricted editing in the mainspace only (including disabling the ordinary Wikipedia:Edit requests, but still allowing IPs to post manually on the talk page).
Ptwiki has a long history of restricting new editors (e.g., CAPTCHAs for every single edit, even if you're just fixing a typo or reverting blatant vandalism), and I understand that a two-thirds majority felt like the tradeoffs were worth it.
All of which is a long-winded way of saying that we can't do that. If we wanted to cut down on IP's edits, we could, however, do something like semi-protect the 1,000 or 10,000 articles that are most popular with IPs (or have the highest page views). WhatamIdoing (talk) 03:47, 8 December 2025 (UTC)Reply
Perhaps what is needed is some sort of additional tool for CheckUsers that lists every edit made from an IP or IP range, regardless of whether it was via an account or not (or perhaps just for temp accounts), in a single list of edits, as if they were one user. Obviously since this would expose private information it would need to be restricted to CheckUsers (or just TAIV users if it only works on anon accounts) and every use of it logged, but would that be feasible? --Aquillion (talk) 14:35, 11 December 2025 (UTC)Reply
I agree with Aquillion in the general sense: What's needed is better, more efficient, more comprehensive tools for CUs and Stewards. The scale we need for this is a dedicated dev team for the next five or ten years, not the m:Community Wishlist or a one-off tool. WhatamIdoing (talk) 17:35, 11 December 2025 (UTC)Reply
@Rosguill according to the policy around using TAIV every use of it is logged. Previously as a lay user I could simply check the IP, look for recent activity from that same address, and if questionable take it to AIV/SPI.
Now however if I were to acquire the tool and examine TAs and I'm wrong, it feels like I'd have a cloud over me because that record could be questioned at any point by a CheckUser.
That makes sense, although personally I think that absent guidance mandating specific limitations on TAIV use, "any mildly suspicious edit or edit made in the vicinity of such edits" should be considered fair game good faith use of the tool. signed, Rosguilltalk19:00, 3 December 2025 (UTC)Reply
@Rosguill but then that needs to be either guideline or preferably policy, that there's a very strong presumption of innocence in usage and it's for those believing it to be misused to have to demonstrate clear malicious usage.
Nobody cares how often you look at the IP address. Look at every single one of them, all day long, if that floats your boat.
It's logged so that if an "anonymous" social media account posts "Hey, world, just creating a permanent record so we'll always know that ~2025-12345-67 is IP 192.0.2.0, and ~2025-23456-78 is 198.51.100.255 and...", then they can figure out who looked at those and, um, provide you with an opportunity to stop doing that. WhatamIdoing (talk) 21:57, 3 December 2025 (UTC)Reply
@Rambling Rambler, please don't worry too much about this when you're reporting to SPI. We know everyone's still getting used to it, and it's very easy for us to revdel any accidental disclosures. I assure you that clerks won't get too mad about it (they've seen worse) and CUs have way better things to do with our time than chase down someone who revealed an IP for no reason other than because they got curious. -- asilvering (talk) 05:01, 5 December 2025 (UTC)Reply
One issue is that its a rfp, all the language around this makes me really scared that if I mess up or misinterpret a policy, i could get blocked. Plus, the policy is hosted on a wmf domain, so I cant even read it bc my school blocks all wmf domains. MetalBreaksAndBends (talk) 15:49, 5 December 2025 (UTC)Reply
@Toadspike I'm aware of that tool existing. However I have been reticent to apply for it because it seems there's just a massive amount of policy bear traps created around both using it and then how you refer to it once you've used it that feels like I'm the one who'd be under more scrutiny for examining a TA than the actual TA.
Also the fact we have that tool just feels like a giant admittance by WMF that TA are basically pointless, because if we're allowed to view IP with extra steps then it's not really dealing with any of the "fear of Wikipedians safety" that WMF claimed was the justification for the change. Rambling Rambler (talk) 18:51, 3 December 2025 (UTC)Reply
Personally, I've decided not to click the button to enable TAIV for myself because I have no interest in working out what the CheckUser-lite policies around it allow and don't allow. Easier to leave it to admins who are into that sort of thing. Anomie⚔23:37, 3 December 2025 (UTC)Reply
For what it’s worth, the interface itself drives temp users towards churning and burning accounts if they don’t want to create an account. There’s a giant grey “you need to log in, this is a temp account” banner on the top of every single page that only disappears when you “exit session”. The result is that browsing while “logged into” a temp account is more annoying than creating the account and immediately throwing it away. I went from having one IP account to creating one for each comment I make. Including this one, haha. ~2025-38292-55 (talk) 19:07, 3 December 2025 (UTC)Reply
As I mentioned elswhere, the temporary account implimention will proove to be a disaster. This idea should've gotten community imput, as to whether or not to implement. GoodDay (talk) 18:09, 3 December 2025 (UTC)Reply
It's one of the worst technical misfires the WMF has ever made and they're justifying it, as Fram and Aaron Liu wrote about here, on an incompent misreading of editing statistics at the Portuguese Wikipedia before and after they switched off anonymous editing. Everyone involved with the decision needs to grow up and accept that the days in which it was appropriate for unregistered users to edit the project are long gone. — Hex•talk19:42, 3 December 2025 (UTC)Reply
Agree, it's a complete mess. Masking IP addresses was absolutely necessary, but this particular implementation is a disaster. It's hard on unregistered users (their contribution history is scattered to the wind even if their IP is static, and their apparent username changes constantly so they're constantly accused of sockpuppetry), it's a disaster for registered users (instead of interacting with one IP address or a few that displayed obvious patterns, now we have to try to converse with what is no more legible than a QR code), it's a pain in the ass for enforcement (if your TA is blocked you can easily just make a new one, far easier than changing your IP), and let me tell you it's absolute horseshit for checkuser (private checkuser reasons). If this is the best solution the devs can come up with, it would solve the problem much more reliably to just disable logged-out editing and force all editors to create an account; registered accounts are already very well protected by privacy policies and have been for a very long time. Ivanvector (Talk/Edits) 19:44, 3 December 2025 (UTC)Reply
@Ivanvector, do you have any estimates on how many ordinary people use staticdynamic IPs these days? I've seen estimates ranging from a conservative "most" to a sweeping "vast majority".
If the username depends on the IP address, then the username would change when the IP address does, resulting in contributions being scattered to the wind. Many mobile editors use multiple IP addresses each day, and most people with a dynamic IP address change IP addresses every couple of days (though it differs per country and ISP). WhatamIdoing (talk) 22:23, 7 December 2025 (UTC)Reply
@WhatamIdoing: I slightly disagree with asilvering, and would say that for Wikipedia's practical purposes all IPs are dynamic. Some, like in the geographies they mentioned, are more stable than others but they're not actually static and can be rotated, and the networks are absolutely massive and geolocation doesn't work. All IPv6 addresses are inherently dynamic because of the way our software handles them. In sixteen years here I can count the number of editors I've encountered on truly static IPs (an IP that is assigned to them by their ISP and never changes) on one hand, and still pick up my coffee. Ivanvector (Talk/Edits) 13:50, 8 December 2025 (UTC)Reply
It's hard on unregistered users (their contribution history is scattered to the wind even if their IP is static, and their apparent username changes constantly so they're constantly accused of sockpuppetry). IP masking uses a cookie to keep a user signed in to their temporary account, even if their IP address changes. So in this respect it is better at grouping a good faith user's edits together than just relying on IP address, as long as they are using the same browser and not blocking or clearing cookies. However if I am reading the code correctly, IP masking only lets a user stay logged in for 60 90 days. And if I recall correctly, this was because WMF wanted to create some incentive for temporary accounts to create actual accounts. So in conclusion, I think the user experience for good faith, non logged in users is kind of a wash, rather than definitely worse. Although if the 60 90 day thing is a problem, someone could always lobby for enwiki to have this setting raised. The patch would be like 3 lines of code. Edit: Can't change constants in PHP, so this would take some additional engineering. –Novem Linguae (talk) 00:45, 8 December 2025 (UTC)Reply
You're not reading the code correctly. The line you link is for freshness of some API response, and is set to 1 day (86400 seconds). The validity of a temp account is 90 days, defaulted here. Anomie⚔01:16, 8 December 2025 (UTC)Reply
Also, FWIW, phab:T359653 indicates that 90 days was chosen to match the expiry of CheckUser data. Although they seem in general to want to determine how quickly good-faith anons naturally lose their cookies and set the expiry to that instead; there was talk in there of expiring them after just a week. Anomie⚔01:24, 8 December 2025 (UTC)Reply
Re changing it, assuming WMF would allow it, it would be a configuration change assigning $wgAutoCreateTempUser['expireAfterDays']. Some comments I'm seeing suggest they'd probably say they want them to be the same across all SUL wikis though. Anomie⚔01:31, 8 December 2025 (UTC)Reply
@Novem Linguae, IP masking uses a cookie to keep a user signed in to their temporary account, even if their IP address changes is the principle of the thing, but I can tell you've been too busy with elections business to do much anti-abuse work recently if you're saying this. It's simply not working this way at all. You don't even need to be a CU to spot it - just spend an afternoon at AIV or digging through the "open" bin at SPI. It's bad. I have no idea how the other wikis didn't notice that TAs weren't working as designed, but they didn't, and it fell to us to point these things out to the WMF team working on it. -- asilvering (talk) 01:51, 8 December 2025 (UTC)Reply
@SuperPianoMan9167, sorry, I can't answer that question, and I'm not sure if the WMF team can yet, either. I am sure they're working on it (stewards and en-wiki functs have been giving them a lot of feedback on the issue). -- asilvering (talk) 02:12, 8 December 2025 (UTC)Reply
Controlling temporary accounts via cookies only works if the user only uses one device (rare these days) and doesn't log out manually, doesn't clear their cookies, and/or isn't using a browser configured to delete cookies after every session (which are now quite common), otherwise their contribs show up as those of multiple random serial numbers. If they're using more than one device they will have more than one TA simultaneously, and if they are using more than one TA to edit the same article or participate in the same project discussion then they are in violation of the sockpuppetry policy without being aware that they are violating it. There's a discussion happening in fits and starts right now about how to edit the policy to handle that. I have not so far seen any TA users having kept their TA for more than maybe a week at the high end, but I have made several checks showing one person spamming dozens of TAs on a single IP, not always obviously deliberately, and with each TA having just one or two edits. How is a non-CU supposed to track that? Ideally, contribs tied to a semi-permanent cookie are better for consolidating contribs; in practice, it's much much worse. So much worse. Ivanvector (Talk/Edits) 13:50, 8 December 2025 (UTC)Reply
Maybe we could include all of the other temp accounts on the same IP on the temp account's user page? We need to get rid of temp accounts, but I doubt the WMF will allow it. Mikeycdiamond (talk) 14:06, 8 December 2025 (UTC)Reply
WhatamIdoing said Nobody cares how often you look at the IP address. Look at every single one of them, all day long, if that floats your boat. This is all a mess and i hate it. (e: person who responded is probably right, just not updating her user page would be strange) MetalBreaksAndBends (talk) 15:20, 8 December 2025 (UTC)Reply
if they are using more than one TA to edit the same article or participate in the same project discussion then they are in violation of the sockpuppetry policy without being aware that they are violating it
This is only true if they are abusing multiple temporary accounts. A good-faith unregistered editor using multiple TAs is not violating the sockpuppetry policy. SuperPianoMan9167 (talk) 14:09, 8 December 2025 (UTC)Reply
Re I have not so far seen any TA users having kept their TA for more than maybe a week at the high end: The following good-faith unregistered users have kept their temporary accounts for longer than that (non-exhaustive list; when I tried to look at the user creation log for the earliest temp accounts the page refused to load):
The last one has had their temporary account for 34 days now and has over a thousand contributions.
I know that for this to work one has to stay on the same browser on the same device, since cookies never sync between devices, but it goes to show that for at least some users, TAs appear to be working as intended. SuperPianoMan9167 (talk) 20:29, 8 December 2025 (UTC)Reply
@Ivanvector, to be clear, someone using multiple TAs to participate in the same discussion is not violating the sockpuppetry policy unless they are also lying about being different people. -- asilvering (talk) 20:39, 8 December 2025 (UTC)Reply
One would hope that this mess would push the WMF towards what has for a long time been the only obvious solution, which is mandatory registration; however, since in the past the disruption of workflows for editors and admins has been something that the WMF clearly couldn't give a shit about, I doubt if this is going away any time soon. Black Kite (talk)19:59, 3 December 2025 (UTC)Reply
I'm sure I'll get roasted for this, but when was the last time anyone here was able to submit any content of any sort to any website, besides Wikipedia, without creating an account first? Ivanvector (Talk/Edits) 20:55, 3 December 2025 (UTC)Reply
The last place I saw using non-account registration outside Wikipedia was the Gawker network of sites.
Funnily enough it led to an endless wave of harassment via spamming gore and torture images that meant they basically hide most of their comments away unless you were given "trusted" status. Of course vandals there just immediately got trusted status on one account and then just used it to make their vandalism content visible. Rambling Rambler (talk) 22:09, 3 December 2025 (UTC)Reply
Nearly all of them accept fake phone numbers and fake e-mail addresses, though occasionally I'll run across one that will reject an @mailinator.com address. Almost none of them actually verify that the e-mail address is functional. But giving them a way to contact me isn't the same as creating an account. WhatamIdoing (talk) 01:19, 5 December 2025 (UTC)Reply
It is the same. They are linking your comment to a specific ID, in that case an email address. Whether that email address is functional is irrelevant to this, usernames never have email functionality. (They are probably also creating a profile through other data, which we do not.) CMD (talk) 03:04, 5 December 2025 (UTC)Reply
Well indeed, a full account creates an additional layer of privacy. Outside of GDPR territories, I expect most companies devote much less attention to this than we do. CMD (talk) 03:43, 5 December 2025 (UTC)Reply
Accounts are also re-usable. With a "Contact us" form, by contrast, if you go back the next day, you have to fill out the same information all over again. WhatamIdoing (talk) 21:58, 7 December 2025 (UTC)Reply
And if you fill in the same email, you will still only be subscribed to their mailing list once, because the database they store your contact info in filters duplicates. Ivanvector (Talk/Edits) 13:50, 8 December 2025 (UTC)Reply
There's some forums I have heard of (econ job market rumors - which has led to a culture of bigotry) but you're right that it's not common. Katzrockso (talk) 08:40, 4 December 2025 (UTC)Reply
I have frequently been critical of the WMF, but I find it difficult to find fault with them in this case. Politically they had to do something about exposing IP addresses to anyone who cares to look. The only choices were to have something like the current temporary account procedure or to require registration. Phil Bridger (talk) 21:23, 3 December 2025 (UTC)Reply
I've been saying this for years. In 2001, creating an account might have been a barrier to entry and it made sense to allow instant editing as we sought to rapidly expand the editor base. But these days the public expects this, there aren't many sites out there that don't require you to open an account. IP addresses were bad because of privacy and also easy socking if you IP hop, but temp accounts are even worse. It's now perfectly legitimate and very easy to edit under a new handle every day. Let's move to requiring log in please. — Amakuru (talk) 23:48, 3 December 2025 (UTC)Reply
Unfortunately I think the problem is that it's no longer the internet of even the early 2000s where it required some base level of skill and Wikipedia was still unknown.
What if we auto-generated username suggestions Reddit-style, e.g. Big-Reptiles1234. Would that remove some friction to registering? (You still need to make a password.) ⁓ Pelagic ( messages ) 21:35, 12 December 2025 (UTC)Reply
The original WikiWikiWeb was an agile tool for a community of practice - created in 1995, long before agile software development - where many of the participants knew each other, and frictionless contribution without a need to register was beneficial and unproblematic. For a long time, anyway (I was there). This project's explosive growth took it beyond that in a very short time, but the people who operate it are libertarian technocrats, and libertarian technocrats suffer from the mindset where the answer to a social (behavioral) problem is always "we can code our way out of it". Instead of what actually works, which is rules that are effectively enforced. An example of such a rule is "editing requires an account", which is enforceable with zero additional software. Back on the WikiWikiWeb we had a maxim for things like this: do the simplest thing that could possibly work. — Hex•talk16:11, 4 December 2025 (UTC)Reply
Also, wikipedia is in a state now that having lower editor traffic isn't necessarily a bad thing, as most of the trivial edits that we had IPs do have been done and any if the more substantial edits require an amount of knowledge that having an account wouldn't be the biggest barrier to entry. mgjertson (talk) (contribs) 20:27, 8 December 2025 (UTC)Reply
Instead we'll die by having pitiful mobile support preventing the majority of internet users from contributing while simultaneously increasing the workload on a declining admin corps through poor implementation of hiding IP addresses. For the same technical effort we could have had not the worst possible mobile experience for editors, added an account requirement, and grown the user base. ScottishFinnishRadish (talk) 00:09, 4 December 2025 (UTC)Reply
That creates even more work and allows more disruption. The additional work isn't just for admins either, it's for anyone who has to deal with the disruption. It also increases the chances that vandalism and other disruption doesn't get reverted. ScottishFinnishRadish (talk) 00:18, 4 December 2025 (UTC)Reply
It sounds like every time you get a vandalism report for a temp account, you check Special:Contributions for the temp account (easy), past contribs for the IP, and for any other temp accounts using that IP.
Your goal is to block them all (if needed) and to revert any problematic edits by any/all of them, instead of just blocking the individual identified problem.
I think it should be possible to create a streamlined tool for CUs and Stewards that automatically pulls up contribs for all of these (@Vermont, does that sound plausible to you, or am I obviously wrong?). But I'd guess that it would first be built by a volunteer who designed it for desktop use, which wouldn't really help you when you're working from a smartphone. WhatamIdoing (talk) 01:32, 5 December 2025 (UTC)Reply
SFR, I have a lot of sympathy for you, but "for the same technical effort" isn't true. A good mobile interface is difficult, especially since what's needed isn't just core MediaWiki features but also the add-on tools that were built by volunteers for use on large screens.
I don't want either of those things, @WhatamIdoing, no. But I think this implementation of temporary accounts might cause even worse damage by limiting our ability to deal with disruption, so I see mandatory registration as the lesser evil.—S MarshallT/C00:25, 4 December 2025 (UTC)Reply
But how would the identifier stay static? Would it be tied to an IP address? If so, that would reintroduce confusion about multiple people on the same IP address (which I think is one of the largest benefits from temporary accounts being tied to a browser cookie, even if that does create other problems). The WMF admits that TAs are not intended to solve any anti-abuse problems and mentions device fingerprinting as one of three solutions:
Can't an abuser just clear cookies? Yes, they can. Temporary accounts are not intended to solve any anti-abuse problems.
We know the problem of abusers making edits through a pool of changing IPs while masking browser agent data. This cannot be solved through temporary accounts. This is not a design goal for this project either. Otherwise, we would need to use trusted tokens, disabling anonymous edits, or fingerprinting, all of which are very involved, complicated measures that have significant community and technical considerations.
We have adapted tools to ensure that trusted functionaries can safely and efficiently navigate the bidirectional mappings between temporary accounts within the last 90 days and IPs. However, abuse from a user who clears cookies may become difficult or impossible to detect and mitigate for users without advanced permissions, or if some of the edits involved are more than 90 days old.
I don't care how many people are using a single IP, I care about the behavior from that IP. There's no problem there to be solved. As for the anti-abuse issue, it actively makes it worse and costs an enormous amount of additional time. ScottishFinnishRadish (talk) 00:58, 4 December 2025 (UTC)Reply
I am of the mindset that you should not have to pick a username that: is unique and not used by any other user; represents you as an individual person; does not include your real name if you are a minor; does not only contain the names of companies, organizations, websites, musical groups or bands, teams, clubs, creative groups, or organized events; does not only describe a particular role, title, position, department, or a group or team of people within a parent organization or group that can be represented or held by multiple people or by different people; is not promotional in nature, and does not appear intended to advertise, promote, sell, gain support, or increase the attention or user-base audience of any person, company, market, product, channel, website, or other good or service; does not imply that your user account will be shared between more than one person; is not offensive, profane, violent, threatening, sexually explicit, or disruptive, and does not advocate or encourage any such behavior (including criminal or illegal acts); does not contain statements that are libelous, contentious, or disparaging, or that disclose any private or non-public information about somebody else (either another editor, or a notable living person); is not deliberately deceptive, confusing, misleading, unnecessarily long, too similar to the username of other accounts, or an attempt to impersonate or falsely represent somebody else (another editor, a notable living person, an "official" Wikimedia Foundation account, etc.) in bad faith; does not imply that the account has explicit ownership of any articles, content, or topic areas, or any kind of "power" or "authority" over other editors, a different application of Wikipedia's policies and guidelines (such as implying that certain policies do not apply to them), or that the account has any administrative or "moderator" access levels or user rights; does not imply the intent to troll, vandalize, disrupt, advertise on, or spam Wikipedia; does not imply the intent to personally attack, harass, or threaten other Wikipedia users; and does imply that you are not here to build an encyclopedia or will use Wikipedia for purposes that it was not created for, just to fix one small typo on a page.
(The point is that you shouldn't have to read any policies or guidelines before contributing to Wikipedia. Requiring registration basically requires any prospective contributor to read the lengthy username policy (of which I have included only the summary) before contributing at all, or else they may be immediately blocked without any chance to contribute due to a bad username. And that doesn't even include choosing "a unique password that you are not using on any other website".) SuperPianoMan9167 (talk) 02:30, 4 December 2025 (UTC)Reply
If picking a username is such a big hurdle, then there could be an option to register under an randomly generated username, like the current TA system. Of course, this would add a lot of burden to WP:CHU but if TAs are such a big problem as some claim, it could be the lesser evil. novovtalkedits08:07, 4 December 2025 (UTC)Reply
You could do something similar to the temp account style, though without the ~2025 at the start (we blocked all creation of usernames beginning that way a couple of years ago, the minute the team decided to prefix the temp accounts with the year of creation). I'd suggest finding a Correct horse battery staple generator instead of doing numbers, though if you do a lot of multilingual or cross-wiki editing, numbers are almost universally readable across most scripts.
If the understanding the numbering scheme would help anyone, it's this: ~YYYY-12345-67: It starts with the year, so when you look at an edit, you'll be able to know if that account is long dead. There are seven digits right now because that's approximately the number we expect to need this year (though it can expand more or less infinitely: ~YYYY-12345-67890-12345-678, etc.). It's in groups of five, because groups of four look like credit card numbers, and groups of six look like SMS account verification codes (which I find difficult to read without my glasses on). WhatamIdoing (talk) 08:33, 4 December 2025 (UTC)Reply
The problem with Correct horse battery staple is ensuring that none of the randomly generated usernames are offensive or derogatory in any culture or when translated to any language. I went through this issue with WP:IRC help disclaimer, where even with the small number of rotating options, I had several complaints about people objecting to being called a dog, or a gorilla, or a cow, or a whale, or black. I had complaints about leaving white, red and yellow in the rotation too, although I ultimately ignored those. --Ahecht (TALK PAGE)14:55, 4 December 2025 (UTC)Reply
Variants of that problem have been solved over and over again by different organizations, and there's no reason why the WMF couldn't open its creaking coffers to specifically pay people to do it again. Also, this is the English Wikipedia. Eliminating words that accidentally come across as rude in "any language" is out of scope as well as impractical. — Hex•talk15:40, 4 December 2025 (UTC)Reply
Ah, I had missed the part of Mir Novov's comment above where he said an option to register under a randomly generated username and misinterpreted this discussion as being about a more legible naming scheme for temporary accounts. Yes, for actual global accounts then it is a problem. — Hex•talk01:20, 7 December 2025 (UTC)Reply
Perhaps we should more obviously advertise that usernames can be changed later. On some websites they can't, so it isn't a default expectation. CMD (talk) 05:35, 5 December 2025 (UTC)Reply
The very least that should be done is to remove the 'ditch this account and dodge all blocks and warnings' button that has been inexplicably included in the drop down menu of user options for all TAs. CMD (talk) 02:52, 4 December 2025 (UTC)Reply
My guess is that there's a legal issue behind that, though it could be pressure from the Growth team to try to push temp accounts into registering. But perhaps it could be made less irritating. WhatamIdoing (talk) 07:43, 4 December 2025 (UTC)Reply
A couple of years ago, I asked editors at one of the Village pumps whether they had contributed as an IP. It was about half and half. Less anecdotally, the logs show a lot of editors first making their first edit as an IP, and then creating an account. Perhaps a "Wow, that worked – I want to do more of it" effect? WhatamIdoing (talk) 01:38, 5 December 2025 (UTC)Reply
We could have the edit button redirect to the login page. The constructive people will make an account, and then we could redirect them again back to the edit page. Most people will understand an account requirement, especially for a project as important as Wikipedia -- possibly increasing our credibility with our critics. An account requirement could serve as a filter for the constructive and unconstructive editors; it wouldn't get rid of them completely, but not as many people would vandalize Wikipedia if it wasn't as easy. The people who refuse to make an account are an extremely small minority. Why should we waste the time of and alienate our current editors when the alternative is creating an extremely small barrier of entry that could filter out some of the unconstructive editors? Mikeycdiamond (talk) 02:26, 5 December 2025 (UTC)Reply
Unconstructive editors will just as easily make an account and vandalize if they are really intent on disrupting Wikipedia. Those who want to vandalize could easily take the extra 20 seconds to register. SuperPianoMan9167 (talk) 02:33, 5 December 2025 (UTC)Reply
Like I said, it wouldn't filter all of them. A large amount of vandalism that I've seen is idiotic stuff that was most likely made by a bored teenager/preteen. If we place a barrier, any barrier, we would remove the fun from vandalism. This could cut out a large percentage of vandalism, which would save hours of editor time. Mikeycdiamond (talk) 02:39, 5 December 2025 (UTC)Reply
Seconding this. The edit history of the banned IP of a school computer I checked recently is exactly what you're describing. It should absolutely be taken into consideration that, while requiring accounts isn't going to stop the type of vandals who are the reason Israel is protected, Annoyance could probably drop its pending changes protection if that happened. JustARandomSquid (talk) 17:48, 6 December 2025 (UTC)Reply
The constructive people will make an account Not necessarily. There are plenty of sites where, when they've given me a "you must sign up to continue", I say "maybe later" and go elsewhere. Anomie⚔02:46, 5 December 2025 (UTC)Reply
About what @Mikeycdiamond said above: We could have the edit button redirect to the login page. The constructive people will make an account.
It's probably at the usability: wiki, though there's always a chance that it's at Meta-Wiki or mediawiki.org. What I remember hearing is that the overall outcome is that pre-edit registration results in fewer good edits, and that every additional question in the Special:CreateAccount form results in fewer completed registrations. WhatamIdoing (talk) 22:27, 7 December 2025 (UTC)Reply
I note the article does not consider the editor time required to deal with disruption, and the article does concede that requiring accounts did eliminate a lot of disruption. Good day—RetroCosmostalk02:28, 8 December 2025 (UTC)Reply
It's awful and was an awful idea from its inception. I understand the reason for it and the solution has always been requiring someone to create a free account. Just like literally every website in the past two decades. Requiring someone to make an account does not change the "encyclopedia anyone can edit" mantra in the slightest. SilverserenC01:05, 4 December 2025 (UTC)Reply
You can find 18 people who disagree with anything. My humble opinion is that a lot of the (former) IP editors were making a big deal of not registering because they liked being a rebel. If they had to register, they would have and would have quickly have got over their "I'm different" glow. Johnuniq (talk) 05:13, 4 December 2025 (UTC)Reply
I talked to one a few years ago who said that he used a lot of different devices, so staying logged in to anything was a hassle. I don't think it was an oppositional motivation; I think he was just doing a rational cost/benefit analysis: If it's easy enough to report the bug, he'd do so; if it wasn't, then he wouldn't bother. WhatamIdoing (talk) 07:47, 4 December 2025 (UTC)Reply
I edit across three devices, -- two autologs, one non-autolog -- it isn't that big of a deal. If you enable autolog, you don't even have to login each time. Mikeycdiamond (talk) 19:19, 4 December 2025 (UTC)Reply
How out of the way is spending 10 seconds logging in? If you didn't want to do it every time, you could spend the 1 extra second to click the remember this device button. Mikeycdiamond (talk) 02:13, 5 December 2025 (UTC)Reply
... which wouldn't solve any problems for the unregistered users that burn through temporary accounts due to having cookies turned off, since the TA system uses the exact same cookie functionality as the "remember this device" button. SuperPianoMan9167 (talk) 22:14, 7 December 2025 (UTC)Reply
How out of the way is spending 10 seconds logging in ...every single time ...maybe in a system that doesn't retain cookies ...and maybe even on shared devices, where you can't save your password?
Anyone want to start a community-wide RfC about this? I believe the WMF will have the final say on whether to disable temporary account editing on the English Wikipedia (and I highly doubt they'll get rid of temp accounts), but it'll still be interesting to see what percentage of the community actually supports requiring an account to edit. I might be in the minority (or majority, who knows), but I don't think temporary accounts are a stupid idea at all. Some1 (talk) 02:18, 4 December 2025 (UTC)Reply
Also, I agree with you about temporary accounts. They have flaws, but implementing them is better than requiring registration IMO as registration creates barriers to good-faith contributors who don't want to or can't make an account. For example, a significant barrier in creating an account (the same one which kept me from having an account for about four months, in fact) is picking a unique, fully username policy-compliant username. SuperPianoMan9167 (talk) 02:42, 4 December 2025 (UTC)Reply
I think this is a mountain out of a molehill. The username policy is very common sense, and any mistake someone does make can be very quickly rectified with a rename request or just making a new account moments later. I put exactly 0 thought into my username when making my account. Athanelar (talk) 14:38, 4 December 2025 (UTC)Reply
Yes, but I think many new users (myself included, when I made my account) get anxious about picking a username when they see Your username is public and cannot be made private later. They might read this as prohibiting username changes and/or not allowing for mistakes, when of course neither of those things is actually true. SuperPianoMan9167 (talk) 17:14, 4 December 2025 (UTC)Reply
Here's more of my opinions: I think ~2025-12345-67 is easier to understand and remember than 2601:402:680:1270:35FA:C71F:B07D:944 (this was one of my IP addresses). If an IP user was on IPv6, there'd be no guarantee that you'd even be able to communicate with them as their "username" changed so frequently. You'd have to hope that you got the most recently used address in the /64. SuperPianoMan9167 (talk) 02:51, 4 December 2025 (UTC)Reply
Yeah I don't understand the complaints that temporary accounts change frequently -- that was already a huge problem, every IPv6 account was functionally a burner. Gnomingstuff (talk) 03:19, 4 December 2025 (UTC)Reply
Yup. Temp accounts only change if you clear cookies or don't use cookies. IPv6 addresses change daily and there's basically no way to stop it other than switching to a static IPv4. (Unrelated: I went ahead and made WP:LLM an information page instead of an essay. Do you think that was a good idea?) SuperPianoMan9167 (talk) 03:23, 4 December 2025 (UTC)Reply
The difference between an IPv6 edit and a TA edit is that it is trivial to add /64 to the IPv6 and see if any related IPs are active. Adding /64 doesn't require a formal opt-in or a promise (punishable by banishment) to be good. Many people without any privilege (including IPs) have reported an IP range for vandalism—that saves time. Johnuniq (talk) 06:23, 4 December 2025 (UTC)Reply
Trivial for users who know how IP address ranges work and who know that a /64 subnet usually represents a single household. Many users that are less technologically inclined don't know either of those things and got super confused trying to follow around an IPv6 user. SuperPianoMan9167 (talk) 17:17, 4 December 2025 (UTC)Reply
Disabling temporary accounts and requiring registration to edit are different. Even if we adopt the pt.wiki precedent of requiring registration to edit articles, TAs will still be used to edit talkpages. CMD (talk) 02:55, 4 December 2025 (UTC)Reply
Description from the file: This graph shows a decline in new registered users from about 160K in 2018 to about 80K in 2025. Yep. And to add to my comment above, I would oppose requiring registration to edit the English Wikipedia mainspace (or any other namespaces, for that matter). From what I've seen on this site, there are more constructive unregistered editors than there are unconstructive ones. Not to mention, Wikipedia is already facing a "drastic" decline in account creation since 2020.[7] IMHO, requiring registration to edit (which includes banning temporary accounts or unregistered users from editing the mainspace) will just accelerate the decline of this project. Some1 (talk) 04:39, 4 December 2025 (UTC)Reply
Is there evidence of that happening? I see the complaint that admins who focus on blocking vandals need some more efficient (and mobile-friendly) tools, but how would a "throw-away temporary account" be any worse for a content creator than someone using a VPN or even just posting one comment at home, one on the school bus, one from school, another on the school bus home, etc.?
A couple of years ago, I checked what mobile editing might be like in my neighborhood. I can go for a five-minute walk and have five different unrelated IP addresses from three different ISPs. You can't use a /64 option to connect those IPs. But under temp accounts, that would be all one temp account number. WhatamIdoing (talk) 08:19, 4 December 2025 (UTC)Reply
What I meant was that content creators are driven away by rubbish, whether from IPs or TAs. That is another way for this project to decline. There will always be plenty of vandal fighters because that's easy and fun and productive. Good content creators are rare and need to be protected. Persisting with the old open-door policy might have bad consequences as it becomes harder to deal with disruption, not to mention AI slop and interference from governments and megacorporations. Johnuniq (talk) 08:53, 4 December 2025 (UTC)Reply
I agree that vandal fighters appear when there is obvious rubbish to be reverted, and that they disappear when the need lessens. But I'm not sure why a good content creator would be deterred by the existence of vandals. After all, it didn't deter us in the pre-ClueBot days, when vandalism persisted on pages much longer. WhatamIdoing (talk) 01:43, 5 December 2025 (UTC)Reply
I have to agree with Some1 and SuperPianoMan9167 that disabling unregistered users from contributing would be a horrible idea. There are way more constructive IPs than vandals, we just pay more attention to vandals because they're the ones who require action. I dislike the recent trend of requiring people to create accounts to see certain contents or contribute to a site (it recently caught onto Twitter, Tumblr, and even Fandom, and it's made me look up all three significantly less), and I do not want Wikipedia to fall into that trap; speaking from personal experience, the primary reason why I even started editing here was because I was able to do so without needing an account, and I would not want to take that experience away from other people. Unnamed anon (talk) 06:42, 4 December 2025 (UTC)Reply
Seconded from me. There are more good IPs than bad ones and it's a pain in the butt for an innocent potential editor to be turned away because they need to create an account. Toby(t)(c)(rw)06:46, 4 December 2025 (UTC)Reply
Agreed -- bad edits might be up, but _all_ edits are up. I've seen way more talk interaction from readers since we stopped making them sacrifice privacy to communicate with us. Feoffer (talk) 15:05, 4 December 2025 (UTC)Reply
November edits in 2025 are down compared to November edits in 2024. Total edits to non-content pages were 1.819 million in November 2024 and 1.1859 in November 2025. That's a 2% increase, which is probably random variation. I don't see a way there to count only the Talk: namespace. That'd probably require help from Wikipedia:Request a query. WhatamIdoing (talk) 05:26, 5 December 2025 (UTC)Reply
And the active users has jumped to 300k. I think TA should be excluded from it because one user can have multiple TA (because they may edit on different devices) Before last month, i think we had 120k active users. JuniperChill (talk) 10:47, 5 December 2025 (UTC)Reply
I don't think we should disable unregistered users. I think the project suffers in some ways for not doing so, but I don't think it should actually be done. But temp accounts are just a license to vandalize. Snokalok (talk) 02:29, 5 December 2025 (UTC)Reply
Earlier this year, I took a look at TA and came to the conclusion that they are a far greater privacy threat than IP editing ever was. I described the details in T388320. The ticket is not public because WP:BEANS, but if you have a phab account and a need to know, I'll be happy to subscribe you. The most gaping exposure has since been fixed, but the concept is still valid and easy to exploit by any semi-sophisticated bad actor. RoySmith(talk)13:39, 5 December 2025 (UTC)Reply
Yup. Stupid and silly. IP accounts ought to go too. "You don't want to sign up to Wikipedia? Well, you're not going to edit it" is the best approach in my opinion. Lemonademan22 (talk) 16:21, 7 December 2025 (UTC)Reply
There seems to be a big bloc of users supporting a ban on IP editing. I'm neutral on this. The pros are privacy and maybe drive-by vandal deterrence. The downside is that Wikipedia will lose a good bunch of typo-correction edits and minor housekeeping. OK, let's assume our editors can take up this housekeeping work. Well, you are not actually really helping with persistent vandals and sockers. They will still create accounts and all that. And the issue brought up of POV-pushers will not be deterred by a simple account creation requirement. Some drive-by vandalism will be stopped, if you're optimistic most would be stopped, but if I'm going more pessimistically then they will likely not care about the account creation requirement and still vandalize. In fact, it may even make it worse as they will discover socking! SPI may become more hellish… OK, let's go optimistic and say that these plagues will be lessened. There is the topic of getting new editors. A good portion of the Wikipedia editor community came from being long-term anon editors. There is a chance we lose a couple dozen or hundred potential contributors just because they can't bring themselves to make an account. But there is some benefit to disabling IP editing. That would be more abstract though and I am not an expert at interpreting the data from the Portuguese Wikipedia about their disabled IP editing. — Preceding unsigned comment added by ~2025-31733-18 (talk) 17:44, 7 December 2025 (UTC)Reply
That is true, and if we force anons into registering the situation will not be much different from POVpushers who don't care about having to make an account, only this time SPI will be flooded because even less people can see that it's just the same person despite being two different temporary accounts. Now checkusers will be absolutely swamped. ~2025-31733-18 (talk) 04:10, 8 December 2025 (UTC)Reply
I have a bit of a cynical take on this temp account issue probably because I'm only really active in the Israel-Palestine conflict topic area. There is obviously a significant asymmetry between the cost of creating a sock account, and the cost of spotting, compiling evidence, reporting and blocking a sock. Our ban/block evasion countermeasures are very limited, thanks in large part to the 90-day data retention schedule that I assume will remain an immovable object. Under these conditions, any account can be viewed as a temporary account where the operator is free to choose when to switch to a different account, there is not much we can do about it in practice, and all of our enforcement mechanisms like topic bans, blocks, logged warnings etc. are mostly unenforceable theater. And with that happy note, I'll bid you good day. Sean.hoyland (talk) 06:36, 8 December 2025 (UTC)Reply
Oh well, I guess the thing here is that unlike CU information for registered accounts, TAIV is much more accesible, so that will ease the burden on CUs and make it easier for admins to block IPs behind TAs, rather than having to open an SPI or add to one every day because User:Example has made their 400th sock ~2025-31733-18 (talk) 13:34, 8 December 2025 (UTC)Reply
What's happening is the opposite. TAIV doesn't access all of the information that CU can, and you often need more than just IP address to determine violations of policy. But since contribs are now grouped by TA instead of by IP, and TA numbering is semi-random, it is completely impossible to tell without CU if a series of TAs are one user whose browser doesn't store cookies properly, one user clearing their cookies to evade scrutiny, one user with more than one device, several unrelated users with a common interest in something because they all live near it and happen to use the same network, a bunch of people from all over the world, or numerous other scenarios. And for each one of those, is it being done in good faith or is it a violation of policy? There is much more work for CUs with temporary accounts active. And besides not being allowed to link an IP with a registered account, we now also aren't permitted to link a TA to a registered account, and we're supposed to avoid revealing the IP of a TA, so a lot of our work just got more complicated, besides there being more of it overall. Ivanvector (Talk/Edits) 14:02, 8 December 2025 (UTC)Reply
Can't you just use the IPs behind it? Or I just might have a Wikipedia:PIXIEDUST perspective... Also, I thought with TAIV you could still see IP contribs, it's just now behind perms? And I think you should not overthink not disclosing the IP of a TA, just not be conspicious with what you're doing, blocking the IP behind it, or just ignore the fact that TAs exist and block the range behind it rather than the surface TAs? ~2025-31733-18 (talk) 16:34, 8 December 2025 (UTC)Reply
TAIVs can still see IP contribs, yes. Ivanvector is fully correct about what it's impossible to tell without CU, but I confess I don't see the issue there - it's not like anyone who wasn't a CU would have been able to make those conclusions about IP edits before TAs, either. -- asilvering (talk) 20:42, 8 December 2025 (UTC)Reply
We need more CUs. We have needed more CUs for years, but we really need more CUs for the next few months, until we get used to the new systems. WhatamIdoing (talk) 00:52, 9 December 2025 (UTC)Reply
Re immovable object: the 90-day data limit is one the WMF said they are open to extending (from the MediaWiki temp accounts FAQ). I think looking into extending this window could be a useful step for enwiki to explore regardless of our consensus position on mandatory registration, though it certainly doesn't solve issues of temp accounts going inactive before that time. Perfect4th (talk) 18:48, 17 December 2025 (UTC)Reply
I don't understand why people think that "well, any other website requires an account" is a good reason to disable anonymous editing. Wikipedia isn't social media or like any other famous website on the Internet. If anything, that's a reason to keep anonymous editing, not disable it. sapphaline (talk) 07:57, 8 December 2025 (UTC)Reply
Exactly. Also, the number of times I've seen a linked tweet on a website, clicked on it to read it in full or watch the video, then been asked to log in to see it, and then gave up, despite actually having an X account, is very large. JustARandomSquid (talk) 08:02, 8 December 2025 (UTC)Reply
No, but I'd say reading a tweet has a comparable pay-off to, say, fixing a typo you just read. I'm saying having to log-in can be to big of a barrier to contributing. JustARandomSquid (talk) 17:36, 8 December 2025 (UTC)Reply
This is Eric from the Product Safety and Integrity team. We know temporary accounts are adding time, energy, and noise to dealing with vandalism on English Wikipedia.
In addition to following the discussion here, we’ve been spending a lot of time the last few weeks listening to this wiki’s functionaries about the specific problems they’re seeing, and discussing ideas for dealing with these issues.
One measure we’ve taken is to tighten the rate limits, for now, on temporary account creation, globally across all projects, to cut down on some of the noise people are seeing while we work on changes to the system. To be clear, the new limits are pretty strict and we expect this to affect places with widely shared IPs, like libraries and schools. While we expect this to be temporary, we have also added a clearer nudge toward account creation to help good-faith editors who get rate limited.
We’re also in the middle of a set of quicker, smaller changes to surface more information more easily about potential vandalism by temporary accounts. Some are done already, with the rest coming this week:
Highlighting temporary accounts on content and discussion pages (T392775)
Added a link to “abuse log” when viewing IP ranges (T412341)
Added some basic information about temporary account and IP connections to Special:Contributions and SpecialIPContributions (T412218)
Added links to IP range modifiers (e.g. /16, /24, /32) directly to Special:IPContributions (T409179)
Added a link to /64 IPContributions when revealing an IPv6 IP (T411943)
Tagging temporary account creations happening via Special:MyTalk, for blocked IPs (T398673)
Displaying higher number buckets for “temporary accounts from all associated IPs” in UserInfo card (T412212)
Showing a tooltip to indicate whether the IP is the latest used (T411185)
Another clear theme of the discussion here is whether to deal with these issues by simply banning unregistered editing.
In past discussions, some volunteers have criticized how the Foundation represented its past research about the effect of banning unregistered editing on the two wikis where it has at least briefly taken place. We discussed this internally and agreed that some of our public comments were overstating the strength of the evidence. We’ve updated our temporary accounts FAQ to make it clearer that the studies we’ve done show mixed results and that their observational nature makes it difficult to draw firm conclusions at all. Thank you to those who pointed out these issues.
Even so, we’re spending the time to make temporary accounts work because we believe editing without registration is a founding principle for a reason. Even though it may lead to more bad-faith editors, we think it is likely that the ability to edit without creating an account has led to more people trying to edit for the first time, and more people eventually creating accounts, sticking around, and becoming respected editors.
Streamlining anti-vandalism work in the temporary accounts system is a focus for our team for the next few months. If you have specific ideas that you think could make the system work better, now is a great time to suggest them to us on our team talk page. EMill-WMF (talk) 22:45, 15 December 2025 (UTC)Reply
Even so, we’re spending the time to make temporary accounts work because we believe editing without registration is a founding principle for a reason. Even though it may lead to more bad-faith editors, we think it is likely that the ability to edit without creating an account has led to more people trying to edit for the first time, and more people eventually creating accounts, sticking around, and becoming respected editors.
From where I'm sitting this is not what's happening or going to happen.
Instead all you're going to achieve with this absurd adherence to the "no account needed" open door policy is drive away more and more experienced editors like myself who are increasingly fed up and don't see the point in contributing anymore because of the circus it's becoming as disruptive TAs run rampant and bad actors can just immediately ditch and switch them without consequences given you've hidden the easiest way to demonstrate a bad actor (their IP address) behind tools only a handful of users have or feel comfortable using, and admin responses are taking far longer in my experience to deal with it and there's less of a tendency to block IP ranges as in the past but just whack-a-mole on each instance of a TA which by the time it's blocked has already been discarded for a new one.
It is not 2001 anymore, where Wikipedia was a niche website of enthusiasts on a tiny internet base that needed to grow. It's 2025 where Wikipedia is one of the most visited websites on the planet, everyone has a portable device that allows immediate access to the internet 24/7, and is constantly subject to disruption.
All this introduction of TAs feels like is living in an area that's a burglary hotspot and being told to remove your door locks because of a theoretical delay for paramedics in an emergency... Rambling Rambler (talk) 23:27, 15 December 2025 (UTC)Reply
I think you are operating on the assumption that most unregistered users are vandals. As far as I can tell that's not true.
I know anecdotal evidence is weak, but I know that I probably wouldn't have made my account if I wasn't able to edit as an IP.
Also, re bad actors can just immediately ditch and switch them without consequences: Eric just said One measure we’ve taken is to tighten the rate limits, for now, on temporary account creation, globally across all projects.
@SuperPianoMan9167 I'm not assuming most people using TAs are vandals, what I'm arguing is that those TAs that are disruptive are increasingly a problem compared to when it was IPs and the very nature of them is more prone to abuse by those who are vandals.
Just as an example when it was IPs and you had an article on something recently prominent, you could easily show that there it might be one specific person in a geographic area that was good-faith but still causing disruption and request a temporary IP block just for them while allowing other IPs to keep contributing. Now however my only option is to immediately go to RFPP and block everyone without an account (which is always backlogged to hell anyway) which inherently defeats the entire point of TAs to begin with and/or spend hours playing whack-a-mole. It's just a grind.
Post to the WP:DRAMABOARD that User:203.0.113.255 is screwing up the article. An admin temporarily blocks the IP address.
New system:
Post to the WP:DRAMABOARD that User:~2025-12345-67 is screwing up the article. An admin looks up the TA's IP address and then temporarily blocks the IP address.
I can say from experience that often times IPs and IP legacy history gets overlooked. Likely because it's changed the AIV workflow in a way that has vastly increased the time required for a complete investigation. ScottishFinnishRadish (talk) 11:52, 16 December 2025 (UTC)Reply
If all the necessary info (TA contribs, other TA contribs on the same IP, legacy IP contribs) was available on one page instead of three different pages, would that problem be solved? SuperPianoMan9167 (talk) 13:31, 16 December 2025 (UTC)Reply
You don't need the TAIV user right to report that User:~2025-12345-67 is vandalizing an article, or that a series of TAs are vandalizing the same article, or articles on the same subject. WhatamIdoing (talk) 20:15, 16 December 2025 (UTC)Reply
Agree with this. I've still been able to do antivandal work even without TAIV (I'm mad at past me for procrastinating when making an account!) because most of the time vandalism or LTA/sockpuppet behavior is glaringly obvious. SuperPianoMan9167 (talk) 20:21, 16 December 2025 (UTC)Reply
Autoblocks are 24 hours. There have been discussions about adjusting that, but then we'll end up making all TA blocks on the underlying IP one set amount, regardless of the level of disruption. ScottishFinnishRadish (talk) 22:45, 16 December 2025 (UTC)Reply
It seems like that's a feature ripe for extension. What do you think would be better: a different default time (31 hours is useful for school-based problems), manually overriding the time, or adding some jitter to the setting (24 hours + random amount), so that it won't always be obvious when to try again? WhatamIdoing (talk) 22:51, 16 December 2025 (UTC)Reply
Concurring with SFR above. From my experience admins now just see the TA and block that without also blocking the IP. So you'll see people report TA after TA that are clearly the same person yet it pops back up immediately while previously it would've been a /16 or /64 block and move on. Rambling Rambler (talk) 12:18, 16 December 2025 (UTC)Reply
Streamlining anti-vandalism work in the temporary accounts system is a focus for our team for the next few months. If you have specific ideas that you think could make the system work better, now is a great time to suggest them to us on our team talk page. --Eric
Here's the problem with that rationale. IF the reason for TAs is that IPs are private information and shouldn't be accessible, then TAIV existing is the exact same privacy violation.
It's not that much better though. I mean christ, if we assume that it is worry over personal data that's the justification for TAs existing then we currently have a logic where you can be trusted with the ability to view someone's IP yet not trusted to edit an article related to Israel-Palestine because Extended Confirmed requires 500 edits minimum.
Rambler, the WP:TAIV requirement is six months plus 300 edits plus individual approval. So that's six months (median new account activity: 1 day), 300 edits (=top 1% of accounts in Wikipedia's history), and personal judgment of the granting admin. Contributing more than 99% of editors without getting blocked is not "a low barrier".
Yes, really dedicated bad actors can game any system. But we're mostly dealing with jerks on the internet rather than an advanced persistent threat. We might need to get a few admins or even a couple of CUs and Stewards to sort out a way to block the person who's harassing the OP, even if it means blocking most of a city or contacting the user's internet providers. But this isn't actually a different system underneath: we have always had to deal with IP-hopping jerks, and admins can still block IPs. WhatamIdoing (talk) 20:28, 16 December 2025 (UTC)Reply
I'm curious, but why "I probably wouldn't have made my account if I wasn't able to edit as an IP"? I can think of two reasons people are averse to creating accounts. One is that they believe IP editing is more private. The other is that creating an account is too much hassle. Which of those was it in your case, or was it something else? RoySmith(talk)00:00, 16 December 2025 (UTC)Reply
OK, I'll call that a subset of "too much hassle". One of the ideas I've seen kicked around is to give users the opportunity to have a random-ish username chosen for them, which they could change at some point in the future. If that had been available to you at the time, would you have found it useful? RoySmith(talk)00:08, 16 December 2025 (UTC)Reply
Also, if you check my IP contributions, you'll see that yes, I did start editing using VisualEditor (shame on me!) and only later switched to wikitext. I found it helpful at first but I don't bother with it now as I feel more comfortable with source editing. SuperPianoMan9167 (talk) 00:17, 16 December 2025 (UTC)Reply
No need for shame; different approaches appeal to different people. It's all good. And some aspects of editing tables are much simpler. isaacl (talk) 02:59, 16 December 2025 (UTC)Reply
I'm guessing the main reason Wikipedia allows users to edit without an account is because it removes the need to create an account just to make a couple of edits (as I don't like it when websites force me to create an account even just to read something.). This is because even the vast majority of NAs have less than 10 edits (when accounts become autoconfirmed). When I first created my account, I did so mainly to hide my IP, and only made ~20 edits in 2020, before starting out in late 2023. JuniperChill (talk) 18:42, 16 December 2025 (UTC)Reply
Editing without needing to create an account lets people "try before they buy".
Unregistered editing is also done by long-time editors who are on a different computer system. Why bother logging in to the work/school/phone/other browser, if you're just reverting this one bit of vandalism? WhatamIdoing (talk) 21:00, 16 December 2025 (UTC)Reply
don't see the point in contributing anymore because of the circus it's becoming as disruptive TAs run rampant and bad actors can just immediately ditch and switch them without consequences
As a TA user; please let us dismiss the “create account” header that sits on every page. The only way to get rid of it is to exit the account and it leads to me making a new TA for every comment. ~2025-41188-39 (talk) 16:31, 16 December 2025 (UTC)Reply
So, why don't you just create an account? I'm not being snarky here, I'm just trying to understand the factors that make people not want real accounts. RoySmith(talk)16:51, 16 December 2025 (UTC)Reply
Latest comment: 4 days ago15 comments13 people in discussion
There either currently is a dispute at WP:ANI about writing on another user's user page, or is at WP:ANI a record of such a dispute: Wikipedia:Administrators'_noticeboard/Incidents#Harassment_by_CarterDillard. As can be seen, at least two editors, including myself, told the editor who made the note on another editor's user page that modifying another user's user page is highly irregular in Wikipedia culture. The editor who modified the user page then replied: I was not aware of the policy on user pages (if it's just culture, it should be made a policy). I looked at the user page policy, and I didn't find a statement that explicitly discourages making an entry on another user's user page.
The user who made the questionable post appears to be seeking to right great wrongs, but that is not the issue here. They didn't know that writing on another user's user page is improper, because there is no written rule saying that it is improper.
It's under WP:USERTALKSTOP. "In general, one should avoid substantially editing another's user and user talk pages, except when it is likely edits are expected and/or will be helpful. If unsure, ask." GeogSage (⚔Chat?⚔) 20:27, 3 December 2025 (UTC)Reply
We certainly should not make a brightline rule about this. There are lots of good reasons for editing a userpage that is not your own. — xaosfluxTalk20:56, 3 December 2025 (UTC)Reply
^This. If editing someone else's talk page were the user in question's only issue, it could easily be resolved by a simple conversation with them, pointing them at WP:USERTALKSTOP and explaining things. It's all the other stuff that made this situation in particular rise to the level of an ANI report. Hard cases make bad law and all that. Writ Keeper⚇♔20:59, 3 December 2025 (UTC)Reply
(edit conflict) I think no; bad cases make bad policy. It seems to me that the problem here wasn't that the user wrote on another user's user page, it was what they wrote and would have been a problem had they written it anywhere. Writing on another user's user page isn't inherently problematic, and I don't think this is a good reason to add policy language suggesting that it is. I say this as someone whose user page has been semiprotected since 2016, though. Ivanvector (Talk/Edits) 21:03, 3 December 2025 (UTC)Reply
Seems to me an unnecessary extension of policy; a huge amount of what we do is done through convention, guidelines, and generally good faith. In particular in this matter, many user pages have other (not the specific editor) watchers who often will intervene and remove stuff not needed. On mine own page, for example, i count seven or eight assorted editors who have removed vandalism or "personal" comments ~ not to mention the times i have done so myself (including sixty consecutive edits by one person; simply a matter of a couple of clicks to revert all of them). In the case of actually vile attacks (which i am too gnomic to be the recipient of), we have other policies against them, and anyone who is of a mind to make such an edit is going to anyway, despite another policy against it ~ LindsayHello12:00, 5 December 2025 (UTC)Reply
If someone else edited my userpage, I'd feel a bit intruded on, as if someone had come into my garden and poked around. By itself editing someone's userspace isn't a major transgression, but it's intrusive and somewhat controlling. There are certainly circumstances where a sysop or someone duly elected to enforce conduct issues and behavioural norms might need to edit userspace and I don't object to appropriate edits; but I'm very much not a fan of the self-appointed userspace police.—S MarshallT/C12:09, 5 December 2025 (UTC)Reply
Two more examples against a new rule: I recently wrote on another Editor's Talk page, after I noticed they had edited another user's comment (for housekeeping reasons) and marked the edit 'minor.' Seems better than running straight to an Admin or noticeboard over trifles, and breadcrumbs of Talk page feedback have many different good uses. A User can also make their Talk page obnoxious with content and widgets, unintentionally or otherwise, and I would not be overly concerned if somebody turned those off temporarily for the sake of facilitating a discussion. --Edwin Herdman (talk) 21:43, 6 December 2025 (UTC)Reply
RfC: Replace text of Wikipedia:Writing articles with large language models
The new draft guideline defines an LLM, strongly advises editors not to use LLMs to add content to Wikipedia, and describes how to handle LLM-generated content that is already present.
Support, per a lot of the arguments made in the previous RfC. I quibble with "unreviewed", but regardless it’s a big improvement on the current policy. 'Perfection' is not required, even an incremental improvement is constructive, and future RfCs can always address quibbles. Kowal2701 (talk) 12:43, 4 December 2025 (UTC)Reply
Support Consistent with current practice. I'd like future RfCs on mandating LLM-use disclosures and clarifying acceptable limited uses like source-searching and copyediting. Catalk to me!13:29, 4 December 2025 (UTC)Reply
That's one reason why a little bit longer RFCBEFORE might have been helpful, as I know I for one strongly supported the previous version but frankly don't have time to keep up with the pace of this conversation. -- LWGtalk16:29, 4 December 2025 (UTC)Reply
Don't beat yourself up about it; there's a decent support base here. I think a fair amount of us are tired of endless workshopping and RFCBEFORE and just want to get things over the line. There's never going to be something perfect which will satisfy everyone and cover all the bases, and we can always modify once it's in place (which is literally what we're doing currently with NEWLLM, so...) Athanelar (talk) 14:45, 5 December 2025 (UTC)Reply
"tired of endless workshopping" and "we can always modify once it's in place" are directly contradictory. Tired of workshoppibg, but we can always workshop more later? Have you considered just stopping? NEWLLM is only two weeks old, it doesn't need to be expanded so quickly. If this RFC doesn't succeed, consider just walking away from the whole issue for six months or a year. If editors who have worked on this are tired of working on it, consider stopping working on it, rather than "just want to get things over the line". Levivich (talk) 15:53, 5 December 2025 (UTC)Reply
No need to apologize. I'm more frustrated with a large part of the community that is allowing their anti-AI dogma to force us to rush decisions that ought to be made deliberately. The gudieline as it currently exists, for example, is so vague as to be useless, but it was nonetheless forced through because editors felt the need to "do something" without thinking about what it is we're trying to accomplish. We are shooting ourselves in the foot by encouraging PAGs that are hostile to LLMs and will result in people being rude and dismissive towards new editors who might innocently, but improperly, use an LLM. voorts (talk/contributions) 15:06, 5 December 2025 (UTC)Reply
Discussion was ongoing for 2 weeks with 100s of comments, it's challenging to make a single proposal for an RfC because people with strong and polar opinions engage more while the majority that are moderate don't. People being rude can be dealt with by our current policies. It's not a coincidence that the most hard-line opposition to LLM-use comes from NPP, AFC, and LLMN/AINB, it's not right that people defend LLM-use but don't engage in any clean-up. Kowal2701 (talk) 15:27, 5 December 2025 (UTC)Reply
To be fair, I haven't done a ton of NPP recently. I still think we can deal with incompetent AI use without banning good AI use. To paraphrase myself from one of the discussions at the new gudieline talk page, it's fantasy to think that banning LLM use will stop new editors and bad actors from misusing AI (which is already a CIR issue); all it will do is bar productive AI use and result in litigation about whether AI was used, rather than focusing on whether its use was disruptive. voorts (talk/contributions) 17:09, 5 December 2025 (UTC)Reply
The community isn't really rushing if anything it took Wiki a long time to get a guidline on AI(and personally I think while the current one can be improved it is not useless but beneficial and long overdue.) GothicGolem29(Talk)22:03, 5 December 2025 (UTC)Reply
Oppose The "Do not use an LLM to add unreviewed content" section is self-contradictory about what is and is not allowed. The guideline as whole makes no mention of disclosure, per Ca needs to mention accepted uses, not relying on machine detection and (sadly) also needs to be explicit about assuming good faith and not harassing editors. Thryduulf (talk) 13:54, 4 December 2025 (UTC)Reply
@Thryduulf Since you replied to me below: what exactly do you find contradictory? That section disallows a bunch of stuff, but I don't see where it explicitly allows anything, so I'm not seeing any contradiction. Toadspike[Talk]02:05, 5 December 2025 (UTC)Reply
The section starts off by saying "Don't Editors should not use an LLM to add content to Wikipedia, whether creating a new article or editing an existing one." which is contradicted by nearly everything else in the section which is more nuanced and implicitly allows stuff. It also contradicts other policies and guidelines that (implicitly or explicitly) allow AI in some circumstances.
If multiple people see a section as self-contradictory (which they do) and multiple other people read the exact same words and don't see that (also apparently true), then that's evidence that the text is not clear enough to be a useful guideline. Thryduulf (talk) 02:30, 5 December 2025 (UTC)Reply
I think the different wordings between the first sentence and the rest of the section are deliberate. The first sentence is stronger, yes, but having a single clear sentence would be useful when dealing with people who refuse to listen to or read much of anything, which is in my experience most people using LLMs poorly. I do not see any direct contradictions within this proposed guideline. Could you please name the "other policies and guidelines that (implicitly or explicitly) allow AI in some circumstances" that are contradicted? Toadspike[Talk]08:25, 6 December 2025 (UTC)Reply
The first sentence states don't add content using LLMs, with no qualification, while the other sentences state that unreviewed LLM content should be added, which is a qualification.
The examples listed below by Anne drew of 'good LLM use' (whatever your position on that) make the contradiction clear: the first sentence makes the good LLM use impermissible, the other sentences imply it is permissible in some cases. Katzrockso (talk) 08:34, 6 December 2025 (UTC)Reply
Oppose - first, that RFCBEFORE was open for like 12 hours. That's not enough time. Substantively, I oppose "do not use LLMs..." as overly broad, totally unenforceable, and just a bad idea overall, like saying "Do not use a word processor...". We want to prohibit people from cutting-and-pasting LLM output wholesale onto Wikipedia (in articles or on talk pages); we do not want to prohibit people from using LLMs for any reason or in any way. If I want to use an LLM to start a draft and then I personally edit that draft to improve it, fact check it, etc., nobody on the internet will ever know I did that and, assuming my output is policy-compliant, there is absolutely no reason to prohibit me from doing it. You all have no idea if I started this comment with an LLM, or had an LLM write it. Or if I asked an LLM to check the grammar, or suggest improvements. Frankly, LLMs write better than some people write on their own; for some, an LLM-written comment is better than one written without the help of an LLM. We don't want to discourage people from using LLMs in any way, because they are useful. They can be used as dictionaries, thesauruses, search engines... wholesale copy-and-pasting articles/comments isn't the only way to use them. Additionally, A large language model (LLM) means any program that can generate natural-language text either in response to prompts or by transforming existing text. is not what a large language model is; see the Wikipedia article for a definition. Please, please, please, not yet another Wikipedia guideline that redefines words to mean something different on Wikipedia than they do in the real world. If you want to expand the existing guideline (which should be expanded), say "do not copy-and-paste without checking..." (it doesn't need to be said three times, just once is fine) and then have the "handling LLM-generated content" part (the word "existing" is unhelpful, because it would apply to "new" LLM-generated content as well as existing content). Levivich (talk) 14:50, 4 December 2025 (UTC)Reply
V3 was posted 22:37 Dec 3 according to Special:Diff/1325583018. Was it posted somewhere else on Nov 24? Best practice, especially for site-wide new rules, is to announce the intent to end the RFCBEFORE and launch the RfC, and ask if anyone objects, and then wait at least a day, preferably more than one, for any objections. "Are we going to categorically prohibit all usage of LLMs on Wikipedia" is a question the community has already answered with "no" in prior RFCs, and should probably be asked on its own before we try to write guidelines that implement such a major change. Levivich (talk) 15:03, 4 December 2025 (UTC)Reply
I'm sure I speak for everyone when I say no apologies necessary, we all make mistakes :-) Another thing on the substantive draft: the reason that the current WP:NEWLLM guideline is so short, almost comically so, is because that's all that we've got consensus for so far. But that guideline, those words, are what has consensus. And it says, Large language models (LLMs) can be useful tools..., so to rewrite the guideline into an absolute prohibition runs contrary to that consensus statement. LLMs can be useful, which is why their use should be permitted within certain boundaries. The current guideline continues ... but they are not good at creating entirely new Wikipedia articles. That has consensus, too; almost everyone will agree that having an LLM write an entirely new article, and copying-and-pasting it onto Wikipedia, is disruptive because of the high risk of error. An expansion of WP:NEWLLM needs to build upon that foundation, not try to re-write it into an absolute prohibition. A better approach to expanding the guideline would be a "LLM Do's and Don'ts"-style guide, that teaches people the proper and improper ways of LLM use--when are they useful and when are they disruptive. It should explain why the "don'ts" are "don'ts," and suggest better "do's". Levivich (talk) 15:14, 4 December 2025 (UTC)Reply
It's worth reading through the RFCBEFORE if you haven't already, as much of this has already been discussed there. Namely, a few of us pointed out concerns with carving out acceptable use cases in a guideline that is essentially fundamentally designed to prohibit, not to permit. The goal is to tell people what they shouldn't do. If you include a section explicitly detailing the acceptable uses, then anyone who gets accused of using them unacceptably is just going to claim they were doing one of the acceptable things (I've already seen it happen; "oh, I didn't generate my comment with an LLM, I just used Grammarly on it and that's why it sounds like LLM prose")
This also really isn't an absolute prohibition; it still provides a carveout in the language of "unreviewed" content. It says you "should not" use an LLM to generate content for Wikipedia, not that you "must not." The only thing it absolutely prohibits is generating new articles from scratch with LLMs, which is (from what I see) generally interpreted as the meaning of WP:NEWLLM anyway, so there's no change there. Athanelar (talk) 16:58, 4 December 2025 (UTC)Reply
I disagree with "a guideline that is essentially fundamentally designed to prohibit, not to permit. The goal is to tell people what they shouldn't do." - the guideline should be designed to guide, meaning to instruct, which means both prohibitions and permissions, what they should and shouldn't do.
I disagree with "anyone who gets accused of using them unacceptably is just going to claim they were doing one of the acceptable things". This is an old argument on Wikipedia that I've seen raised many times, and I think it's bad advice, contrary to the fundamental purpose of guidelines, which is to teach. The notion that we shouldn't outline what is acceptable because people who do unacceptable things will claim it's acceptable is nonsensical to me.
I disagree with "It says you 'should not' use an LLM to generate content for Wikipedia, not that you 'must not.'" That is the exact reason why "should" shouldn't be used in policies and guidelines. "Must" and "may" are clear; "should" is ambiguous. It's too bad that many of our policies and guidelines use "should" go mean both a requirement and a suggestion. We must not continue this practice.
Basically, I disagree with you on the fundamentals for what makes a good guideline, and what the purpose of the LLM guideline ought to be. Fundamentally, you want a clear rule you can use to take action against people who do something you think shouldn't be done. That's not how rules on Wikipedia work, or should work. Our rules are not laws, they are guides and descriptions of practice (descriptive, not prescriptive). Levivich (talk) 17:33, 4 December 2025 (UTC)Reply
Completely agree, and frankly I don't understand the justification for keeping important background information out of the guidelines. Guidelines aren't information pages. We have plenty of information already about why using LLMs is usually a bad idea at WP:LLM. is the reason given for why NEWLLM does not justify itself. I disagree. Guidelines are absolutely information pages. If we don't explain why we don't want articles to be generated with LLMs, it gives the impression that their use is banned based only on Wikipedians' opinions.
If WP:LLM is the page that explains why using LLMs is a bad idea, that should be the guideline, not another entry in a series of incremental restrictions on LLM use. Making such incremental restrictions is more confusing to newbies then just explaining everything in one place.
I prefer to read NEWLLM not as a ban on LLM-generated articles, but as a piece of generally accepted advice saying "LLMs are bad at writing Wikipedia articles, so it's generally not a good idea to use them." Although a significant number of editors read NEWLLM as "LLM-generated articles are prohibited and subject to deletion."
Confession: Other, experienced editors already pointed out the problems with vague guidelines in the RfC. I argued against them. I now understand why they opposed. SuperPianoMan9167 (talk) 20:20, 4 December 2025 (UTC)Reply
Support per my previous reasoning, which I'm just going to copy-paste because it remains unchanged: "Having no policy effectively is encouraging LLM use. The longer we remain in that state, the longer we are encouraging LLM use, and the longer it accumulates on Wikipedia [...] Going three years [without] AI policy has done substantial damage to the integrity of Wikipedia, and frankly we're probably near the precipice where that damage becomes irreversible." To this I will add: the longer we remain in this state, the longer the project is fundamentally misleading bordering on lying to our readers, given the huge advertising in the past few months about how Wikipedia is the human alternative to AI. Gnomingstuff (talk) 15:05, 4 December 2025 (UTC)Reply
@Gnomingstuff This is not proposing to adopt a policy but to replace one guideline with a different guideline. I'm also going to have to ask for a citation for pretty much all of your justifications, particularly Going three years [without] AI policy has done substantial damage to the integrity of Wikipedia. Thryduulf (talk) 15:27, 4 December 2025 (UTC)Reply
First, stop pinging me.
Second, I know what this is a proposal for. My view is that we need a policy but in the absence of that a guideline is the next best thing, and that this guideline is the improvement.
Most of the justifications should speak for themselves, but regarding the advertising push I am referring to stuff like [11] (which, among other things claimed that Wikipedia had AI guidelines when it didn't at the time) Gnomingstuff (talk) 15:47, 4 December 2025 (UTC)Reply
Not exactly. The article you link to says "In all cases, volunteers create and enforce guidelines for responsible use of AI tools...", that was on Nov. 10, and by then WP:NEWLLM had already been created and was in the middle of the RFC to promote it to a guideline. I am also curious why you think that "substantial damage to the integrity of Wikipedia" has occurred in the last three years due to the lack of an AI guideline. Can you point to an example of a false statement in a Wikipedia article introduced by LLM usage that remained in mainspace for a significant amount of time, that wouldn't have remained if we had had an AI guideline? Levivich (talk) 16:12, 4 December 2025 (UTC)Reply
Not to speak on @Gnomingstuff's behalf, but from my point of view the lack of guideline has meant that disruptive use of LLMs by editors has meant protracted discussions at ANI and other noticeboard while editors and admins um and ahh over what to do about it. qcne(talk)16:28, 4 December 2025 (UTC)Reply
As far as damage to the integrity of the encyclopedia: I refer you to your previous stance here:
We don't know how many [need to be dealt with]. But even if a mere 10% are bad -- 9,000 articles -- PRODing 10 a day would take 3 years. And if it's higher than 10%, if it's 50% bad, then we're talking over a decade to PROD them all. To go through them case-by-case is totally impossible, in my view.
Substitute "PRODing them all" with "fact-checking them all" (fact-checking being much more time-consuming than PROD), and "9,000 articles" with "some unspecified but large amount of edits" (edits being much more numerous than articles).
As a data point, there are currently around 4,376 drafts identified and/or declined as likely AI-generated in the past 6 months, not counting anything deleted for being older than that, and around 3,900 articles identified as possibly containing AI-generated text, not counting anything already fixed or still undetected. Are we at 93,000 unreviewed AI-generated edits? I think we're easily on track for that in the next couple of years. Gnomingstuff (talk) 17:11, 4 December 2025 (UTC)Reply
unsurprisingly there has been no response to this; guess potentially problematic edits are only a problem when there's a real person you can scapegoat and bully over them Gnomingstuff (talk) 23:39, 7 December 2025 (UTC)Reply
Support I think this is a very reasonable (and workable) proposal. I also think if future edits are desired, this structure is a good base. --Enos733 (talk) 16:04, 4 December 2025 (UTC)Reply
Oppose this gutted version, support version 2 from the RFCBEFORE As much as this would be an improvement on WP:NEWLLM, in it's current state it's just going to require an immediate RFC to strengthen it, and I'm tired of spending all my Wikipedia time on AI issues. Specifically we need these sentences back in the guideline:
Define appropriate scope: LLMs, if used at all, should assist with narrow, well-understood tasks such as copyediting. New editors should not use LLMs when editing Wikipedia.
Clearly state what CIR looks like for LLMs: If the editor cannot confidently check and correct the output, they should not use an LLM for that task. LLMs should not be used for tasks in which the editor has little or no independent experience.
Set an expectation of disclosure: Editors should disclose LLM assistance in the edit summary (e.g. "copyedited with the help of ChatGPT 5.1 Thinking"). This helps other editors understand and review the edit.
I also support Thryduulf's suggestion of adding something about AGF and biteing, since that is a common concern raised about stronger AI guidelines. -- LWGtalk16:45, 4 December 2025 (UTC)Reply
WP:LLM would need changes if it became a guideline, which brings back the original issue: there is no agreement on the changes. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 19:43, 4 December 2025 (UTC)Reply
I would prefer to use @Qcne's proposal as a basis for a guideline than WP:LLM, which I find bloated. If we can resolve the contradictory language and section header, and potentially incorporate some of LWG's suggestions, I think we can get something pretty strong approved! NicheSports (talk) 19:58, 4 December 2025 (UTC)Reply
How is WP:LLM bloated? Aren't guidelines meant to educate? The rules are not intended to be laws. I don't think "you can't use LLMs because Wikipedians say so" is a good approach to a guideline. SuperPianoMan9167 (talk) 20:02, 4 December 2025 (UTC)Reply
Oppose as not strong enough. This isn't even an improvement on the status quo, so I see no reason to support this.The weakest of weak supports this version is a little tougher than previous versions, and it is a faint improvement of the status quo of no guidance at all. Nonetheless! – AI-generated text isn't appropriate for a human encyclopedia, period. Re Ca and Thryduulf: there are no accepted uses. Cremastra (talk·contribs) 16:48, 4 December 2025 (UTC)Reply
They can disagree all they want. Doesn't make the facts any different. There are no valid uses of LLMs on Wikipedia. If someone cannot summarize or paraphrase a source without resorting to AI slop, they lack competence to edit the article in question. Support stronger prohibitions. oknazevad (talk) 07:02, 8 December 2025 (UTC)Reply
There are many valid uses of LLM models on Wikipedia. An important one, which a guideline on LLM should perhaps encourage, is to ask the LLM to identify factual mistakes in WP articles. However, the editor should then check the outcome "manually" (unassisted) using the cited sources and other reliable sources to verify the proposed change. Gitz (talk) (contribs) 09:42, 8 December 2025 (UTC)Reply
So rather than manually verifying the facts in an article, you ask an LLM to do it for you, and then you... manually verify its whole output? I'm not seeing the improvement. Athanelar (talk) 09:47, 8 December 2025 (UTC)Reply
Yesterday I asked ChatGPT to verify an article. It found that the subject had not won a literary award, but had only been shortlisted. It was right and I corrected the mistake [12]. I wouldn't have been able to spot this mistake alone. It's a minutia that doesn't raise a red flag, so it gets unnoticed. Gitz (talk) (contribs) 10:15, 8 December 2025 (UTC)Reply
@Gitz6666except that the source actually said she won the award, which apparently you didn't check: The Unbreakable Miss Lovely (p. 60 on that eBook; or p. 38 on this one): "The first review arrived the morning of her birthday. It was the only one that would turn out not to be positive. (She would win an “Edgar” from the Mystery Writers of America in nonfiction for the book.)" That is the only relevant mention of "Edgar" in the text.
This is pristine evidence that LLMs can't be trusted to check sources, because they don't actually read them. If sources are contradicting each other, a better approach is needed that just doing what the LLM says is correct. Cremastra (talk·contribs) 13:31, 8 December 2025 (UTC)Reply
We already have a "better approach", the one I followed: to check the official website of the award, which unequivocally reports that she was nominated and Legacy of Death by Barbara Levy won the award.[13] This is only one of the many mistakes that can be detected using an LLM. Gitz (talk) (contribs) 13:50, 8 December 2025 (UTC)Reply
OK so it appears as though this award gives out "scrolls" to the shortlisted/nominated books [14], which some have interpreted as "winning" an Edgar Award ([15]). Misleading at best to say that that is "winning" an Edgar Award. Katzrockso (talk) 14:08, 8 December 2025 (UTC)Reply
Oppose with disappointment and some frustration. Agree with Thryduulf on Do not use an LLM to add unreviewed content" section is self-contradictory which was the exact feedback I gave at the RFCBEFORE, which @Qcne didn't engage with. I would enthusiastically support this interpretation but it is not clear from the language in the current proposal that this is what is intended. As written this contradictory language will cause significant confusion "in the field" especially for newer editors. Minor changes could have resolved this. The RFCBEFORE should have gone on longer to address this type of feedback. NicheSports (talk) 16:49, 4 December 2025 (UTC)Reply
I know it's faux pas to modify a guideline during RfC, but would your vote change if we changed the section header like so;
−
Do not use an LLM to add unreviewedcontent
+
Do not use an LLM to add content to articles without thorough human review, or to create new articles
I think this brings the section header in line with the body of the guideline and the spirit of its intent, and should I think be relatively uncontroversial as a result.
No. In addition to not addressing most of my points this just demonstrates it's still very unstable and thus not ready to be considered for adoption. Thryduulf (talk) 17:16, 4 December 2025 (UTC)Reply
I think it'd be better as "Do not use an LLM to modify or add content to Wikipedia articles, or to create new articles." --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 17:19, 4 December 2025 (UTC)Reply
No, but I would support "Do not use an LLM to add content to articles without thorough human review." It should also say something about how we are responsible for what we publish on this website regardless of what tools we used to draft the text, so the review should be as "thorough" as is necessary to ensure compliance with policies, because if the text is not compliant, the editor will be held accountable for it. I wouldn't support the whole proposed guideline just with this one change, as I still don't support other parts of it, but it would bring me a step closer. Levivich (talk) 17:25, 4 December 2025 (UTC)Reply
This doesn't address the contradictory language at all. I can draft something later that would, but unfortunately the RFC is already open. Bah. NicheSports (talk) 17:35, 4 December 2025 (UTC)Reply
LWG's changes are basically just returning to V2 of Qcne's proposal, which was controversial during the RFCBEFORE.
Ultimately, there's no pleasing everyone here. The LLM hardliners like me won't be pleased by more permissive language, and the permissive ones won't be pleased by more restrictive language. I think this version really is the best middle ground. Athanelar (talk) 18:08, 4 December 2025 (UTC)Reply
I'm not opposing because this is too strict or too permissive, I'm opposing because it is contradictory. We need to stop rushing LLM PAG RfCs. Agree with Kowal2701, let's remove the RFC tag and work out this issue. But I can't do that because I have !voted. Qcne can, or an uninvolved editor. NicheSports (talk) 18:24, 4 December 2025 (UTC)Reply
Oppose - It contradicts itself in a few places as pointed out above. Also explicitly states it should not be used in general and that is just wrong. It can be used, but it needs to be reviewed and verified, which is a huge difference. ~2025-38536-45 (talk) 19:43, 4 December 2025 (UTC)Reply
Support - this proposed guideline is still insufficiently strong, but it is a step in the right direction, and we should take it, even if we need to fix a wording here and there later, and even if we have to immediately hold a follow-up to try and strengthen it further. Tazerdadog (talk) 21:52, 4 December 2025 (UTC)Reply
Support – I have some qualms about the specifc wording, but this is a massive improvement. Thank you, Qcne. We should be listening to folks like him who have reviewed tens of thousands of AfC drafts, not nerds like me who spend too much time yapping on noticeboards like this one. Toadspike[Talk]22:02, 4 December 2025 (UTC)Reply
Support - the right approach, and we will certainly continue to tweak. FWIW, I think AGF is implicit and nothing here undermines it so shouldn't need to be spelled out. —Rutebega (talk) 22:22, 4 December 2025 (UTC)Reply
It shouldn't need to be spelled out, but experience has tells us that it absolutely does need to be. There are far too many editors who believe that a suspicion (correct or otherwise) of using AI is an automatic declaration of bad faith and thus they are free to respond in kind. Thryduulf (talk) 23:11, 4 December 2025 (UTC)Reply
Support I'd prefer stricter but, after a pretty thorough discussion this version satisfies most of the issues raised in the previous rfc, and no policy is ever going to be perfect. So let's not fall for the perfect solution fallacy and pass incrementally better versions instead of failing the imperfect. Also, Randy in Boise might actually realize he cannot simply paste what ChatGPT says about the Peloponnesian War. ~ Argenti Aertheri(Chat?)23:45, 4 December 2025 (UTC)Reply
Perfect is indeed the enemy of good, but I do not believe that something that is self-contradictory and has other issues (as noted above by multiple people) can be accurately described as "good" nor as "better" (incrementally or otherwise) than what preceded it (as that does not contradict itself). Thryduulf (talk) 00:47, 5 December 2025 (UTC)Reply
Oppose as insufficiently clear. This ambiguity will not permit good decision-making and will just cause issues - more time workshopping this proposed guideline would have been appreciated. Katzrockso (talk) 02:45, 5 December 2025 (UTC)Reply
Support as clearly better than the current guideline. We need to have a guideline that will clearly discourage the use of any unreviewed LLM created material in any article, not just in articles created from scratch as at present, and this draft does that. It may be that the guideline needs rephrasing in places (and in particular the first sentence of the "Do not use an LLM to add unreviewed content" section should be rephrased to make it clearer that only raw or lightly edited LLM content is being forbidden here), but we shouldn't let that stop us implementing this guideline as it is, since we can always improve it later. Dionysodorus (talk) 08:00, 5 December 2025 (UTC)Reply
Oppose. I share Thryduulf's concern that the do not use an LLM to add unreviewed content section is contradictory. The section itself only mentions not using LLM's to generate content it does not reference reviewed content or give examples of reviewed content that would be acceptable. GothicGolem29(Talk)14:20, 5 December 2025 (UTC)Reply
Oppose. This is poor guidance that prevents legitimate uses of LLMs:
Editors should not use an LLM to add content to Wikipedia, whether creating a new article or editing an existing one. Do not use an LLM as the primary author of a new article or a major expansion of an existing article, even if you plan to edit the output later.
Sure. As one example, someone might notice information is missing from an article, use AI to draft a paragraph with that information, comb through it to correct errors or policy/guideline violations (if any), and include it in the article with appropriate sourcing.
But this is a general-purpose technology - there are innumerable valid uses of AI, from research, to copyediting, to finding errors in articles. The important part is that any AI-generated content must be rigorously reviewed and corrected by a human editor. I would be glad to support a guideline emphasizing this. Anne drew (talk · contribs) 22:23, 5 December 2025 (UTC)Reply
Legitimate uses:
Human-reviewed article improvement suggestions
Human-reviewed ideas for new articles
Human-reviewed analysis of diffs and usernames for RCP patrolling
Oppose per Levivich, who seems to sum up the issues well. The word processor analogy is a good one - in the right hands, with due care an attention, an LLM can be a useful tool in helping to produce better-quality prose and basic sanity checking of what you've written. And clearly in the wrong hands, LLM use is very dangerous - it gives editors the ability to churn out lots of material if questionable accuracy. The current guideline has an advantage that it is very short and to the point, it's very easy to see what it prohibits. I would support an expansion of that to (equally succinctly) prohibit new unreviewed LLM content of any flavour rather than just "new articles from scratch", but I certainly wouldn't support a change that restricts legitimate LLM use more generally, or makes it more wordy and therefore harder to point new users at the hard rules about what they can and can't do. With thanks to the OP for wading into this difficult debate and attempting to make progress, I unfortunately do find the proposal too wordy (as well as potentially contradictory, as per Thryduilf) to be an a improvement for us. Cheers — Amakuru (talk) 17:41, 5 December 2025 (UTC)Reply
Support. I am unclear of proper protocol for this support message, as this is my first time supporting. I agree with pester and Kowal2701. Parameci (talk) 18:12, 5 December 2025 (UTC)Reply
Support. Good step in the right direction. There's definitely a faction of editors that want to continue allowing some LLM use. Forbidding "raw or lightly edited LLM output", while not explicitly forbidding "all" LLM use, is what this RFC does, and is in my opinion a good compromise. –Novem Linguae (talk) 23:31, 5 December 2025 (UTC)Reply
P.S. To address the issues raised above of "Editors should not use an LLM to add content to Wikipedia" (absolute prohibition) being out of sync with "Editors should not Paste raw or lightly edited LLM output" (prohibition of most LLM use), I'd be OK with deleting the sentences that give absolute prohibitions. Just delete that first paragraph of "Do not use an LLM to add unreviewed content" and leave the bullets. Worth it to get this passed. –Novem Linguae (talk) 23:37, 5 December 2025 (UTC)Reply
Oppose. This part is poorly written and stops all legitimate use of LLM in Wikipedia:
Editors should not use an LLM to add content to Wikipedia, whether creating a new article or editing an existing one.
That statement shuts off all legitimate use of LLM on the Wikipedia. This also contradicts the other statements made on the section, especially as the text after this statement implicitly allowed LLM that are are heavily-edited.
Do not use LLMs to write comments or replies in discussions
There's no legitimate reason for this guideline. LLM can be used to fix grammar, which is a legitimate use of LLM. We can also use LLM to rewrite or refine our thoughts, which is another legitimate use of LLM. And if one agrees with what the LLM is spouting up, who are we to judge them? A bad judgment didn't mean that the opinion had to be discarded. We humans made bad decisions and judgments as well, and it is wrong to have it discarded outright.
Where content is largely or entirely based on unedited or lightly edited LLM output, it may be draftified, stubified, nominated for deletion, collapsed, or removed entirely, especially where the content is unverifiable, fabricated, or otherwise non-compliant with existing Wikipedia policies.
I have to disagree on this. A content has to be actioned only if it is unverifiable, fabricated, or troubled. If an LLM content contains no problem, there is no reason to remove the content from Wikipedia. Wikipedia has enough guidelines to keep our content "clean". We should not care too much "how" the content is written; we should focus on "what" the content is. We should judge the quality of the content, not the methods of writing the content.
Repeatedly making problematic LLM-assisted edits may be treated as a competence issue and can result in the editor being blocked.
Same reason as above. Problematic LLM-assisted edits are the same as problematic human edits. There should be no difference at all.
I have to emphasize again that Wikipedia has enough guidelines to stop the excesses of LLM problems. There is no reason to add more rulings. Today we have seen the limits of LLM, but what will happen in 20 years ahead? Will Wikipedia expect the LLM to continue to be problematic? Today, our rulings are based on LLM throwing imaginary references, but what about in the next 5 years? ✠ SunDawn ✠Contact me!06:43, 6 December 2025 (UTC)Reply
Support Even if this guideline is not perfect, it's significantly more detailed than what we have now. For a topic as complicated as LLMs, I feel that a short guideline on their usage is insufficient as it doesn't explain LLMs, what specifically editors should not do with LLMs, or what editors should do upon seeing LLM generated content, all of which this proposal addressed. I don't think it's necessarily perfect, but what matters is that it is a step in the right direction of having a concrete stance on LLM usage, and is far more tenable to changes than the current wording. Gramix13 (talk) 15:57, 6 December 2025 (UTC)Reply
But the guideline contradicts itself. One part says "do not use LLMs to add content", and the other says "do not use LLMs to add unreviewed content" (implying reviewed content is okay). These two parts represent the two major viewpoints toward LLMs on Wikipedia, which makes sense for a guideline that is supposed to be a compromise, but putting them together makes no sense, because we're simultaneously saying "don't do it" and "you can do it if you thoroughly review it". SuperPianoMan9167 (talk) 17:17, 6 December 2025 (UTC)Reply
I really think this issue is a mountain out of a molehill. The section in question says editors should not use AI to add any content (which is advice, not prohibition) and only explicitly forbids using AI to create new articles from scratch. The section header fails to properly include the latter point, but it doesn't contradict it.
The section tells you;
You must not use AI to add unrestricted content
You shouldn't use AI to add any content at all, preferably
You must not use AI to create new articles wholesale
The bullet points add some confusion by using 'should' rather than 'must', but we can easily improve the clarity on that post-RfC. I think the point is the spirit of the guideline, which aims to prohibit generating whole articles with AI (in line with NEWLLM) and otherwise strongly discourage thw use of AI to add other content.
It'll be much easier to improve the clarity post-RFC than it would be to cancel the RFC, make a new draft, take it to RFCBEFORE, leave the RFCBEFORE up long enough to satisfy the people who are complaining about rushing, then bring it back to RFC and get consensus on it. So long as we can get consensus on the spirit of the guideline, the actual written clarity can be improved Athanelar (talk) 19:18, 6 December 2025 (UTC)Reply
There is no deadline. I'd prefer we resolve the contradiction before proceeding.
Guidelines are not rules that you can enforce against anyone who breaks them; they are guidelines, which are meant to guide editors.
Also, you read the word "should" in different ways depending on the specific guideline: in regards to NEWLLM, you read Large language models should not be used to generate new Wikipedia articles from scratch. as an absolute prohibition on generating articles with LLMs, yet here, you say that Editors should not use an LLM to add content to Wikipedia is not an absolute prohibition on all LLM content generation. "Should" is therefore ambiguous. The proposed guideline does not have the word "must" in it at all, so you're reading words into the guideline that aren't there. SuperPianoMan9167 (talk) 21:24, 6 December 2025 (UTC)Reply
I don't think the use of 'should' is ambiguous per se, I think it's contextual. In the context of NEWLLM (especially when taken with Cremastra's stance in these subsequent RFCs, as well as the sentiments of those who voted in support of that RfC) I think it's clear that the intent was and is to act as a prohibition. If it weren't for this RfC going on now, then I would be lobbying to get 'should' changed to 'must' there precisely to clarify that, and it was something discussed at the time.
I think 'should' is read as non-prohibitive here precisely because it stands next to and is contrasted with statements that read "Do not..." (which is, I argue, plainly synonymous with 'Editors must not X' which is why I used that language)
NEWLLM is one simple statement which uses the word 'should,' and that's why I read it as prohibitive despite that.
This is multiple statements, some which say 'should not' and some which say 'do not,' and I think that difference in language marks a difference in implementation. Athanelar (talk) 21:34, 6 December 2025 (UTC)Reply
Similar to what Levivich argued in this comment, NEWLLM has more nuance to it than you are suggesting, and it is notone simple statement. It is actually three statements, each one with consensus support:
Large language models can be useful tools. (True.)
But they are not good at creating entirely new Wikipedia articles. (Also true.)
Large language models should not be used to generate new Wikipedia articles from scratch. (The conclusion.)
The second sentence indicates that the reason we are banning unreviewed LLM-generated articles is because they're bad. The words "from scratch" are vague, but my understanding of them is that blindly copy-pasting LLM output into the edit window and pressing "save" is not allowed. This is a perfectly reasonable rule because competence is required. My understanding is that if an editor reviewed and fixed up an LLM-generated article so that it meets all policies and guidelines, the guideline would not apply. Even if the guideline is an absolute prohibition, editors are completely free to not follow it if they are experienced editors who properly review their LLM-generated articles. SuperPianoMan9167 (talk) 22:51, 6 December 2025 (UTC)Reply
@Athanelar, about take it to RFCBEFORE, leave the RFCBEFORE up long enough: Please go read WP:RFCBEFORE. RFCBEFORE is about how to not have an RFC at all. (You may be looking for the gentle suggestion in the last lines of WP:RFCBRIEF, which is about how to get help with wording an RFC.) WhatamIdoing (talk) 18:29, 15 December 2025 (UTC)Reply
Oppose Agree with Levivich that the days spent critiquing other proposals do not justify having less than a day of WP:RFCBEFORE discussion on this proposal's final wording, especially when more review should have addressed the inconsistency highlighted by Thryduulf. Substantively, I agree with WhatamIdoing that whereas WP:NEWLLM was guided by AFC/NPP experience to focus on new AI-written articles, this proposal is prohibiting a far wider set of uses without demonstrating that those uses are similarly draining on editor time or corrosive to our content. ViridianPenguin🐧 (💬) 18:54, 6 December 2025 (UTC)Reply
Neutral, but positive: I know this process has been a long slog, so it may be time to say this is a 'good enough' draft to replace what exists, with the understanding that a new draft is needed. Some issues I want addressed: I think "unreviewed content" is trending in the right direction but we can be more specific about the problem: Editors should not add content they have not read and understood, and large revisions incorporating a lot of changes are difficult to review compared to small revisions. Generally, I think that Wikipedia's consensus process has been pretty robust in the face of vandalism and poor quality edits - conceptually, that's basically what bad AI editing is. I also agree with Thryduulf's observation about inconsistency. --Edwin Herdman (talk) 21:06, 6 December 2025 (UTC)Reply
Support in spirit. I agree with editors that the final WP:RFCBEFORE should have been left open for longer. I agree with the prohibition on unreviewed content, but as others have pointed out, the current wording is self-contradictory. Again, I see no reason why we should be prohibiting the addition of policy-compliant content, although I wouldn't necessarily be against restricting it to, say, extended-confirmed editors in order to ensure that they are actually aware of the relevant policies and guidelines that the generated content is supposed to comply with.I think the closer should consider a partial consensus for this RfC, as I think most editors here support forbidding unreviewed LLM-generated content, but they don't support the much broader prohibition on LLM output. Kovcszaln6 (talk) 11:29, 7 December 2025 (UTC)Reply
I very strongly oppose adopting anything (regardless of subject matter) as a guideline that differs from the words that people were explicitly commenting in the discussion, because even with absolutely impeccable faith there is a very strong risk of unintentionally introducing significant problems or misrepresentation of views.
In this specific case, Wikipedia talk:Large language model policy#RFC found no consensus to adopt "Large language model output, if used on Wikipedia, must be manually checked for accuracy (including references it generates), and its use (including which model) must be disclosed by the editor; text added in violation of this policy may be summarily removed." as a "policy/guideline" and that should not be overturned in a discussion that does not specifically discuss that. FWIW I'd be inclined to support a policy or guideline specifically and only prohibiting the addition of AI content to Wikipedia without human review (although specific wording, e.g. around what counts as a sufficient human review, would be of the utmost importance), but that is not what is proposed in this discussion. Thryduulf (talk) 14:04, 7 December 2025 (UTC)Reply
After just now reading through yet another AI-generated unblock request which says that policies say things they absolutely don't say in reality, I am affirmed in my position that I think it's better if our net accidentally catches too much AI usage rather than too little. I of course recognise that this is an ideological position that you absolutely won't agree with; but every incidence like this only strengthens my belief that we need stronger, unequivocal restrictions on problematic AI usage, yesterday. Athanelar (talk) 18:21, 7 December 2025 (UTC)Reply
It is far more important that we get any restrictions right than we get the quickly. Poorly worded restrictions that are confusing, misleading, contradictory, redundant (e.g. a significant proportion of the problematic edits highlighted in discussions like these already fall foul of existing policies and guidelines), too broad or too narrow help nobody but have a high likelihood of making existing problems worse or creating problems where none currently exist. Thryduulf (talk) 20:53, 7 December 2025 (UTC)Reply
Oppose. I find it hard to interpret as written. LLM output can be unreviewed, reviewed but not significantly edited, or reviewed and edited. The guidelines mixes all three, such that it's not very clear what exactly is forbidden. I can also see why previous comments find it somewhat contradictory. This proposal is directionally correct, but I'd rather support an edited and respun version of this RFC. That seems like a safer bet if the goal is to make it easier to make decisions about LLM (ab)use, and less risk of being stuck with a ambiguous guidelines. Mlkj (talk) 22:48, 7 December 2025 (UTC)Reply
My Oppose or Support depends on whether the all-encompassing sentence Editors should not use an LLM to add content to Wikipedia, whether creating a new article or editing an existing one stays or not; in the latter case, I support the proposal. However, I think it would be useful to have a Help page with LLM do's and don'ts, instructing editors on a helpful use of LLM, as Levivich suggested. Gitz (talk) (contribs) 10:03, 8 December 2025 (UTC)Reply
When I try such experiments, I often like to post the output for transparency and to share the results. Flat prohibitions on the posting of AI generated text is not helpful in such cases.
This is something that I hadn't thought of before, but posting both unreviewed and reviewed output in the same comment (and I guess this might be relevant too in an article related to LLMs/generative AI) for the purposes of comparison should be an obvious exception to any prohibition on contributing unreviewed output. Thryduulf (talk) 13:46, 8 December 2025 (UTC)Reply
I'd say that sort of thing falls under a common sense exception anyway, no? Even if a total restriction on unreviewed LLM content does manage to pass, I think any sensible editor would understand that an excerpt of unreviewed LLM text posted in a discussion context for demonstrative purposes doesn't count; any more than quoting a sourced insult made about someone in a BLP is a BLP violation. Athanelar (talk) 13:51, 8 December 2025 (UTC)Reply
@Athanelar (sorry, it looks like I should have edit conflicted with you when I posted by comment below but I didn't and I've only just spotted your reply) I agree it's the sort of thing that should fall under a common sense exception, but given the volume of comments in discussions about AI that explicitly or implicitly state there should be no exceptions whatsoever and (in some cases) a lack of belief that common sense exceptions can even theoretically exist when it comes to AI, I'm not convinced that it doesn't need to be explicitly stated. Thryduulf (talk) 16:31, 8 December 2025 (UTC)Reply
Actually there are a couple of other exceptions too -
Posting the unreviewed output from various LLMs given the same prompt as a comparison between them
When the unreviewed output is itself notable, or part of a work that it is notable because it contains such
When quoting a reliable source (e.g. if it is encyclopaedic and due to quote the reaction of $official to $event (which is less often than such quotes are often used), then that official's quote being unreviewed LLM-output should not be a barrier to inclusion).
Given how stringently and literally some editors (wish to) interpret LLM-related guidelines, it is probably necessary to explicitly list these exceptions somewhere. Thryduulf (talk) 13:54, 8 December 2025 (UTC)Reply
Support per Tazerdadog and Toadspike, definitely a step in the right direction; the process will continue and we will refine this guideline. I do not quite get most of the oppose arguments. Invoking "there is no deadline" (a valid concept about encyclopedic content) for a guideline is unconvincing, while arguing that there has not been enough discussion guarantees that we will never move forward given how fraught this topic is. We should be thankful to the people who deal with the clean-up and help instead of losing sleep over technicalities in wording that can be refined as needed. The infinitesimal minority of editors who know how to use an LLM constructively (spot-checking, summarizing, rephrasing, etc.) are never going to paste any kind of output into articles since it will only inform their edits instead of being part of their substance, which is what we are trying to avoid. Let's keep our eyes on the prize here. Choucas0 🐦⬛⋅📬⋅📜14:34, 8 December 2025 (UTC)Reply
I personally do not see this as a direct contradiction, and while it could be clearer it is far from a blocking issue in my book. This guideline is not perfect yet (none is or can be) but what matters to me is that its practical implications are helpful in the short term and that it is a stepping stone in the right direction. Choucas0 🐦⬛⋅📬⋅📜14:48, 8 December 2025 (UTC)Reply
@SuperPianoMan9167 responding to every supporting !vote with this argument is bludgeoning. You've made the argument plenty of times here already, please trust that the people !voting in support have already thoroughly read the thread and haven't been compelled by this point. Athanelar (talk) 15:08, 8 December 2025 (UTC)Reply
Oppose: The proposal seems like a half-baked draft. First, there is no lead text. Second, "This includes tools marketed as "AI chatbots" or "AI writing assistants", such as...". Even if a guideline is in itself not an article, this goes against the guideline on expressions of doubt. Those softwares are not "marketed as" chatbots or writing assistants, they are (besides, "AI chatbot" is a tautology, there are no non-AI chatbots). Third, "Editors should not paste raw or lightly edited LLM output as a new article or as a draft intended to become an article". Another tautology: with some very limited exceptions (drafts intended to be something else instead of articles, such as the one being discussed here), all drafts are "intended to become an article", or they would have to go to miscellany for deletion. Meaning, AI is not allowed even in drafts. Which is a questionable proposal (and also forgets that Drafts are not checked for notability or sanity), but later says "Where content is largely or entirely based on unedited or lightly edited LLM output, it may be draftified". If the proposal is actually that AI content is allowed on drafts, with the caveat that it has to be reviewed or improved before going live, then it has to be rewritten for clarity. If "a draft intended to become an article" means a draft in Wikipedia:Articles for creation that has been submitted for review but isn't approved yet, be specific (and don't forget that "pasting raw or lightly edited LLM output" in a draft would be step 1 before starting to edit and review it, so don't drop it among all the other copypasted prohibitions). Fourth, "...especially where the content is unverifiable, fabricated, or otherwise non-compliant with existing Wikipedia policies. So, that means that AI generated text may be removed even if verifiable, non-fabricated and compliant with existing Wikipedia policies? Fifth, "Tag the page as LLM generated under Template:AI-generated.", links to the template directly instead of using TL for easier copypasting. And then there's the missing content: describe the acceptable uses. Some people propose that users should disclose the use of AI, but if the guideline is all "don't"s and no "do"s, the inevitable outcome would be that all such edits would be deleted or removed by users with a strong anti-AI sentiment, and then nobody would disclose anything (and with no reliable AI-detecting tools, that's probably not the thing you would want). By the way, the idea of promoting a guideline against AI got the better of several users, and supported it without noticing the small detail that the proposal was just a useless stub. This proposal is very little better, and it wouldn't pass AFC if it was an article. Many say "let's promote it anyway, we'll fix it later". No: now is that "later". Policies and guidelines are not articles, and the wiki process does not work the same: big changes require consensus, and more so if the page has to be rewritten from the ground up. We are having this RFC because of the short-sight of approving a useless stub guideline, and if we promote this mess we'll have yet another one in a couple of weeks to fix this one as well. Cambalachero (talk) 15:34, 9 December 2025 (UTC)Reply
Err, this is literally a quickly thrown together [guideline] to "fix" issues that isn't even clear about any of what it's trying to fix, why it's trying to fix it, or how it will fix it. Thryduulf (talk) 23:13, 9 December 2025 (UTC)Reply
We kind of need these "bludgeoning" comments when people make confusing or incorrect statements (though all of us have had the experience of posting a comment in the wrong tab or mixing up which page we're talking about – you were probably thinking of WP:AISIGNS, which is almost exactly two years old now).
Levivich gave us the dates for the new guideline, but if you're opposed to "some quickly thrown together policy to "fix" issues", then I'll point out that what you've voted to "support" was just 10 days old when this RFC started (started on the same day the new guideline was promoted), and the OP made major changes to it just half a day before starting this RFC. The resulting lack of in-depth pre-proposal review means there are still some significant weaknesses, and this is one of the reasons some editors have voted to oppose its adoption for now. I'm personally skeptical that what we need is a long guideline (I think a big box at the top of the editing window that says the equivalent of "No chatbots! 🤮" would be more useful), but if we're going to have a long guideline, we need to polish it up a bit before making a new WP:PROPOSAL. WhatamIdoing (talk) 18:55, 11 December 2025 (UTC)Reply
Support But go further. All use of LLM's to add or change texts should be disclosed in the edit summary. Not following this rule should result in an immediate indef which can only be lifted after aknowledging LLM use, promising to not use LLM's again and promising to clean up all previous use (no other edits befor this is done). Merely using a LLM as a search engine to find sources is fine and shouldn't be disclosed. There should be a banner warning editors before an edit is published. Rolluik (talk) 12:37, 10 December 2025 (UTC)Reply
I couldn't support that - one incorrect accusation of undisclosed LLM use (whether in good or bad faith) would mean either an unappealable indefinite block for doing nothing wrong or forcing people to lie in order to be unblocked. Neither of which are even on the same planet as things that are good for Wikipedia. Thryduulf (talk) 13:59, 10 December 2025 (UTC)Reply
If I was repeating the same comments in response to the same opinions being expressed, then yes it might be. This comment however was definitely not. It was a response to something that was different (qualitatively and in degree) to anything brought up previously, and my comment was focused entirely on that new argument. Thryduulf (talk) 17:11, 10 December 2025 (UTC)Reply
Bludgeoning isn't just repeating oneself, it's also taking up space in/dominating a discussion and pushing back on every comment one disagrees with Kowal2701 (talk) 17:54, 10 December 2025 (UTC)Reply
I think Thryduulf is fine here; as they've said, they're being selective about who they respond to and how, not pushing the same counterpoint again and again. Athanelar (talk) 17:28, 10 December 2025 (UTC)Reply
Support. It's an improvement over what we have now. The Do not use an LLM to add unreviewed content section seems perfectly clear to me in prohibiting raw or lightly edited LLM output but in any case this expanded version will be easier to refine going further. The fact is that most of our efforts at policies surrounding LLMs have stalled because people have demanded perfection or dragged their heels on anything that doesn't completely encompass everything they want; in particular I think it's extremely unlikely that we would reach a clear consensus on unambiguously allowed usages (there are too many people who want it banned in all cases for a consensus to form explicitly allowing any use, while not being enough to actually ban it in all cases; this is what has stalled out all previous discussions. And if you feel you can get a consensus to add specific allowed use-cases, it can always be done in a separate RFC - there's no need to try and do everything at once, that's another reason why previous efforts to make this policy fell apart.) Refining and narrowing the allowed usages over time until we hit points where we can't reach a consensus to narrow them further is the easiest way to work around these problems. And in this context the "contradictions" people complain about are a good thing - any ambiguities will be resolved over time as the guideline enters use and practice evolves, with resolutions to them eventually making their way to the page itself. We had our chance to get an exhaustive from-above LLM policy in the past and it fell apart after months of discussion (partially, to be extremely blunt, due to disagreements between people opposing here.) So this is what we get. Is it perfect? No. But it's workable and is an incremential improvement over what we have, which itself was an improvement over having nothing. This is how building policies for controversial aspects of the wiki work. --Aquillion (talk) 14:25, 11 December 2025 (UTC)Reply
Support - the proposed version is compact, gets straight to the point, and is a solid first-stage expansion compared to the one-sentence old version. The concern (expressed several times above) of self-contradiction is incorrect: Do not use large language models (LLMs) ... add unreviewed content to existing articles is not strictly complete, since taken alone, it allows for adding "reviewed" content, i.e. it literally allows for adding "lightly reviewed" content. However, the content of the guideline clarifies that Editors should not: ... Paste raw or lightly edited LLM output .... Any human fluent in English who reads this will understand the implication that heavily edited LLM output can, in principle, be accepted (and that it's up to the editor to do the heavy, thorough editing of the LLM output). There is no contradiction. An "in a nutshell" summary can acceptably be incomplete (which is the case here); that does not make it contradictory with the body of the article; it is not intended as a complete, nuanced summary. It's a TL;DR. It gets to the essence of the guideline. These are instructions for humans, not for semantic engines, and not for LLMs either. Boud (talk) 00:52, 12 December 2025 (UTC)Reply
Any human fluent in English who reads this will understand the implication that heavily edited LLM output can, in principle, be accepted (and that it's up to the editor to do the heavy, thorough editing of the LLM output). multiple humans fluent in English have explained that this is not the case. Thryduulf (talk) 05:28, 12 December 2025 (UTC)Reply
What is the difference between "heavily edited" and "lightly edited"? How much edited is enough edited? How do we know how whether editing was heavy or light? And I don't just mean how do I know whether someone else heavily or lightly edited, I mean how do I know whether I heavily or lightly edited? So not just how do I monitor others' compliance with this guideline, but how do I monitor my own compliance? I think the answer is "you don't know, it's impossible to measure with such vague standards," which is why this proposed guideline shouldn't be adopted. Levivich (talk) 05:45, 12 December 2025 (UTC)Reply
Well, no, I think the answer is always going to be 'you'll know it when you see it' because depending on the model used, volume of text generated etc the amount of review necessary is always going to vary. That's why I'm of the mind that ultimately our prohibition shouldn't be based on human review at all, since it seems to me the only sensible threshold for "well reviewed" is "indistinguishable from non-LLM text anyway" Athanelar (talk) 10:30, 12 December 2025 (UTC)Reply
Weak support. Needs more time to bake, we need to actually agree on what to put in such a policy to actually have a consensus other than oppose too weak and oppose too strong arguments ~2025-31733-18 (talk) 19:25, 13 December 2025 (UTC)Reply
This is to modify an existing guideline, not create a new policy. Because it already exists, this would be exactly the place to talk about if the text is to strong or weak, since it is modifying an existing. ~2025-38536-45 (talk) 17:26, 15 December 2025 (UTC)Reply
This is an RFC, which comes after the workshopping stage. That there was insufficient workshopping of this proposal prior to the RFC does not mean this is a workshop. Thryduulf (talk) 19:43, 16 December 2025 (UTC)Reply
If it quacks like a duck, it is a duck. So no, this is also part of the overall workshopping. Just less official, but none the less, the same purpose. Unless you want to argue semantics I guess? That feels like a waste of time though. ~2025-38536-45 (talk) 21:03, 17 December 2025 (UTC)Reply
The point of an RFC is to establish consensus on a specific thing, to that end changes to the wording of that thing are generally strongly discouraged because they are almost always unhelpful (because it is unclear what someone is actually supporting or opposing). This is in complete contrast to a workshop where there are frequent, often iterative, changes to whatever is under discussion and no attempt to solicit support or opposition to adopting the proposal (and indeed bolded "support"/"oppose" etc. comments are frequently called out as incorrect and/or unhelpful). The two processes look nothing alike, and this is both explicitly and by all appearances an RFC not a workshop. Thryduulf (talk) 21:21, 17 December 2025 (UTC)Reply
Oppose I think its the right direction but missing a few steps. For example, there are good uses of LLM when you have actually already crafted text but want the LLM to make it more concise (that is, you're not asking for it to create information but rephrase it), or using LLM to actually do initial searching. As long as the editor using the LLM is taking responsibility for any problems it creates (including hallucinations or non-encyclopedic tone or whatever) and corrects them if present, that should not be considered harmful. Masem (t) 00:55, 14 December 2025 (UTC)Reply
Support, it's a great improvement on the existing guideline, which covers only new articles; however, inserting text into existing articles is at least as much of an issue. Things can be tweaked later if needed, but we can't let every quibble hold us back from having a strong guideline on adding AI-generated text to existing articles. Crossroads-talk-22:24, 15 December 2025 (UTC)Reply
Why do you regard the multiple, fundamental objections to this guideline from multiple independent good-faith editors as "quibbles"? What makes a guideline that many read as self-contradictory "strong"? I'm not trying to bludgeon here, I'm genuinely trying to understand your viewpoint. Thryduulf (talk) 23:51, 15 December 2025 (UTC)Reply
The fundamental issue is that we need a policy addressing people credulously plopping unedited or barely edited AI output into existing articles. Right now LLMs have been around for years and there is still no policy/guideline squarely forbidding that. Any subsidiary aspects can be discussed and adjusted later, but statements like Editors should not:...Paste raw or lightly edited LLM output into existing articles as new or expanded prose are sorely needed. Crossroads-talk-22:29, 16 December 2025 (UTC)Reply
Please see the Politician's syllogism - just because (you believe) something should be done does not mean that this is the correct something. If you think it is the correct something, you should address the issues with this specific proposal brought up by those in opposition. Many (perhaps most) of those opposing agree with your aim, (almost?) everyone agrees that the aim of this proposal matches that aim, however there is significant disagreement that this will achieve that aim and/or that it will not cause more problems than it solves. Almost none (but not quite all) of the support, including your two comments, does not address those issues. Thryduulf (talk) 01:52, 17 December 2025 (UTC)Reply
Support — While I have some minor quibbles over the wording and I'd still prefer a blanket ban on LLM use, this is a good second step towards codifying best practices at dealing with LLM slop. —pythoncoder (talk | contribs)02:19, 16 December 2025 (UTC)Reply
Support per fifteen thousand two hundred twenty four – If the editors doing a great service to this project by devoting themselves to the cleanup of AI slop think that this is a good change, we ought support it. Anything to give them more tools to tackle what is an existential threat to the project. Yours, &c.RGloucester — ☎20:23, 16 December 2025 (UTC)Reply
Support; I don't see anything substantial to disagree with here. I agree it is challenging to police and to prove LLM use in many cases, but there is still value in a clear statement of principle saying we don't want it - cf our policies on conflicts of interest, etc. I doubt this will be the final policy we have but it is a decent next step. Yes, it is imperfect, but the issues with it do not seem fatal to me, and something like this has been needed for a long time now. Andrew Gray (talk) 04:49, 17 December 2025 (UTC)Reply
The issues is that many people disagree that hit is a clear statement and that statements of principle and guidelines are interchangeable. Thryduulf (talk) 14:48, 17 December 2025 (UTC)Reply
Thryduulf, not every !vote needs your opinion. Seeing an admin argue with every third to forth vote is incredibly discouraging to newer editors who disagree with you, please chill. ~ Argenti Aertheri(Chat?)23:04, 17 December 2025 (UTC)Reply
I was going to say the same thing, but I was getting toasted by autoblock at the time.
The issues is that many people disagree that hit is a clear statement and that statements of principle and guidelines are interchangeable and clearly Andrew Gray does not share this opinion. This has passed WP:BLUDGEONING for which you have been warned repeatedly on this thread. It's really not fitting for an administrator to have to be reminded of conduct rules by multiple non-admins. Cremastra (talk·contribs) 01:08, 18 December 2025 (UTC)Reply
not every !vote needs your opinion. which is why I'm not giving my opinion on every vote, just some of the ones that appear not to have taken any note of the prior discussion and/or seem not to have engaged with the fact this is a proposed guideline (i.e. intended to provide guidance) not a proposed general statement of principal or philosophy. The number of accusations of bludgeoning is irrelevant to whether someone actually is bludgeoning, and you'll note that the previous accusations have all been disagreed with by those who understand what it actually is. Thryduulf (talk) 03:19, 18 December 2025 (UTC)Reply
By my count at the time of the above comments you'd participated in the replies of 11 out of 28 opposes. It's true that a 39% is a long way from every oppose, but it's still a high amount. If you find yourself needing to preemptively clarify a comment with a statement like I'm not trying to bludgeon here, it may be worth stepping back and letting the discussion breathe. fifteen thousand two hundred twenty four (talk) 04:15, 18 December 2025 (UTC)Reply
It's not just that, count the number of support votes with replies from anyone except Thryduulf. Since SuperPianoMan chilled virtually every support vote that was commented on was initially commented on by Thryduulf and, generally, no one else. So no, it's not every !vote, but any support vote that has been challenged has been challenged by the same admin. Idk if it's capital B bludgeoning, but please stop dominating a discussion that isn't about you. ~ Argenti Aertheri(Chat?)05:30, 18 December 2025 (UTC)Reply
Can we all just slow down and try to discuss what the essential components of a comprehensive LLM guideline should be before !voting on one? NEWLLM passed less than two weeks ago. SuperPianoMan9167 (talk) 23:37, 4 December 2025 (UTC)Reply
In that case we should modify the existing guideline instead of throwing it out entirely. This proposal aims to restrict more LLM use than NEWLLM does, because it says Editors should not use an LLM to add content to Wikipedia, whether creating a new article or editing an existing one. with no qualifier. SuperPianoMan9167 (talk) 22:58, 6 December 2025 (UTC)Reply
Yes, this proposal is pretty much deleting everything under the {{guideline}} tag and replacing it with something else. @Rutebega, the key word in my comment was expanding. This proposal isn't just a clarification of the wording. It's a dramatic expansion from "don't copy/paste whole articles straight out of your chatbot" to "here are a bunch of new rules for a large variety of situations". WhatamIdoing (talk) 04:13, 8 December 2025 (UTC)Reply
I had been following that talk page, saw there was a new draft but didn't have enough time to fully form any thoughts before I saw a message that there was a RfC here.
What Thryduulf and Katzrockso said - I have a day job, you know, and can't be counted on to log in to Wikipedia every week, much less digest thousands of bytes of text from a variety of viewpoints and formulate a well-considered, clearly-articulated response. Plus I have to dedicate at least some of my Wiki-time to content-space contributions or I will lose my mind and quit the project forever. I think these AI conversations are really important and fairly urgent, but on a timescale of weeks or months, not days. -- LWGtalk21:50, 5 December 2025 (UTC)Reply
A little comment to people who like to point out 'copyediting' as an acceptable use of AI that we should explicitly permit; I've been working on cleaning up a chronic LLM-misuser's contributions as tracked here, and I would really strongly encourage you all to go and take a look at some of those diffs. The most egregious ones are cases where the AI copyediting accidentally crams together two sentence clauses in a way that changes the meaning of a sentence, or needlessly thesaurusifies a direct quote from a real person, but even if you look at the diffs that I haven't bothered to revert (marked in red,) you'll see so many cases of entire paragraphs being needlessly thesaurusified into nausea-inducing pompous purple prose by this user whose modus operandi appears to be telling an LLM to 'translate' article text into 'encyclopedic language.' I simply don't have the patience to go in and manually reword every little sentence which has been needlessly puffed up by this process, and that's exactly the kind of 'death by a thousand cuts' that us in the anti-AI camp are trying to avoid. Athanelar (talk) 19:19, 10 December 2025 (UTC)Reply
I can show you many, many examples of serious mistakes made by editors without using LLMs. Should we ban all human-written content because humans have a high error rate? You talk about not having time or patience to fix it all... I spent five years, 40k edits, fixing human editors' mistakes on this website. Still, I don't favor banning humans from the website. Levivich (talk) 19:24, 10 December 2025 (UTC)Reply
At least in human-written text, the amount of effort to create it is larger than or equal to the amount of effort needed to fix/remove it. As commented somewhere above, LLM use flips that balance on its head, where users can use external tools to create large amounts of poor text that are difficult to manually fix. Cremastra (talk·contribs) 19:26, 10 December 2025 (UTC)Reply
That's not true at all. It's much easier for a human to add incorrect, non-policy-compliant content than it is to fix that content. LLMs do make it easier, that's true, and that's their danger. But they also make it easier to add policy-compliant content, and that's their advantage. It's just like a word processor, or a typewriter, in that sense: it makes it easier to write, faster to write... both writing good stuff and writing bad stuff. Levivich (talk) 19:28, 10 December 2025 (UTC)Reply
Describing generative AI as just another tool that makes writing easier, like a word processor, is an optimistic inaccuracy because it, not the human, is the one doing the writing. It is no longer the human writing with the process sped up, as in a typewriter or word processor: it is a human either telling a machine what to write or writing with machine-suggested changes and rephrasings.
Saying LLMs are just another writing tool is a bit like saying a car is just a better shoe. More complicated shoes may allow one to walk faster, or get better grip, but it is still a human process. A car is a complex machine only guided by a human. But LLMs are even worse, because they can generate content with only the vaguest human instructions: you still need to steer a car (at least, for now). Cremastra (talk·contribs) 19:34, 10 December 2025 (UTC)Reply
It is the human doing the writing if the human being checks the LLM's output, which they should do. I mean, that's the difference between using an LLM as part of a writing process, and just copying and pasting what the LLM outputs. Nobody should be coping and pasting LLM output without checking it first, and probably without making some edits to it. If the LLM output is checked by a human, then it becomes human output, or at least hybrid output, not entirely machine output. (The ironic thing about cars is that self-driving cars are actually safer than cars driven by humans. We may get there with LLMs someday, too. Or maybe not.) Levivich (talk) 19:42, 10 December 2025 (UTC)Reply
I mean, we're getting a little outside the scope of the point of my original comment now, but I will say to that what's already been said above - the pitfall in requiring 'human review' is that there's essentially no way to prove it has or hasn't been done unless the person leaves in the most obvious signs of unreviewed output like human-directed communication, UTM footprints etc; but in cases like this with problematic and unnecessary copyediting, if there were a hypothetical guideline forbidding all AI-generated additions without suitable review, this user could simply come forward and say "well, I reviewed it and thought it was fine" and we'd have no recourse against that.
My whole argument with my original comment is that these edits very much could be "human-reviewed copyediting"; i.e., literally the poster child for acceptable AI-generated content as held up by the pro-AI (or, less anti-AI, I suppose) camp in this discussion; and they're still generally unproductive and unnecessary in the best case. Athanelar (talk) 19:46, 10 December 2025 (UTC)Reply
There's lots of types of edits on Wikipedia that other editors perform that some editors believe are "problematic and unnecessary", is that grounds to ban them or all humans from contributing to Wikipedia?
The point here is that AI-assisted editing is not some unique class of editing that is all-good or all-bad, but that these edits vary in their quality just like any other type of editing: solely humanly generated edits (a concept becoming more dubious over time as technology is increasingly embedded in digital interfaces), edits assisted by grammar checkers and other writing software, edits assisted or produced by bots, etc. Katzrockso (talk) 21:19, 10 December 2025 (UTC)Reply
The point is that AI-assisted editing pretty much is all bad, unless it's painstakingly reviewed and copyedited with a degree of scrutiny and editing that makes it essentially no more convenient than just writing it yourself.
If there were any other tool that pretty much universally resulted in worsening the encyclopedia in a way that required intense, focused, organised human effort by an entire wikiproject to fix, was completely useless for big tasks like article creation while in the best case saving marginal amounts of man-hours doing minor tasks like copyediting, we'd restrict its use as much as we can without a second thought. But because AI is 'the future' or whatever and has infested peoples' daily workflow so much, we're forced to bend over backwards trying to find a way to reconcile it with Wikipedia when it's so obviously observably contrary to what we do here. Athanelar (talk) 21:33, 10 December 2025 (UTC)Reply
The point is that AI-assisted editing pretty much is all bad, unless it's painstakingly reviewed and copyedited with a degree of scrutiny and editing that makes it essentially no more convenient than just writing it yourself. Many editors here disagree with this unevidenced claim, which is the crux of the dispute. Katzrockso (talk) 21:35, 10 December 2025 (UTC)Reply
Well, I've seen absolutely no evidence to the contrary, but WP:AINB has ample evidence to the affirmative. That's what my whole top level comment here is showing; that even minor, selective, seemingly human-reviewed copyediting, the poster child for ideal LLM usage, is turning out bad results. Athanelar (talk) 21:39, 10 December 2025 (UTC)Reply
That much is true, yes, but I also haven't seen anybody give any convincing examples of how it can be used well except for some handwaving towards the possibility. The one exception is the editor whose name doesn't come to mind who has been making very thorough articles using LLMs, but I know that that editor uses a custom LLM that they trained themselves and which they review the output of extensively, so they can't exactly be taken as a type specimen. Spiders georg and so on. I understand that negative examples will naturally end up on noticeboards, but I just don't see any convincing positive examples presented anywhere else; which you'd think the pro-LLM crowd should be quite interested in producing.
SuperPianoMan linked the LLM demonstrations subsection above, but the most convincing examples there are examples of using it to 'suggest' edits to then be made by a human, rather than actually producing any wikivoice text in itself.
My contention is that LLMs are, when used by a typical user, essentially useless at producing any text in wikivoice which actually improves the encyclopedia. All of the 'ways to use LLMs well' focus on circumventing this limitation, which is a red flag for me. I wouldn't use a calculator which spat out nonsense if you used the multiplication button so instead you had to just use addition to approximate multiplication; or at the very least, I certainly wouldn't use it for multiplication.
Though, to be transparent, even if such evidence (of LLMs being any good at article text) did exist, I'd still be opposed on principle, but that's a separate matter. Athanelar (talk) 22:21, 10 December 2025 (UTC)Reply
All of the 'ways to use LLMs well' focus on circumventing this limitation That's the point. The "ways to use LLMs well" are the ones that overcome their limitations. SuperPianoMan9167 (talk) 22:39, 10 December 2025 (UTC)Reply
Though, to be transparent, even if such evidence (of LLMs being any good at article text) did exist, I'd still be opposed on principle, but that's a separate matter. Which is precisely why producing such evidence (which does exist, by the way!) is not productive here. Katzrockso (talk) 23:13, 10 December 2025 (UTC)Reply
I mean, it would still be productive (a debate is as much about convincing the audience as it is about convincing your interlocutor) I just wanted to be frank about the fact that nobody's goal should be to convince me specifically, since I will not be convinced. Athanelar (talk) 23:18, 10 December 2025 (UTC)Reply
I think this is case-in-point for the discussion, inoculation from evidence is not a productive attitude towards discussion here.
It's not about 'inoculation from evidence,' I'm willing to accept that I'm wrong if it can be proven that LLMs can be coerced into producing half-decent wikivoice, I just think that the fundamental reason for an LLM prohibition should not be that they are 'ineffective' but rather that they are philosophically and morally anathema to Wikipedia and to any meaningful creative pursuit in general. I just focus on the more practical criticisms here because I think that's more likely to gather support and get changes implemented. So, if I am wrong that LLMs are useless at producing wikivoice without enough human review to render the effort-saving negligiblw, I still think we should crack down on LLMs, just for other reasons.
As for Shit flow diagram it was, I presume, extensively human reviewed; and still has criticisms of its wikivoice on the talk page, so my criticism that it requires equivalent human effort to verify AI wikivoice (and to clean up when it goes wrong) as it would to just make it the old fashioned way still stands. Athanelar (talk) 04:26, 11 December 2025 (UTC)Reply
The criticisms were agreed to have been flawed. When you search through any text, including those written by a human, to search for flaws, you typically will find some. That the text there had at worst one stylistic choice that was remedied is strong evidence that LLMs can be used to produce text in a policy compliant manner. Katzrockso (talk) 07:06, 11 December 2025 (UTC)Reply
If humans were able to produce perfect text with zero errors on the first review, GA and FA would be very significantly quicker and easier processes. It is unreasonable to hold reviews of human text and reviews of LLM text to different standards. Thryduulf (talk) 12:17, 11 December 2025 (UTC)Reply
I think it's because editors are focused too much on the tool that is used (LLMs), and not enough on teaching the people using the tool how to use it correctly (and banning the ones that don't seem to have the competence to use it). Levivich (talk) 19:26, 10 December 2025 (UTC)Reply
The onus shouldn't be on us to teach them to use it correctly any more than we should have to teach people to use their keyboard or to make appropriate reversions with Twinkle. Competence is required, and if you decide to charge in like a bull in a china shop and make huge amounts of disruptive edits with a tool you don't know how to use, we shouldn't treat it any differently than we would treat people mass-misusing twinkle or AWB or what have you without doing their due diligence. Athanelar (talk) 19:34, 10 December 2025 (UTC)Reply
Surely you're kidding? We do, in fact, teach people how to type on Wikipedia. We have all sorts of instructional pages about how to write on Wikipedia, how to format, how to use Wikitext, etc. etc. But I agree with you that people should be held accountable for what they publish on the website irrespective of what tools they use to publish, whether it's Twinkle, AWB, just a keyboard, or a chatbot. Levivich (talk) 19:39, 10 December 2025 (UTC)Reply
Well, no, we should at best expect them to educate themselves on how to do that, in the same way that as soon as you click the box to enable Twinkle you're agreeing that you know what you're doing and will use it responsibly.
If someone then went on to make a bunch of problematic mass reversions using Twinkle while ignoring numerous warnings about it, we wouldn't sit them down and give them a crash-course on how to use Twinkle, we'd block them for disruptive editing. Athanelar (talk) 19:50, 10 December 2025 (UTC)Reply
If I see a user systemically not following a guideline, I'll tell them about the guideline on their talk page; no harm done. If they ignore my message and continue egregious violations of the guideline, then a short block would be justified, not to "punish" them, but to get their attention and stop the immediate problem so we can, metaphorically, sit down and explain what's wrong. I often see new editors rush ahead and make huge batches of changes that are suboptimal: often they'll listen, but sometimes you need to grab them by the shoulder and tell them what's up. Cremastra (talk·contribs) 20:01, 10 December 2025 (UTC)Reply
a short block would be justified, not to "punish" them, but to get their attention and stop the immediate problem so we can, metaphorically, sit down and explain what's wrong Then why are editors getting indeffed for LLM misuse right after being brought to ANI? I know what you'll say, "indefinite is not infinite", but indefinite is effectively infinite for most newcomers, as most newbies that get indeffed will likely give up and quit Wikipedia entirely (and the ones that don't often try making a new account instead). SuperPianoMan9167 (talk) 20:11, 10 December 2025 (UTC)Reply
Then why are editors getting indeffed for LLM misuse right after being brought to ANI? they aren't. They are being indeffed for breaching policies like disruptive editing in exactly the same way they would be if their disruptive editing was unrelated to LLMs. Thryduulf (talk) 20:27, 10 December 2025 (UTC)Reply
Of their examples of 'incivility' much of them were quite evidently comments about content and not contributor. Their 'creepiest of all' example seems to be from a misunderstanding of what speedy deletion means, as they seem to think Tankishguy meant a speedy deletion of them as a user rather than of the page User:Orange Jones. They even quoted me saying Competence is required… If you aren't capable of being clear, respectful, and organised without AI help, then you simply can't participate here. as an evidence of incivility -- which, obviously I'm biased, but seems to me like a pretty straightforward summation of CIR.
And I'll say now what I said previously to another problematic AI contributor; civility is mandatory, but respect is a two-way street. If you're going to come into Wikipedia and make no effort to engage meaningfully with the project, spitting out AI-generated unblock request after unblock request and straight up saying "AI is too useful to me, I can't promise I won't use it again" after people have stressed again and again how your AI usage is problematic, you can't really be surprised if editors want to wash their hands of you and get a little terse in their interactions with you.
I won't shed any tears if the editors we lose by being harsher on AI are the kind of editors who persist in misconduct after it's been repeatedly and patiently pointed out to them, and then cry foul when people lose their patience. Athanelar (talk) 20:48, 10 December 2025 (UTC)Reply
What if the editors we lose by being harsher on AI are also the kind of editors who are doing their best to bring a global perspective to articles that deserve a {{globalize}} tag? People who don't write easily in English can nonetheless provide useful, encyclopedic contributions. I don't think we need a "ban AI" rule to get rid of people who persist in misconduct. WhatamIdoing (talk) 23:18, 11 December 2025 (UTC)Reply
We're an English-language encyclopedia. I don't think sacrificing our English competency requirements is worth it for a potential increase in global perspective. Athanelar (talk) 00:46, 12 December 2025 (UTC)Reply
Blocking feels punitive to most people, even when the motivation is purely preventive.
Also, in operant conditioning terms, if a short block improves an editor's behavior, then it actually is a punishment. (Punishments are stimuli that decrease the likelihood of a behavior recurring. Even something so mild as suggesting a better alternative can be "a punishment" in this sense.) WhatamIdoing (talk) 19:27, 11 December 2025 (UTC)Reply
Well, yeah. Just like a newcomer who has zero experience with Wikipedia policies and guidelines is expected to educate themselves on notability, verifiability etc before they run off and start submitting drafts at AfC or mainspace. If they fuck up once or twice then we give them a 'heads up' and explain why they shouldn't do what they're doing, but if they keep doing after that then they get a block until they can demonstrate that they know what they're doing is wrong and why they shouldn't be doing it.
In fact I find the approach that tells us new editors need lots of hand-holding and infinite warnings patronizing rather than helpful, because it assumes that new editors are all stupid. Most aren't, and can figure things out given a bit of encouragement. Cremastra (talk·contribs) 20:09, 10 December 2025 (UTC)Reply
That, and competence is required; somebody who needs a million reminders about appropriate conduct and doesn't have the presence of mind to do a little bit of independent research before taking action isn't likely to be a productive editor anyway. Athanelar (talk) 20:17, 10 December 2025 (UTC)Reply
Just like a newcomer who has zero experience with Wikipedia policies and guidelines is expected to educate themselves on notability, verifiability etc before they run off and start submitting drafts at AfC or mainspace.
The first link there is about not assuming bad faith just because somebody is ignorant.
The second, similarly, is to say you're not exempt from being accused of BITEing just because the newcomer is ignorant.
The third only reinforces my point with its section WP:CAREFUL; we encourage boldness, not recklessness. You're expected to do at least some forethought about what you're doing, whether you're doing it right, and whether you should be doing it at all. If someone decided a piece of wording in WP:N was unclear and substantively changed its meaning of their own volition 'to be bold' without any attempt at consensus-gaining, they'd be in for a serious trouting at the least, even if they were a newcomer ignorant of those concepts.
Well, I think it's moreso that nobody has bothered to report them. I thought the same thing when I saw the AINB case about User:AKLKPhilo and when I decided to escalate that to ANI they were indeffed five minutes after I submitted my report. Athanelar (talk) 19:32, 10 December 2025 (UTC)Reply
Well, that was because they lied about verifying the output and then continued to add hallucinated sources, and also because they violated COI guidelines by recreating their COI page into mainspace after having a draft declined.
AI-generated articles are already per se forbidden, by WP:NEWLLM. This proposed revision would forbid much more than AI-generated articles, it would forbid using AI altogether, for anything. (I know, you say it only says "should not" not "must not" but we've already covered our disagreement on that point.) Levivich (talk) 19:45, 10 December 2025 (UTC)Reply
Well, yes, and I'm very transparent about being in favour of an eventual moratorium on all AI-generated additions to Wikipedia, even if I don't think this proposed guideline is that necessarily. Still, AKLKPhilo's block isn't really a good example that such a thing isn't necessary - because their block was based on other substantive policy/guideline breaches anyway. Athanelar (talk) 19:48, 10 December 2025 (UTC)Reply
Yeah, exactly. I've seen the sentiment floating around that there's some kind of de facto prohibition of AI usage being enforced, and while I wish that were the case I don't think there is. The whole point of guidelines like this one is to start enforcing a stricter standard of usage for LLMs. Athanelar (talk) 20:08, 10 December 2025 (UTC)Reply
The whole point of guidelines like this one is to start enforcing a stricter standard of usage for LLMs.
I think that's just a weak argument, or at least selectively applied. We have no problem understanding that WP:Notability is both simultaneously a guideline and also an essentially incontrovertible standard that an article must follow in order to be included, and I think we therefore must also be able to understand that any guideline-based prohibition against LLM usage is both a prohibition and also subject to common sense exceptions, interpretive wiggle room, etc. Athanelar (talk) 20:23, 10 December 2025 (UTC)Reply
What I'm saying is that the guideline should explain itself. I'm not really against expanding restrictions on LLM usage; I would actually support a prohibition on unreviewed or poorly reviewed LLM-generated additions to articles. This is because, as you said, LLMs are essentially useless at producing any text in wikivoice. If there are exceptions to this, WP:IAR covers them. SuperPianoMan9167 (talk) 22:59, 10 December 2025 (UTC)Reply
Latest comment: 4 days ago39 comments13 people in discussion
CGI recreation of the two Hellenic AF F-16s inspecting the aircraft
I've just removed this image, with this caption, from Helios Airways Flight 522. My rationale was Not sure that a CGI file is particularly helpful here. In general, is it a good idea to illustrate articles with CGI images, in situations where we'd use a real picture if one were available? I'm not talking about graphics/drawings/etc., but CGI "photographs". My question assumes that the image doesn't already violate any policies (e.g. copyright), that it accurately illustrates the scene, that we don't currently have a real picture that could replace it, and that it acknowledges itself to be CGI.
In my opinion, it isn't particularly helpful, since it doesn't necessarily reflect the scene's actual appearance. Do others agree with me, or am I too picky here? I consulted Wikipedia:Image use policy, which talks about AI-generated images, but it doesn't address images created with human input, like this image that was created in 2008. Hesitant to ask this at the policy's talk, both because my question is more of a style-type thing (versus IUP heavily concentrating on copyright, privacy, etc.) and because VP gets better visibility. Nyttend (talk) 09:23, 7 December 2025 (UTC)Reply
I'm not sure either. On the face of it, as long as we properly declare that this is a CGI recreation and not a photo, it could be helpful to readers. My main concern is accuracy. Perhaps this could be seen as similar to a user-generated diagram, but it's much harder for someone else to edit than most of our maps and diagrams, which are SVG files. This rationale got Osmosis videos removed from articles many years ago. Toadspike[Talk]09:58, 7 December 2025 (UTC)Reply
User:Toadspike, I'm envisioning situations where there's no specific accuracy dispute. I'm going at the issue of using an image that's obviously not a real photo, and objecting because it's obviously not a real photo, even if the uploader could prove that it's 100% accurate. In this case, it looks as if someone uploaded something from a freely licenced version of Microsoft Flight Simulator; in my mind, such images just aren't good for much of anything, except discussions of the software, CGI in general, etc. I don't think ease-of-editing is really significant; I've never heard of Wikipedia:Osmosis before, but Wikipedia:WikiProject Medicine/Osmosis RfC makes it sound as if the problem were that the videos had errors that couldn't easily be edited away in this format. If the videos hadn't had errors, and if they were in a field where information doesn't really change (e.g. a video of this air crash), that might not have been a complaint. Nyttend (talk) 18:58, 7 December 2025 (UTC)Reply
Very good points. I think, provided a CGI image is accurate and relevant, they shouldn't be entirely disallowed. But it really depends. Do you consider 3DBenchy a valid example of what you're talking about, or do you only mean realistic CGI scenes? Toadspike[Talk]23:47, 7 December 2025 (UTC)Reply
Sorry, didn't mean to be annoying. I was simply hoping to point out that I think you're concerned about CGI models of realistic scenes, not all CGI imagery.
(Pedantry, feel free to ignore: 3DBenchy isn't a physical object, it's a 3D model that 3D printers print to varying degrees of success. In that our lead images of 3DBenchy are 2D computer-generated images of a 3D model, they're not all that different from the flight simulator image that began this discussion.) Toadspike[Talk]20:33, 8 December 2025 (UTC)Reply
Wasn't annoyed, just confused. I think the lead images in the article are good, since they show the ideal, versus the photos lower down that depict how individual printers render it. It's a good example of a situation where CGI is outright better than a simple photo; this isn't one of the "situations where we'd use a real picture if one were available". Nyttend (talk) 02:41, 9 December 2025 (UTC)Reply
If a reliable source had created the CGI, that would be worth an inclusion discussion. User-generated illustration attempts such as the example here are a can of worms and generally unacceptable for the reasons described at WP:USERG and WP:SYNTH. ~ ToBeFree (talk) 14:51, 7 December 2025 (UTC)Reply
User:ToBeFree, I should have excluded images from reliable sources, e.g. architects' renderings of buildings or NASA drawings of US spacecraft on other bodies. I was thinking of images created by Wikimedia editors or freely licenced images created and uploaded elsewhere online by other average people. Nyttend (talk) 18:41, 7 December 2025 (UTC)Reply
Doesn't WP:IMAGEOR directly contradict that argument? Original images created by a Wikimedian are not considered original research, so long as they do not illustrate or introduce unpublished ideas or arguments. Anomie⚔14:55, 7 December 2025 (UTC)Reply
"Speculative" could be ok if it's illustrating something that's already described in the article with appropriate sourcing and the illustration helps reader understanding and doesn't wind up giving the speculative topic undue weight. The important part, IMO, is that people consider actual relevant factors like that rather than blindly saying "User-made image is OR! OR is bad!". Alas, too many people like to do the latter, because it's much easier to take out things they don't like that way. See User:Masem's reply posted just as I was writing this, for example, trying to nitpick the accuracy of the airplane model when that's completely irrelevant to the merit or lack thereof of the image in the context described. FWIW, I agree with the removal of this image from this article since it doesn't seem to serve any purpose except decoration, and the article already has other images and floating boxes that serve that purpose well enough. Anomie⚔15:22, 7 December 2025 (UTC)Reply
Regarding "speculative" that opens up issues when the illustration is of reliably-sourced speculation. For example a lot of accident investigation involves speculation on precisely what happened - that speculation is based on and bounded by all the available facts and other evidence and is usually presented as being the (significantly) most likely explanation but it is inherently still speculation. Whether illustrating that speculation with a user-generated image is appropriate is a different question that can only be answered with knowledge of the specific circumstances. The answer I suspect will usually, but crucially not always, be "no" - but this is speculation on my part.
On the topic of CGI images more broadly, an absolute prohibition is impossible (even more so than one on AI-generated images) because there are hugely many such images that are created by reliable sources, some of which are themselves notable. Even user-generated CGI images have their place, see many of the illustrations of articles about CGI topics for example. I also expect there are some mathematics illustrations that can be created with no original research at all. Thryduulf (talk) 15:57, 7 December 2025 (UTC)Reply
Thryduulf, I forgot to exclude images created by reliable sources. I meant images created by Wikimedia editors, or images created by other average people and uploaded to other websites with acceptable licences. And my original post specifically talks about CGI images sitting in the place of a real photo; your example, "illustrations of articles about CGI topics", is one where a real photo wouldn't work. Nyttend (talk) 18:45, 7 December 2025 (UTC)Reply
If there existed a 3d more del file of the planes that was freely available, that would be OK. If editors were eyeballing or creating the model on their own without clear published specs or dimensions, that's a problem in OR Masem (t) 15:16, 7 December 2025 (UTC)Reply
The positioning of the planes may also be OR. Some speculative illustrations may have their place, but I'm not sure what this particular image adds to a reader's understanding of the topic. CMD (talk) 15:33, 7 December 2025 (UTC)Reply
Hypothetical: say we had good sourcable models of the planes involved, and sourced information that said something like "the support plans typically fly 500-1000 yards to the side and 300-500 yards behind the lead plane", then a CGI that combines those models with those representative distances against a generic BG is completely fair. But if we didn't know the exact distances in the formation, then that's speculative and would be OR. Masem (t) 19:47, 12 December 2025 (UTC)Reply
As I discussed in various threads within Wikipedia:Requests for comment/AI images § Relist with broader question: Ban all AI images?, the quoted phrase isn't a blanket exemption of user-created images. Images must still be verifiable to reliable sources appropriate for the content being conveyed. Cases like graphs based on data from appropriate sources, or minor photo retouching, can be directly verified by any editor by comparison with the source. An image of a grid of 1000 dots can also be directly verified by any editor (if somewhat tediously). A computer-generated image of a plane in flight, in my view, goes beyond this threshold, and so I think it should come from a reliable source in order to meet the verifiability requirement. isaacl (talk) 18:16, 7 December 2025 (UTC)Reply
Same as with all content: its relevance must be verifiable. The provenance of any content must be evaluated, in terms of its reliability, editorial control, and suitability for what is being verified. isaacl (talk) 22:03, 7 December 2025 (UTC)Reply
You didn't specify which image. Assuming you meant the first one on the page, it appears to come from a page that generates images on demand. As such, there's no cited source to indicate that it exhibits the properties of the page's subject. isaacl (talk) 03:12, 8 December 2025 (UTC)Reply
You're welcome to your opinion, but it doesn't match what the policy page actually says. The real issue in a case like this is less "verifiability" (there's nothing much to "verify" in an artist's impression that's labeled as such, whether it's a hand-drawn sketch or a CGI mockup) than it is relevance, but it's easier for people to handwave at "verifiability" and such to try to remove things they don't like. Anomie⚔22:39, 7 December 2025 (UTC)Reply
I kinda think that that CGI image is useful; it helps to have some visual accompaniment to break up walls of text and provide interest, and as long as it's not claimed as real it's actually great to have that CGI image there. Mrfoogles (talk) 16:52, 9 December 2025 (UTC)Reply
IMO, we should make a more explicit distinction between images that were created by editors/non-RS and those that were reliably published. Diagrams/representations uploaded by editors, if used in an article, should include their provenance as user-generated clearly in the caption (same goes for published images). However, photorealistic CGI should only be used if it was first published in RS; otherwise it is far too likely to mislead readers even if the caption says it's CGI (which wouldn't be immediately apparent anyway when it shows up in Google image results). In any case the accuracy of the upload doesn't matter (I don't see why we would even accept an editor's assurance that an image is accurate if it's not actually directly verifiable). JoelleJay (talk) 18:50, 10 December 2025 (UTC)Reply
Not sure how this would interact with MOS:CREDITS, which disallows crediting the image creator in captions "unless relevant to the subject". I personally do not think adding what is essentially a warning label to user-generated diagrams (like File:Laffer_curve.svg) is necessary, though I agree that a similar warning would be warranted for "photorealistic CGI", which is really what this whole discussion is about. Toadspike[Talk]09:40, 11 December 2025 (UTC)Reply
I know MOS:CREDITS discourages this (for valid reasons), but I think there are also very valid reasons to inform readers that, unlike every source cited in the text, an article's diagrams sometimes may not be reliably published by an SME. While readers can assume that the text itself is the original writing of a WP editor—and when it's not, it's made explicit through quotes—I think readers are far less likely to realize that some otherwise-professional-looking diagrams are editor- (or especially random Flickr uploader-) generated. JoelleJay (talk) 17:30, 11 December 2025 (UTC)Reply
There's a difference between describing an image in its caption and adding a "warning" that an image was created by a Wikipedia editor rather than coming from an external source. Anomie⚔19:36, 12 December 2025 (UTC)Reply
It's either a credit, a warning or both. If you say it isn't a warning, then you must be arguing it's a credit instead. However none of the arguments presented are relevant to it being a credit. Thryduulf (talk) 20:06, 12 December 2025 (UTC)Reply
Or it's just additional information that is relevant to readers, much like a citation (which would also be fine at the end of the caption)... JoelleJay (talk) 17:34, 13 December 2025 (UTC)Reply
But that's not how it's being framed in any of the comments above. Why is it relevant information that the image was created by a Wikipedian if not to give a credit or a warning? Thryduulf (talk) 23:07, 13 December 2025 (UTC)Reply
I am using "disclaim" in the sense of denying responsibility for certain statements, by virtue of using quotes. Maybe it's not the best word, but the intended distinction is still there. JoelleJay (talk) 20:03, 12 December 2025 (UTC)Reply
Case-by-case. The "if one were available" is an important part of where we'd use a real picture if one were available. We accept drawings/illustrations in some cases, so why not drawings/illustrations made with a computer? Won't be right for all cases, of course. — Rhododendritestalk \\ 21:37, 12 December 2025 (UTC)Reply
RfC - The inclusion of destination lists in Airport articles
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Airport destination lists: Should airport articles list full and complete lists of destinations reachable from the airport, or to what extent should they be curtailed?
Background: Airport destination lists have been a reasonably heavy point of contention in recent months, due to the poor (in many cases) sourcing of these lists, and the constant churn of content being added and removed, often without reliable sources. It got to the stage at one point where editors in this ANI thread were so tired that comments like 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. were left. As a result, a discussion was opened at Wikipedia:Village pump (policy)/Airport destination lists.
As a result of that discussion, the following options were developed as ways forward for airport destinations lists. Note that in every instance, WP:V still applies, and routes must be sourced with reliable sources. Additionally, if it is decided to retain some form of destination tables, it is my intention to have a further RfC to agree upon sourcing requirements for these tables, as this point too has been the subject of sometimes heated debates.
Airport articles should contain comprehensive lists of routes flown from that airport (No change)
Split very large destination tables into separate articles, and retain smaller destination tables in airport articles. For example, the large table in Heathrow Airport#Airlines and destinations would become a List of Heathrow Airport destinations, with a {{Main}} hatnote and a brief summary in the article about the airport. Such lists would normally be considered notable provided that the airport destinations are discussed as a set in independent reliable sources; any that weren't would be merged and redirected back into the airport article to WP:PRESERVE the information.
Replace large destination tables with a summary in prose that does not mention most individual destinations by name. Smaller destination tables may be retained (or not, as editors of that article choose). For example, the large table in Heathrow Airport#Airlines and destinations would be replaced by a paragraph saying that it has dozens of airlines and hundreds of destinations in dozens of countries; Wikipedia would no longer contain information about the individual destinations. However, Eastern Iowa Airport#Airlines and destinations, which lists less than 20 destinations, would be left alone (unless editors of that article preferred a different approach).
Replace every destination table with a summary in prose. For example, Durango–La Plata County Airport#Airlines and destinations has a small table listing two airlines and four destinations, and that would be replaced by two sentences naming the two airlines and four destinations, and larger airports would have longer, potentially multi-paragraph summaries.
Remove destination lists - all information about destinations reachable from an airport should be excluded. For example, Kearney Regional Airport has exactly one airline (United Express) flying to only one destination (Denver, Colorado), and editors should be prohibited from mentioning the airline, the lone destination, the number of airlines, and the number of destinations anywhere in the article.
"Summaries in prose" could broadly take this form (not fixed and not in the scope of the RfC):
Start with a brief summary - eg. Wikipedia Airport is served by sixteen airlines, and has services to 16 countries / 3 continents. The latter would be flexible, and depend on the available sources. Primary sources such as the airport website would generally easily verify this.
Next, have a summary of route development, where this can be verified, including info such as when airlines start flying from the airport, significantly increase their service or cut services. eg: In 2019, Scottish Airlines started flying to Wikipedia Airport, with a service to Edinburgh.[ref] Subsequently, this service has expanded to include other Scottish cities.[ref] In 2020, English Airlines started serving Wikipedia Airport, with services to London Gatwick and Birmingham.[ref] The airline subsequently cut services, instead preferring to fly to Wikivoyage Airport.
Finally, where this can be sourced, have a list of statistics, such as that found at Tri-Cities Regional Airport#Statistics. Many articles already have this, and they are generally well sourced. It would help highlight how important/unimportant the airport is, especially if they can be developed further such as by adding graphs etc.
Note - any individual routes that are specifically listed in a summary, should be sourced with reliable secondary sources, sufficient to satisfy WP:NOTABILITY.
3, or failing that 4 - My personal vote as the opener of this RfC would be these options, as I feel it's the best balance between keeping the relevant information and doing away with unwieldy and "churny" lists. Danners430tweaks made20:03, 7 December 2025 (UTC)Reply
Option 1. The current airport destination tables are informative and largely kept up-to-date by dedicated editors, serving a wide range of readers effectively. The primary issue is sourcing, which requires improvement. Official airline websites should be established as the primary source. This change allows for real-time verification of flight status by any editor - offering the most current flight data available. While this approach might slightly diverge from typical encyclopedic sourcing requirements it would definitely solve the sourcing problem issue. As for cargo destination tables and sourcing - that is more complex issue that needs more discussion. Maybe, just adding a list of Cargo airlines without destinations would be sufficient Dootfish (talk) 22:30, 7 December 2025 (UTC)Reply
1 (mostly) or 2 (I could live with 3 as a very distant backup option, but only if that's the only way to achieve consensus). There is no reason to treat these differently than any list of notable aspects of a subject. If an airport is notable, then what destinations are served by that airport is an important, encyclopaedic aspect of a comprehensive article. WP:SIZE should be the sole determiner of whether the list is part of the main article or a spinout list article. Thryduulf (talk) 20:36, 7 December 2025 (UTC)Reply
Update, the more I think about this and the more comments I read, the firmer I am of the opinion that 1 (but allowing flexibility to choose between an inline list and a separate article, based on WP:SIZE considerations) is the only sensible option. There is no need to require secondary sources to discuss these aspects as a set any more than that need exists for sports team rosters and results, fleet lists, or countless other lists. Option 5 is patently ridiculous - for example it would prohibit mention of the primary reason Papa Westray Airport is notable. Thryduulf (talk) 02:47, 9 December 2025 (UTC)Reply
1 There's absolutely no issue with these lists. They're well maintained and updated, easily verified, and essential to the contextual understanding of both the airport and how the region the airport serves is connected to the rest of the world. The content is clearly encyclopedic reference information. I use these lists about as much as anything else on the site. The table has also over time proven to be the best way to organise this information. SportingFlyerT·C20:53, 7 December 2025 (UTC)Reply
Additionally, those citing WP:NOTGUIDE are completely wrong and don't seem to understand the purpose of these lists. WP:NOTGUIDE exists to make sure we do not write articles like a travel guide instead of an encyclopedia. This information does not exist in travel guides. Route information is also encyclopedic - for instance, Rijeka Airport talks about the first commercial air routes from 1930 in its history section. The information also just needs to be correct and verifiable, which isn't a problem - these are some of the most heavily gnomed parts of the website - and by the logic being used by those proposing to eliminate them, the exact same logic would apply for train routes. SportingFlyerT·C23:07, 8 December 2025 (UTC)Reply
3/4 These lists are inherently unencyclopedic. Discussing them in prose makes sense or having a generalized, limited list in the airport articles. But Wikipedia articles are not meant to be a constantly changing (on the daily at that) morass of added and removed material. Current breaking events are one thing (and even those have their detractors among the community), but these lists inherently are unstable and their purpose is to be forever unstable, forever changing. No material in them is ever meant to be permanent. Which exemplifies why they are unsuitable for an encyclopedia. I've seen multiple editors supporting these lists in past discussions claim that they serve as direct information to build flight itineraries while traveling. That is not what Wikipedia is for. If you want a travel guide, there are sites like WikiVoyage. In short, the information of destinations should be generalized and, where possible, made into prose. The information is meant to be an overview of the subject as a general topic for the airport articles, they should absolutely not be inexhaustive, constantly changing daily lists of all possible flight routes. SilverserenC20:59, 7 December 2025 (UTC)Reply
4 We should be summarizing how an airport is connected to other airports based on what third party reliable sources say, which, for all but region airports, is going to be high level and not include all possible destination. All of these tables rely too much on primary or first party sourcing, making them IINFO, in addition to NOTGUIDE. Since airlines are free to change routes at a whim, three lists are also subject to high variability, we should be looking for a stable, enduring summary, those major new routes added or removed (as covered by third party sources) can be included. Masem (t) 21:01, 7 December 2025 (UTC)Reply
5, airports don't fly anywhere, airlines do. Routes are a property and factor of the airlines not the airport. Airline routes are very much just product listings, and they're about the airline. And this is before we take into account the massive amount of disruption to airport articles around this topic, edit wars, sockpuppets, locked articles constantly, massive violations of WP:RS etc. At the end of the day what routes airlines fly from airports isn't something that should be on the airport article. We're not a product directory, and we're certainly not for having an article on a topic that lists products from a completely separate company. Not a travel guide. Not a list of indiscriminate non-notable information. And there's not even any attempt right now to indicate, reference or support any notability to these routes. However we should be able to mention which airlines use the airport, as hubs bases etc, and which airlines fly from it, just not where to. Canterbury Tailtalk21:06, 7 December 2025 (UTC)Reply
I'm not making the same comment over and over, I'm trying to respond in different ways to some people's (not everyone's) specific comments as different points are made. We're talking about decades of work on thousands of articles potentially being deleted here under misapplication of guidelines. Many people talk about summarization, but I don't trust that the appropriate information people still want to include will be conveyed by currently unwritten summaries – that work has not been undertaken because the full list is so much more informative. But sure, I can pull back on replying. — Reywas92Talk17:46, 14 December 2025 (UTC)Reply
1 (or possibly 2 if there really are cases where the list is so long as to make the whole page unwieldy), but I doubt that happens very often). Per SportingFlyer, these are generally well-maintained by a team of editors who keep an eye on them, easy to verify and very clearly of high relevance when discussing an airport. After all, what is an airport other than a place to fly to other destinations from? For those saying it's unencyclopedic, I'm not quite sure what you think it is that an open-ended unlimited encyclopedia ought to contain. Tables of information relevant to the subject of the article are part and parcel of our content across the project. As an aside, having the lists there is also highly useful for readers - I make use of it myself frequently if I want to fly somewhere and need to see which airports you can reach that place from. Given the large number of content elsewhere on the project which is out of date, poorly sourced, pushing a POV or has other problems, this animosity towards one of the areas which is none of those things and is also encyclopedic is mind-boggling in the extreme. — Amakuru (talk) 21:09, 7 December 2025 (UTC)Reply
3, failing that 4. There are essentially two dimensions to this !vote. The first is the extent to which options 1 or 2 are capable of meeting WP:V. As repeated discussions on this topic, including the RFCBEFORE, have shown, there is a generalised absence of reliable secondary sources which detail airport destinations as a set. Because there are few or no primary sources which detail the cessation of routes, the maintenance of the table itself becomes an exercise in OR. We should not have content whose maintenance is simply incompatible with policy. Second, there is the more nebulous question of encyclopedic value. Clearly, airlines and destinations are to some extent important to the significance of the airport itself. But this differs for small and large airports. For a small airport, specific airlines and destinations are indicative of economic, industrial and demographic factors in the history and significance of the airport. For a large airport, it is ineffective and counterproductive to try to show these linkages with comprehensive lists; it is simply WP:TRIVIA. What is effective is to discuss the evolution, broad patterns, and groupings of routes – a task for which prose is eminently more suitable. Triptothecottage (talk) 21:14, 7 December 2025 (UTC)Reply
@Triptothecottage, do you really mean secondary sources? Wikipedia:Secondary does not mean independent. Secondary sources provide analysis ("My airport is better than your airport for the following three reasons, so my airport should get a bigger subsidy"). Independent sources don't have a vested interest in the subject ("His airport has four non-stop destinations, and her airport has five"). WhatamIdoing (talk) 23:00, 7 December 2025 (UTC)Reply
I did mean secondary sources here, as my emphasis was on avoiding OR: it is not common for us to have sources which say "here are all of the destinations serving this airport, and here is why that matters". I'm not sure the independence of sources is of particular importance here; if an airport's website has an explicit list of routes I don't think there is any major dispute about its reliability. Triptothecottage (talk) 00:29, 8 December 2025 (UTC)Reply
I'm confused about two separate things:
Would you accept an explicit list of routes on the airport's own website? That wouldn't usually be a secondary source (as it's usually just a list, without any "why that matters" content).
If we're just writing "United Airlines, here to Denver" in the article about Smallville Regional Airport, how does the "why that matters" part help us avoid making up content that wasn't ever published in any reliable source? OR == "On Wikipedia, original research means material—such as facts, allegations, and ideas—for which no reliable, published source exists. By "exists", 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" (copied from the top of the policy). If you've got a primary source (like WP:PRIMARYNEWS) that says "United Airlines flies from Smallville Regional Airport to Denver", then there's no possibility of OR in putting "United Airlines flies to Denver" in the article about Smallville Regional Airport. It doesn't seem like having that source add something like "because it will promote the growth of the company and create a healthy bidness climate in the Smallville region" makes any difference at all.
1London Heathrow is one of the bigger airports but I just checked its table which doesn't seem especially problematic. My main observation is that it would be cleaner and tidier without the citations and {{cn}} which seem mainly to be unnecessary clutter. A single source for this such as the airport's interactive route map would be ample.Insofar as there's an issue, it's the need to keep this info up-to-date but there are lots of pages like that on Wikipedia such as the holders of government offices. It appears that Wikipedia's aviation editors are on top of this and so it's not a problem that needs fixing.Andrew🐉(talk) 21:19, 7 December 2025 (UTC) (edit conflict)Reply
1 maybe 2 I don't see personally see anything wrong with the tables so as long as they aren't like getting way too large I don't see why we should change what's working so far --2007GabrielT (talk) 21:32, 7 December 2025 (UTC)Reply
1 or 2 Which destinations an airport serves and which airlines fly there are key information about an airport, making those tables all WP:DUE. For readers, tables/lists are easier to read than prose. Some1 (talk) 21:33, 7 December 2025 (UTC)Reply
Option 1 or 2 per @Some1. Also, raising the bar of sourcing or notability creates an unnecessary effort to retroactively attempt to identify sources for notability. If I were writing a policy from the start, I might limit in some way, but I think we should give deference to the status quo. Dw31415 (talk) 02:34, 15 December 2025 (UTC)Reply
Option 2 — here's my reasoning. I'm against prose summaries, for the simple reason that the destination table should be a summary of prose itself. Airport articles also definitely shouldn't be prohibited from talking about destinations. Sending the largest of destination lists to separate articles is the best option for convenience reasons, but also if the majority of the list is sourced to primary or unreliable sources (which happens already on huge airports, if I understand the issue at hand correctly), the list is liable to get deleted entirely, which, I agree, is sometimes just the best outcome for things that become huge points of contention and soak up editor time. Lists sourced to reliable secondary sources don't violate WP:NOTDB because they are a summary of what reliable secondary sources say about a topic.JustARandomSquid (talk) 21:37, 7 December 2025 (UTC)Reply
Just another comment, I would be open to supporting option 3, but only if applied to the very largest airports. Exceptions should also be granted to airports where there is a reliable secondary source that can be expected to be able to be used. For example, in the region of former Yugoslavia, [16] covers basically every route opening and closure, so no matter how big Belgrade Airport gets, it gets to keep it's list. (FWIW, it is already adequately sourced. Scratch that, I see a lot of Aeroroutes. Still though, it's vastly better than most. If this RfC doesn't result in its removal, I'll personally fix it.) JustARandomSquid (talk) 22:05, 7 December 2025 (UTC)Reply
1 or 2 Anything that turns airports into contextless concrete and buildings is unacceptable to me. Airports stations exist to transport people. Not giving an overview of services is stripping the raison d'etre from them. I could maybe be convinced to replace the tables for large airports with paragraphs that don't list every single destination, but anything as undetailed as "you can fly to lots of places from Heathrow" is unacceptable.--Eldomtom2 (talk) 21:43, 7 December 2025 (UTC)Reply
1, or failing that 2 - I think "should" in #1 is too firm - "may" would be better - but I think the approach of generally permitting them is fine. If we do split out larger tables per #2 then I think having the parent article have a prose summary a la #3 makes more sense than some kind of short table, though - I'm not sure a short/summary version of the table would be particularly practical in most cases. In general, these lists seem to be useful to our readers - when I have mentioned this discussion to non-editors, they have been baffled that we want to remove them - and from a content policy perspective, I do not agree that they are inherently in breach of any of our content policies, so I do not feel we gain anything by removing them. Andrew Gray (talk) 22:42, 7 December 2025 (UTC)Reply
First and foremost, strong oppose option 5 as a major overkill. Where airline flights fly to from an airport is an integral part of the daily operations of a passenger airport, similar to what are the railway lines or companies serving a train station and where the trains go to. They provide insight to the range and scope of an airport’s operations, let it be a major international hub-and-spoke transfer hub (e.g. Doha Hamad, Dubai, Singapore Changi), large domestic airport (e.g. Osaka Itami, Chengdu Shuangliu) or a small regional airport. Not mentioning such things at all, regardless of it being summarised as prose or fully listed in a table, is detrimental to the readers’ understanding of such operations and the role the airport plays. As for the rest of the options, I’ve said it before in WP:DESTNOT that I do not believe they violate WP:NOTTRAVEL, though I can see why some people interpret them that way. I would typically go for options 1 or 2 (no preference over each other since it’s just a matter of splitting on individual discretion), but in the spirit of a compromise to settle things once and for all, my final opinions would be supporting options 1/2/4 tied (no option 3 mainly to enforce consistency). S5A-0043🚎(Talk)21:53, 7 December 2025 (UTC)Reply
Option 4 or 5 - I don’t think the routes are encyclopedic. My thinking is that Airport articles should contain a simple list of which airlines regularly fly in and out of it (not destinations or routes).
Meanwhile, the linked airline articles should simply list the destinations (airports) it regularly flys to (but again, not the routes). Blueboar (talk) 22:16, 7 December 2025 (UTC)Reply
The local airport article says: "Airlines serving this airport include United Airlines."
The article about United Airlines says: "United flies to airports in Abilene, Akron, Albany, Albuquerque, Alexandria, Allentown, Amarillo, Anchorage..."
No article says: whether it's possible to fly directly from the local airport to Abilene or Akron or Albany.
The same logic needs to apply to airline destinations. A high level summary of an airlines route structure, such as hubs and principle destinations, sure, but not every smaller and regional airport, because an airline can change those at the drop of a hat. Masem (t) 00:02, 8 December 2025 (UTC)Reply
The fact an airline has served a smaller or regional airport is some of the most important information about that smaller or regional airport, though. SportingFlyerT·C23:08, 8 December 2025 (UTC)Reply
4 as first choice, 3 as second choice. As I said at Wikipedia:Village pump (policy)/Airport destination lists: that airlines that serve an airport is acceptable content in an airport article sounds good to me - there's almost always at the very least a press release when an airline inaugurate scheduled services from a new airport, and while WP:PRIMARY that is acceptable for citing simple facts (such as, for instance, that Fooian Airlines serves Barford International Airport) - and usually when an airline stops service to an airport this gets reported in at least the local newspaper. Routes on the other hand are sometimes - maybe even often - ephemeral things, subject to change at a moment's notice and without any notification sometimes other than being added or removed from the flight-boards in the terminal, and so destinations served lists are absolutely in violation of WP:NOTTRAVEL. That is the crux that those !voting for 1/2 seem to be not recognizing: Wikipedia is not a travel guide. If (regrettably) 1/2 passes regardless, it should be with the strict provision that all routes in lists must be cited or removed as WP:V is our single most important PAG. - The BushrangerOne ping only22:02, 7 December 2025 (UTC)Reply
1 per SportingFlyer. Historical routes should also be catalogued when verifiable. The destinations flown to via an airport are more economically and socially important to the airport and the area it serves than which airlines fly those routes. J947 ‡ edits22:30, 7 December 2025 (UTC)Reply
1 or 2 as !vote, though in reality 1 and 2 can both be used depending on size (etc). 5 seems barmy to me, there is a reasonable disagreement by some that it is not encycloopedic, other reasonable people think it is encyclopedic. There again, it's an interesting debate here, but not an existential one. EDIT TO ADD for the Closer: Basis of my view is under WP:AIM ="The goal of a Wikipedia article is to present a neutrally written summary of existing mainstream knowledge in a fair and accurate manner with a straightforward, "just-the-facts style".", and this information is fundamental to the purpose of an airport, travel from A to B. ChrysGalley (talk) 23:15, 7 December 2025 (UTC)Reply
1. While the destination lists tend to become somewhat out of date, especially for small airports, I nevertheless see great value in including them, and would argue a great many users come to the article for this information, and use internal links to virtually travel between destination airports and read about them. What exactly is the problem with including this content? Even for the largest airports, they are not overwhelmingly large (so I don't see a need for option 2, though I suppose in extreme circumstances, would be acceptable). Summarizing the table content in prose is a terrible idea, a table is exactly the correct format to present this information. Mdewman6 (talk) 00:04, 8 December 2025 (UTC)Reply
After seeing months of back and forth ANIs, RSN discussions etc. option 5 the previous RFC concluded with when independent, reliable, secondary sources demonstrate they meet due, now its been discussed that it ws based on a misunderstanding of what secondary sources meant but if we ignore the secondary aspect and stick to independent, reliable, then unfortunately that has been ignored by maintainers of these tables since the rfc. Lavalizard101 (talk) 00:43, 8 December 2025 (UTC)Reply
1 or 2, but either result should not be binding and up to local consensus at a particular page (e.g. if editors at Fooian Airport deem that a separate article isn't warranted despite it being large enough to split off, they should be permitted to do so). This does not have particular bearing on the verifiability of such lists, which is different (there is currently some more problematic content on some of these lists that should be removed, but this does not impinge on the encyclopedic nature of these lists on a more abstract level). However, I am also not opposed in principle to editors at a particular airline article deciding that they wish not to have a route list and instead summarize the information in prose, if that is the consensus of editors at that particular article. But I am strongly against option 4 insofar as it prohibits comprehensive lists from existing on any article, but not against not summaries in prose in the abstract. It's unclear if this RfC is supposed to be binding for all airport articles (i.e. option 1 would mandate that every airport article would have a table, even if some editors had previously preferred a WP:SPINOFF), but I would much prefer if we leave how the information is organized up to consensus of editors at that article rather than institute a particular rule for organization.Katzrockso (talk) 00:53, 8 December 2025 (UTC)Reply
3 or 4: I think there should be, at a minimum, a section that mentions destinations such as in prose form. The issue, as I'm sure most editors know, is sourcing. A lot of destinations at larger airports can be hard to find secondary sources for. I do think the lists are notable to warrant some inclusion, but I find myself going back and forth on what the best way for that information to be included is. (VenFlyer98 (talk) 02:51, 8 December 2025 (UTC))Reply
There is simply no need to limit this content to only that covered in "secondary" (or non-independent) sources. It is not a controversial or exceptional claim to state an airline flies a certain route, nor are airports' or airlines' statements on these uncomplicated facts going to be biased or misleading. Even if there's not much coverage of, say, a longstanding regional route, there's no reason to exclude this when it's still perfectly verifiable through timetables, maps, or other sources that might not be secondary, since editors are still not doing any analysis or synthesis to say "JetBlue: JFK to Boston". Reywas92Talk04:52, 8 December 2025 (UTC)Reply
Option 4 per Masem and Bushranger. Wikipedia cannot include every fact that is verifiable, even those that are useful or interesting to certain readers. We use independent sources to establish notability for standalone articles or lists, and it's my view we should also rely heavily on the quality of sourcing to indicate what merits inclusion in an article. Not only does this serve as a bulwark against corporate promotion, it gives us a fair standard we can apply to any possible topic. And if readers want to know more than what we provide in an article? That's why we have external links. —Rutebega (talk) 03:16, 8 December 2025 (UTC)Reply
Specific facts within articles are simply not subject to the same notability requirements of standalone articles as a whole. It's absurd to call simply naming a route as part of an airport's network "corporate promotion"; business activities are still encyclopedic information that we cover in a variety of contexts. We are also not including "every fact that is verifiable", which might also include frequencies, schedules, aircraft used, terminals used, and other details related to flying. Reywas92Talk04:52, 8 December 2025 (UTC)Reply
It's not clear to me from your comments here why you would even be against including frequencies, schedules, aircraft used, terminals used, and other details related to flying. —Rutebega (talk) 03:16, 10 December 2025 (UTC)Reply
1 It's entirely unnecessary to have yet another discussion that ponders deletion of valuable encyclopedic content from thousands of articles. Airport destination lists provide significant context about an airport's operations, such as the airlines that operate there and their relative levels of service and the airport's role in the air transportation network to serve regional, national, or international destinations, applied equally to large and small airports. Airports are not merely buildings and runways, but part of a system of commerce and transportation through their destinations. Routes are in fact a property of an airport, its raison d'etre: Airport authorities are closely involved not only with airlines' presence at the airport but also routes they fly. These airport operations are also regularly covered in a variety of news sources as a topic of interest to the general public. These tables are well maintained by many editors, and the straightforard, uncontroversial content is easily verifiable through reliable sources; there is no need to limit the type of sources that may be used as this is not going to be subject to bias or misinformation. That's part of the beauty of Wikipedia, that we can update content when it changes. Deleting the content but replacing it with a summary is not an appropriate compromise option as it does not inform readers of this key information, and it may be difficult to appropriately summarize something that is no longer in the article anyway; a table is much easier to read and simpler to convey the information than prose in some undefined form. The fact that some readers may use it to learn things about travel does not mean it is a travel guide, which refers more to a certain tone of presentation, and does not mean it should be deleted in bulk so we are less informative. Reywas92Talk04:52, 8 December 2025 (UTC)Reply
4 (or 3 as second choice): comprehensive lists are inherently unencyclopedic and go against the spirit of WP:NOTGUIDE in particular. All we need to know to understand how the airport fits into the broader context (is it a major hub serving hundreds of routes, a minor regional airport with just one or two destinations, or somewhere in between) can be expressed in prose. If you want more details, the chances are you're trying to use Wikipedia to plan a journey, in which case there are plenty of travel-oriented sites that can give the full, up-to-date picture far better than an encyclopedia could or should. Prose also gives us more flexibility to document historic aspects (e.g. the airport was well connected until the early 1990s when XYZ Airlines chose to relocate its hub to ABC...) than tables. Rosbif73 (talk) 07:43, 8 December 2025 (UTC)Reply
This is a contradiction – Wikipedia doesn't give enough information and travel-oriented sites are much better, yet these simple lists that give no information beyond wikilinks to other airports served is a forbidden travel guide? I agree that we don't and shouldn't give the "full picture" – we don't say whether a route is served once a week or five times a day, we don't say what it costs or any other booking details. These tables give enough information to encyclopedically help readers understand how the airport works and how it's connected, but it's not at all enough to actually be used to plan travel. We already can describe airports use as hubs or a general number of destinations in prose, but that's no reason to delete the additional relevant content. — Reywas92Talk14:46, 8 December 2025 (UTC)Reply
Not a contradiction at all. We've had comments in the previous discussions (and indeed in the discussion section below) stating that they have consulted these tables when stuck in an airport and trying to replan a journey. I should perhaps have clarified If you want more details than will remain in the future prose version, i.e. if you're looking for a comprehensive list of destinations... then you're probably in the first stages of planning a journey. Of course you can't go as far as booking a flight using only the information in these tables, but that doesn't change the fact that comprehensive lists go against various aspects of WP:NOT. Rosbif73 (talk) 15:16, 8 December 2025 (UTC)Reply
I look at these lists all the time when I'm not planning journeys to or from them. I learn so much about an airport by seeing the presence of major airlines or regional airlines, nearby destinations or faraway international ones, its role as a hub or as a spoke. Why would we delete something for the very reason that we know people actually read it? That's a pretty dumb use case though. — Reywas92Talk15:34, 8 December 2025 (UTC)Reply
Adding additional rationale from my comment in the discussion section below, regarding the non-encyclopedic nature of comprehensive lists: they purport to be a snapshot of destinations served at a given date (generally recent but unspecified), yet the actual destinations vary over time. How can that snapshot pass the WP:10YEARTEST?Rosbif73 (talk) 15:35, 9 December 2025 (UTC)Reply
Option 1-ish - no action for now and escalate the discussion. Please excuse a lengthy input here.
I'm glad to see this come up because at RfC on consensus of WP:DESTNOT at WT:NOT I was disappointed that the reasonably long close for the surprisingly long RFC did not say anything about the mentions to WP:NOTDB, WP:NOTTRAVEL, and WP:NOTDIRECTORY. I say Option 1 to pick no action at this time because there was not such consensus or discussion about the general principles that would make editing easier, as seems clear from the confusion and disagreement among folks here and in the windup forming this RFC, and that lack seems why we are here. Status Quo should hold as it doesn't seem like all aspects have even emerged, plus that functionally jumping to a different end conclusion without stating such basis items would not be clear and would not provide guidance well for future edits. In particular folks are discussing just the huge airports, not guidelines that would apply for most or all airports. Caveat the Option 1 phrasing "should contain comprehensive lists of routes flown" might be better as the discussed wording 'acceptable' since that seems more where the prior guidelines were and to better respect that for many airports it is not done and maybe is not appropriate. Other items:
Points of general agreement - I believe there are four background points folks seem generally agreeing to -- (a) we are discussing guidance (more than an essay, less than a policy) for the demarcation of how much detail 'should' be included; (b) to consider and state how the guidance relates to existing guidance such as NOTDB/NOTTRAVEL/NOTDIRECTORY; (c) we consider and perhaps alter prior RFCs (Wikipedia:Village pump (policy)/Archive 187#RfC on the "Airlines and destinations" tables in airport articles] (Nov 2023) only if secondary sources demonstrate DUE, NOCON on listing destinations) (Wikipedia talk:What Wikipedia is not/Archive 60 from January 2025 reached a consensus that both List of airlines destinations articles and airport destinations lists don't violate WP:NOTRAVEL ; and (d) stating airlines is OK, times or specific flight numbers are right out, and destinations for each airline there is where the discussion is at.
Escalate please - I see mentioned that similar considerations came up for rail, and I think it does or should escalate up and generally discuss as points for a higher abstract Transportation hub. For any airport, sea port, rail hub, or bus terminal it's going to be desirable to describe the location, facilities, corporations using it, and capabilities. In all cases they would be likely to at least be using the appropriate infobox items, but we're talking what content to have below that.
Context - In each case, the article is going to have the context of a particular airport, and that's going to be the key for WP:RS, WP:V, and WP:DUE. It is explicit for WP:RSCONTEXT. The WP:DUE question seems whether this data matters to the airport or on the scale of the airport. And the WP:V seems to relate to the prior RFC asking for secondary sources -- but most entries are getting done with primary sources of the airline. Might have to consider that 'no consensus' to make it delete all such tables or to remove the 'secondary' requirement, because de facto the requirement conflicts with it's purpose of 'not deleting' all such tables, and we wouldn't want to have just partial lists of the pieces with secondary coverage. In all cases, it seems like nobody considered what the size and location of the airport does and covering the more usual case of smaller airports. If I look at List of airports in the Greater Toronto Area, the situation for Toronto Pearson International Airport is different than Billy Bishop Toronto City Airport, and much lesser for Brampton-Caledon Airport. (List of airports in India seems similar.) A major airport seems likely to have secondary press or other coverage but not for each one of a hundred routes, a small airfield might have little coverage but would for any of it's five routes, an a really tiny airport would have no coverage at all and no scheduled airline routes.
Some consensus? -- In the discussion at discussion was opened at Wikipedia:Village pump (policy)/Airport destination lists, User:Danners430 said "For better or worse, airports can be measured in their importance by the number of flights they have." offering number of flights or passengers as a measure why Heathrow Airport is seen as more important than Gatwick Airport. User:The Bushranger indicated their demarcation concern is transience at "airlines that serve an airport is acceptable content in an airport article sounds good to me - there's almost always at the very least a press release when an airline inaugurate scheduled services from a new airport, and while WP:PRIMARY that is acceptable for citing simple facts (such as, for instance, that Fooian Airlines serves Barford International Airport) - and usually when an airline stops service to an airport this gets reported in at least the local newspaper. Routes on the other hand are sometimes - maybe even often - ephemeral things, subject to change at a moment's notice and without any notification sometimes other than being added or removed from the flight-boards in the terminal, and so destinations served lists are absolutely in violation of WP:NOTTRAVEL " I take from this that the list of all routes would be significant for the airport, the issue is for a daily fluctuation -- so perhaps keep the routing of a flight path as something that is coordinated and kept in place but exclude daily fluctuation such as a weather cancellation ?
@Markbassett:I take from this that the list of all routes would be significant for the airport, the issue is for a daily fluctuation No, that's not what I meant at all. Routes in general violate WP:NOTTRAVEL. Airlines are fine. I.E. "Foobar International is served by Barfoo Airlines" = okay. "Foobar International offers flights to Alphabeta, Gammadelta, and Etaiota via Barfoo Airlines" = not okay. - The BushrangerOne ping only23:45, 8 December 2025 (UTC)Reply
User:The Bushranger - understood, but WP:NOTGUIDE does not apply because this does not give guidance or recommendations, see "not the telephone numbers or street addresses of the "best" restaurants". A list of the airlines serving an airport seems to me just a key part of the facility or capability information, just as one might have a map shown for an underground or canal ssystem showing the routes of those. Cheers Markbassett (talk) 05:05, 9 December 2025 (UTC)Reply
5 as first choice, 4 as second choice: This information is subject to change too frequently and I wonder what encyclopedic value a larger prose or list would hold. A brief paragraph about the routes is enough for most articles, if at all.Kingsacrificer (talk) 10:11, 8 December 2025 (UTC)Reply
@Kingsacrificer, when you wrote that This information is subject to change too frequently, which airport did you have in mind? I'm sure it's not a small airport, since those rarely change even once a year. When I was clicking around during the drafting of this RFC, I found some that hadn't changed for longer than a decade. WhatamIdoing (talk) 01:01, 9 December 2025 (UTC)Reply
I meant small to medium sized airports, particularly in India. They sometimes service a route for a month, then don't, then begin again. It's rather sporadic. Perhaps it may not be the same for other airports. Kingsacrificer (talk) 09:43, 9 December 2025 (UTC)Reply
4 as first choice. Then 3, then 5. The current situation is wrong. Per Canterbury Tail, the airport doesn't fly anywhere, and where airlines fly is subject to change. However, I believe that it is relevant to article prose that there be some discussion of what routes can be flown from an airport. Croydon airport, for instance, was an international airport, and that is relevant, historically significant and encyclopaedic information. The prose rightly mentions routes to India, Africa, the Middle and Far East, Asia, Africa and Australia, and mentions Qantas. Not relevant to anyone now is what flight numbers went at what times, because that is not historically significant nore encyclopaedic. That is destination guide stuff, and does not belong in an encyclopaedic article written in summary style. So prose mention of routes, where the prose and subject demands it, is fine. What is definitely not fine is 1, especially as the information thus presented on Wikipedia can not be relied upon, and may, in fact, distract readers from finding the correct information on airline or airport websites. Wrong and out of date information is significantly worse than no information. And on Wikipedia it will always be wrong somewhere. Excise it. Sirfurboy🏄 (talk) 10:28, 8 December 2025 (UTC)Reply
4 – These lists encourage users to add unencyclopedic content to articles, in a clear violation of WP:NOTGUIDE. Notable aeronautical routes will be covered in reliable secondary sources, and these can be included in the article body. There is no need to provide a table of potential routes, which is impossible to keep up to date or verify – if a reader wants this information, he's better off calling the relevant aeronautical company. Wikipedia should not try to be something it is not! Yours, &c.RGloucester — ☎10:29, 8 December 2025 (UTC)Reply
We've already had a major discussion that found a clear consensus that a list of everywhere an airline flies from an airport does not violate WP:NOT, so no, this is not a clear violation. This is false – we have many users who have done a fantastic job keeping these sections up to date, and it is straightforward to verify with timetables, route maps, news, and other sources. It's much more straightforward to simply include all the routes rather than determine what makes specific routes notable and fluff it up with unnecessary text in the body. The encyclopedia has has this for decades now and we are not trying to be something else. — Reywas92Talk14:54, 8 December 2025 (UTC)Reply
If something is not a WP:NOT violation in two articles, and many people explicitly commented (in both original and follow-up RFCs) that it would also not be a WP:NOT violation in other articles other than those two, then it is ludicrous (and at bordering on either bad faith or incompetence. Even if not quite over the line it is extremely close to such) to say that it's presence in a different article of the same type is {{a clear violation of WP:NOTGUIDE}}. It's not impossible that it is actually a violation, but it's unarguably not an unambiguous one. Thryduulf (talk) 16:26, 8 December 2025 (UTC)Reply
No need to withdraw, I am well-known to be incompetent. Please note that I expressed my opinion, based on my reading of the relevant policy, which is my prerogative. I do not think there is any benefit to Wikipedia hosting this information. Yours, &c.RGloucester — ☎21:49, 8 December 2025 (UTC)Reply
Your having that interpretation of policy is fine. Your stating or implying that that interpretation is obviously and unarguably correct when multiple good faith editors explicitly disagree with that interpretation and there is a community consensus that your interpretation was incorrect in a directly equivalent case is not fine. Thryduulf (talk) 23:50, 8 December 2025 (UTC)Reply
We're not stupid: The first RFC was an obvious attempt to delete content from not only those articles but identical content from related ones. The follow-up was intended to vacate that clear consensus and a clear majority still said it applied broadly. — Reywas92Talk20:31, 8 December 2025 (UTC)Reply
It's a good thing then that these are simple summaries that are merely names of connected airports then, and not exhaustive lists with every single aspect like what days and times the routes are flown and what aircraft are used or how long they've been flying them. No one's conducting business with this, and I think it is significant as to what airlines operate at an airport and what routes are served. — Reywas92Talk14:56, 8 December 2025 (UTC)Reply
" simple summaries that are merely names of connected airports" - and the airlines that fly them (so if more than one airline flies it, it gets listed multiple times), and whether they are "seasonal" and the date when future routes will begin (to the specific day), and whether they are "passenger" or "cargo". And if you doubt that all this is standard practise, that is exactly how Heathrow Airport#Airlines and destinations is written. FOARP (talk) 19:04, 8 December 2025 (UTC)Reply
This is irrelevant nibbling at the edges. If you want seasonal routes rolled into the indefinite routes or not to give announced starting/ending routes, that doesn't require deleting the tables as a whole. Obviously passenger and cargo routes are different. — Reywas92Talk20:35, 8 December 2025 (UTC)Reply
A variation of 23, as smaller airports should have a complete list, but the largest airports should just summarise, as the list would be too big and too hard to maintain. Graeme Bartlett (talk) 10:03, 9 December 2025 (UTC)Reply
The existing lists at large airports are maintained perfectly well at the moment, so your !vote seems to be based on an incorrect premise. Thryduulf (talk) 12:00, 9 December 2025 (UTC)Reply
I beg to differ. Even for relatively "large" airports, some lists are far better maintained than others, and even among the well maintained ones the sourcing often leaves much to be desired. Rosbif73 (talk) 12:44, 9 December 2025 (UTC)Reply
3 – The idea is that articles should include destination lists when they are a main part of an airport's notability. Usually that means small airports. In the case of a huge airport, Heathrow, JFK, Narita, etc, it is notable that they have flights to and from zillions of places, and statistics would be nice, but the minutiae of which actual destinations they serve is not notable. Zerotalk07:19, 11 December 2025 (UTC)Reply
first 3, second 4 We here at Wikipedia should not help people with their itenerary directly. Only include lists if they are actually relevant, and don't use just tables, explain why the route merits a mention. Why are y'all using Wikipedia of all things to check airport destinations? Shouldn't their website or a flight booker be enough? Also some people here have argued with an WP:ILIKEIT argument which is a terrible argument. ~2025-31733-18 (talk) 19:17, 13 December 2025 (UTC)Reply
"I like it" and "I use it" are actually *great* reasons to include information – we're not talking about standalone articles here. I think it is very relevant that Delta Airlines serves a variety of small regional airports from its hub in Atlanta, even if people don't write lengthy news articles about them. Each one of these routes deserve a mention, even if we don't write harder-to-read paragraphs on them, because they connect people and communities. Just because you aren't part of "y'all" here does not mean the rest of us can't learn about transportation networks this way. Clearly you don't understand this topic, because no, the airline's website is not enough, since in many cases they don't have an easy-to-read list or map organized by route. Not to mention that's there's a lot of Wikipedia content that's simple duplication of official website, so it's pretty risible to think that's an excuse to remove it here, with its wikilinks and consistent organization. — Reywas92Talk21:39, 13 December 2025 (UTC)Reply
Wikipedia is not an indiscriminate collection of information. If you really like collections of destinations, go over to WikiTravel and add destination lists. That is the appropriate place for those, not an encyclopedia. If they really deserve a mention, elaborate why, don't just handwave it as automatic. We should prioritize WP:V and WP:N rather than 'useful info' otherwise we aren't an encyclopedia, we would be a guide/database~2025-31733-18 (talk) 08:42, 14 December 2025 (UTC)Reply
And these are verifiable, so WP:V is prioritized. We are not talking about standalone articles, so WP:N is irrelevant. Something being related to the concept of travel does not make it a travel guide or forbidden from inclusion. Wikitravel does not have this because it's not actually relevant as a travel guide. — Reywas92Talk17:05, 14 December 2025 (UTC)Reply
Verifiable? Probably, but most of the destination lists are completely unsourced potential WP:SYNTHs. I find your assertion of destination lists not being part of travel guides while simultaneously saying they are useful because they help you plan trips (which is the purpose of a travel guide btw) preposterous. ~2025-31733-18 (talk) 17:59, 14 December 2025 (UTC)Reply
I will reply here, as an ardent proponent of curtailing these lists - almost all are at least partially sourced with reliable sources, and there are a fair few that are fully and well sourced too. We can't say that most are completely unsourced. And when I say reliable sources here, I mean SIRS sources. However, there is definitely an issue with verifying continuity of a route - they're announced, but then there's nothing to state they continue. Danners430tweaks made18:03, 14 December 2025 (UTC)Reply
Though there's usually a newspaper article when a route is discontinued, it's pretty easy to check Google Flights or Kayak or any number of sources to make sure we haven't missed any changes. -- Beland (talk) 18:44, 14 December 2025 (UTC)Reply
1 or 2. This information has encyclopedic value, and is small enough to include (even if we have to make separate pages for large airports). I have used this information to help plan trips, and also when examining public policy issues. For example, the rules for intrastate vs. interstate routes in the US are different, and this has been a political issue in Texas. There are also important questions in immigration policy and domestic immigration law enforcement which are informed by knowing which countries have flights to specific airports. Changes to this information is always newsworthy enough to make the headlines on our local NPR station, so its value seems to be supported by reliable sources. -- Beland (talk) 00:43, 14 December 2025 (UTC)Reply
1 or 2. As a person who constantly browse articles on Wikipedia, it is quite important for me to visually see data rather than reading long prose that are sometimes not as comprehensive as a list or table (because of painstaking listing of everything in a paragraph type). This is especially true if you are travelling, as articles in airports come in handy in last minute or emergency situations where you need to have accessible, easily understandable data fast. Where this destination lists are not well-sourced, editors should not remove them but instead put appropriate tags, or better yet, find reliable sources and add them. Most often, these list, while within articles are what I would look at first rather than the wordings of the articles itself, if these are the data I was particularly trying to find. This is true not just on airport/destination articles, but on any articles where visual cue is easily reliable than the wordings itself. This is the essence of taxobox or infobox. Jp2593 (talk) 11:58, 14 December 2025 (UTC)Reply
3 or 4 A general overview in prose is good and enclyclopedic info. A list of all destinations is not enclyclopedic. BTW having 5 choices presents some math issues. The "should not have such lists" view is divided between 3 different alternatives. The close should interpret such things. North8000 (talk) 21:36, 15 December 2025 (UTC)Reply
3 or 4 per WP:NOT, per Masem, and per WP:CONSENSUS. WP:NOT guides us to write encyclopedic articles in prose, and discourages directory-style lists and indiscriminate databases. #3 and #4 are the only approaches consistent with WP:NOT. Options 1 and 5 prevent us from reaching a WP:CONSENSUS. I also reject the framing of this RFC that presents #1 as existing policy when WP:NOT is core. Even if you disagree, the most you could say is that we are inconsistent. Shooterwalker (talk) 16:34, 17 December 2025 (UTC)Reply
The existing consensus is that these lists explicitly do not violate WP:NOT You may disagree with that consensus, but that does not mean it does not exist or that it is incorrect. Thryduulf (talk) 16:58, 17 December 2025 (UTC)Reply
You're incorrect, or misunderstanding my point about WP:NOT. It quite literally says:
An article should not be a complete presentation of all possible details, but a summary of accepted knowledge regarding its subject.
Wikipedia is not a directory of everything in the universe that exists or has existed
Wikipedia is not an indiscriminate collection of information. To provide encyclopedic value, data should be put in context with explanations referenced to independent sources.
Which informs our guide on lists, particularly MOS:USEPROSE. Once again, you can disagree with the application of Wikipedia policy, but at most that means Wikipedia is inconsistent. You can't declare your own consensus when WP:NOT is very clear here. Shooterwalker (talk) 17:20, 17 December 2025 (UTC)Reply
And this was already extensively discussed at Wikipedia talk:What Wikipedia is not, which found clear consensus that this was not a NOT violation. This is not "[his] own consensus", and it's simply incorrect to assert that WP:NOT is clear here. A simple list of destinations is not "all possible details" nor is it indiscriminate. There would need to be a new clear consensus to delete this longstanding content – the fact that some people disagree with practice does not mean that a supposed compromose position that deletes only some of the content is the actual consensus. — Reywas92Talk19:00, 17 December 2025 (UTC)Reply
Option 4 As an encyclopedia, we should use prose to describe the significance of the article subject (in this case, the airport), and that includes the routes that fly into and out of it. A big chart or table or list doesn't explain much about the airport. It doesn't indicate that it is a hub for X airline, or that it is the major hub serving all of X area, or that it is a regional airport mostly sending and recieving flights from Y hub. It doesn't explain that the addition of the A to B route in 1987 led to an economic boom, or the elimination of the C to D route in 2013 caused a local recession. Routes are ephermal, and presenting them in a table format can cause headaches as editors are constantly needing to update the table to keep it current, and it also leads to the loss of significant information as major route changes have significant real world impacts which are not described in the article, instead vanishing from the article just as they vanished in real life. We do our readers a disservice by presenting information in this format. ~ ONUnicorn(Talk|Contribs)problem solving17:45, 17 December 2025 (UTC)Reply
1 or 2 These lists are part of the topic and are what most users would use for, most people depend on these lists because flying to somewhere is the point for airports, and also per SportingFlyer and Amakuru. Metrosfan (talk) 11:20, 8 December 2025 (UTC)Reply
somewhere between4 and 5 -- Something like "Squortly Airport provides flights to cities in 83 countries" is valid. In the Kearney Regional Airport example, all that needs to be said is that it only provides service to Denver. --User:Khajidha (talk) (contributions) 15:18, 8 December 2025 (UTC)Reply
Not 5. Small commercial airports with only one possible destination should mention this, since it's an important aspect of the airport that's routinely familiar to locals and significant to travellers from elsewhere. My previous city's airport has flown only to one other airport for a long time, and this situation has routinely occupied the attention of city officials and other local residents; the mere fact of a second airline with additional destinations is a significant development that deserves some mention in the history section, e.g. once it happens, "For decades [obviously this is vague, but I don't know when previous services ended], Lynchburg's only commercial service was American Airlines flights to Charlotte, but United Airlines added flights to DC and Chicago in 2026". It would be preposterous to enact a 100% ban on any references to this fact. Or, consider a very different airport, Nadi International Airport in Fiji. As the main hub for Fiji Airways, it has service to Australia, New Zealand, the US, and various other major countries, whilst it has few domestic flights because that's the role of Nausori International Airport elsewhere in the country; we ought to be able to mention some of the major destinations (e.g. Melbourne, Auckland, and Los Angeles), and we should note that passengers can fly from Nadi to Nausori if that's the case. (When I encounter big Option 1 tables, and an expected destination is missing, I'm always uncertain if the table is incomplete or if that destination isn't really an option.) And it's quite reasonable for the Funafuti International Airport article to say Fiji Airways operates between Suva, Nadi and Funafuti with a citation to the website of the government of Tuvalu. Outright prohibiting any mentions of these facts, regardless of sourcing, would be detrimental to the encyclopedia. Nyttend (talk) 18:53, 8 December 2025 (UTC)Reply
3 or 4 The massive tables are very hard to keep accurate, changes happen quite often for auxiliary destinations with less than daily service especially in growing areas or for seasonal flights. A narrative description keeps the information that fits what Wikipedia can provide: for small airports, it could be as simple as "Frog Town Airport only has daily service to New Frog City", for medium airports it could expand to say "New Frog City Airport has seasonal service to numerous Warm Coast destinations", and further expansion for the massive hubs of the world. If you need a complete up to the minute guide of flight destinations, there are other websites for this, as well as any booking site you can muster. And seriously people, option 5 is daft nonsense and you should not be distracted by it. Omnifalcon (talk) 04:05, 9 December 2025 (UTC)Reply
It's a work in progress since in the past, route-specific sources were typically removed after the route started since there would often be a general timetable source. This isn't particularly difficult to verify. — Reywas92Talk14:29, 9 December 2025 (UTC)Reply
Option 3 or 4. The attempts at comprehensive lists have historically been magnets for poor sourcing and misbehavior. Prose summaries that detail the key information without trying to be complete, up-to-the-minute lists will still provide most of the useful information while being better able to meet WP:V. ModernDayTrilobite (talk • contribs) 15:28, 9 December 2025 (UTC)Reply
4, 3, or 5, but I think a better RfC option would be "secondary, independent sources for each entry and/or the list as a whole are required to include an airline destination list". If a full listing is somehow covered in SIRS media, then we shouldn't necessarily prohibit it from being in the article. JoelleJay (talk) 17:03, 9 December 2025 (UTC)Reply
0 - none of these options are the right answer. IMO, the closest the community got to the "right answer" was the 2023 RFC, which resulted in consensus that airlines and destination tables may only be included in articles when independent, reliable, secondary sources demonstrate they meet WP:DUE. Closest because it's actually WP:ASPECT, not WP:DUE, that is relevant. But anyway, some routes are significant WP:ASPECTs of airports, and some routes are not. For example, there are airline routes that are independently notable, like Hong Kong-Taipei route, or the Island Hopper; those routes should of course be mentioned in the articles about the airports along those routes. Even if a route isn't notable, it may still be a significant WP:ASPECT of the airport. Articles about airports should mention routes that are significant WP:ASPECTs of the airport according to independent, reliable, secondary sources; it should not list all routes, or no routes. Whether that information takes the format of prose, or a table, or a subpage, would depend, article by article, on how many significant WP:ASPECT routes there are. (Probably not many though.) But if the question is "list all routes" or "list no routes," the answer to both is "no." List some routes, the significant WP:ASPECT routes, and list them in whatever format makes sense for the particular content in question. Levivich (talk) 21:41, 9 December 2025 (UTC)Reply
Yes, I don't understand why we are rehashing this as "should airport articles have destination tables or not" rather than "destination tables should only be included when supported by SIRS and BALASP". The RfC is treating this as essentially a "MoS for airport articles" issue rather than addressing the actual problem. I'm now regretting not getting more involved in the pre-RfC discussion... JoelleJay (talk) 17:43, 10 December 2025 (UTC)Reply
The vast majority of airline routes from airports can be cited in one form or another and requiring significant coverage about the route itself in the article about the airport is not consistent with how any other topic on the project is treated. Take a look at the FA George Tucker (author)#Works for example. There's a list there which (a) has numerous entries without Wikipedia articles, suggesting those works themselves aren't notable; and (b) the list as a whole is uncited, meaning this list is something put together by Wikipedians themselves rather than assembled as a whole block somewhere else; the citations are simply the fact that those books exist, and their ISBNs are given so you can find them. WP:LISTN might imply that we can't show any lists that aren't cited in full in an external source, but vast reams of the project, including featured content, don't follow such a rule and in general it's taken as read that LISTN only applies to standalone lists (as its wording says) and not to lists within other articles. — Amakuru (talk) 18:42, 11 December 2025 (UTC)Reply
requiring significant coverage about the route itself in the article about the airport is not consistent with how any other topic on the project is treated - well, if you use the term significant coverage, referencing WP:SIGCOV, that's true--SIGCOV is about notability, not about what we include in articles. However, I didn't say "significant coverage," and neither did JJ. We're both pointing to WP:BALASP (aka WP:ASPECT). That's a section of WP:NPOV that is how every other topic on the project is treated. If the only source for a route is the airport's own website, and none of the other sources about the airport mention the route (particularly independent secondary reliable sources), then the route probably isn't going to meet the WP:BALASP test (An article should not give undue weight to minor aspects of its subject ...) and shouldn't be included in the Wikipedia article about the airport. And I totally reject any kind of analogy between an artist's works and an airport's destinations. A closer analogy might be a company and its products, and we don't list all the products in company articles. (Or at least we shouldn't; some companies, like Microsoft, have a veritable product catalogue on Wikipedia.) Levivich (talk) 22:24, 14 December 2025 (UTC)Reply
4, or 5 or 3 - There are too many problems with destination lists, mainly that they change frequently, and that there are frequent disputes about the acceptability of the sources. The way to minimize disputes about lists of airline destinations is to avoid having lists of airline destinations. Robert McClenon (talk) 06:49, 10 December 2025 (UTC)Reply
Because a reader is better served by readable prose rather than table stuff. Especially as a single entry table does not need a table. Tabular information is presented in that format to allow a reader to make quick connections between different data. They should not be used merely for presentation purposes and they present user accessibility issues when used. Here there is no different data to connect. The only possible purpose of a table is obviated by the fact it is a single entry. Sirfurboy🏄 (talk) 11:42, 10 December 2025 (UTC)Reply
2 because we don't want to overwhelm articles, but I don't see how that's any different from how we treat long articles now, so I'd be fine with option 1 as well. I believe destination lists are a point of interest for our readers, and I'm surprised to see people arguing that the need to update them is a problem—collaboratively updating things is a core part of why Wikipedia is a top-ten website. In addition, the other options are unpalatable. With option 3 or 4, I can't see how something like the Heathrow Airport destinations example could be covered in prose in a way that's actually easier for readers to understand. The tables are just far more easily parsed, especially for people conditioned to short-form content. Option 5 is completely unworkable.I was also influenced by Thryduulf's well-argued !vote above, WhatamIdoing's very cogent points throughout this RfC, and Andrew Davidson's point below about why airports exist: "Destinations are not miscellaneous; they are the fundamental raison d'etre of an airport." (Admittedly a few people have made a similar point, but this was the most quotable.) Ed[talk][OMT]18:31, 11 December 2025 (UTC)Reply
What about situations where the entire table is only supported by primary, non-independent sources? If a complete list of destinations is so important to understanding the airport, why wouldn't this be reflected in SIRS sources? JoelleJay (talk) 17:42, 13 December 2025 (UTC)Reply
My preference is either 2 or 3. Regarding option 2, I think that a hatnote and prose summary would be better; having "smaller" destination tables sounds like it would be susceptible to mission creep. For anyone who hasn't read the saga over at Village pump (policy)/Airport destination lists (understandable—it's enormous) I'll copy my main points over:
being presented with a table full of, essentially, raw data is the opposite what an encyclopaedia should be doing, which is summarising the information.
I guarantee that the information in the tables can be summarised in prose format, because I do exactly that almost every time I write a technical report.
Some articles (Darwin International Airport for example) already have most of that info in prose form anyway, it's just been put in the History section instead of the Airports and destinations section.
Final note: one of my problems with the tables is that when I see the heading "Airlines and destinations" I expect to find (1) the airlines that service the airport, and (2) the destinations that someone could travel to. Tabulating the information into "Airline A goes to X, Y, and Z. Airline B goes to X and Y. Airline C goes to X, Y, and Z. Airline D goes to X. Airline E … etc etc" instead of "Airlines A, B, C, and D service the airport" and "The destinations are X, Y, and Z" is just annoying to read. (Me: Okay, okay! You can fly from the airport to destination X, I got that the first time.) In short, there's a lot of repeated information, and it feels really inefficient. ―Tosca-the-engineer (talk) 13:34, 13 December 2025 (UTC)Reply
For one, it's much easier to collate and track the information when it's organized by airline and destination together, and two, that can show the significance of a route if multiple airlines serve it, as well as how airlines use the airport for different types of flights. It's simply not true that most of the information at even Darwin International Airport is already in prose form. The History section mentions some international routes, the ones most likely to have recent news coverage, but it doesn't mention the larger number of shorter regional routes. It's quite relevant that the airport serves these small communities across northern Australia even if editors haven't included that in the history. I can't overstate how much of a nightmare implementation would be if this were closed as option 3 as some sort of compromise against the truly absurd 4 and 5 – we're going to see huge amounts of content simply deleted without adequate summaries having been written. Just because a summary could be written doesn't mean they will be (not to mention the rest of your report is still there). — Reywas92Talk17:19, 14 December 2025 (UTC)Reply
Option 2 or option 3 would get my vote. I think that this information is matters more on the articles for smaller airports, as they are often notable because of the regions and destinations that they serve (maintained either in prose or as a list, depending on what makes sense for the editors working on the article). The lists are very tedious on the articles of larger airports, but I would be fine with the tediousness being kept on their own pages. --Gurkubondinn (talk)11:32, 17 December 2025 (UTC)Reply
I hope editors don't mind, but I've added bullets to our comments - something I should have done myself when I first added my own vote. Feel free to revert if you disagree with their use :-)Also, I've notified (or rather am in the process of notifying) those editors that were involved in the original VPP discussion and the closed RfC at WP:NOT. Danners430tweaks made21:03, 7 December 2025 (UTC)Reply
So, Amakuru, you're openly acknowledging that you're using and supporting these lists as a itinerary and travel guide, in specific opposition to WP:NOTGUIDE? I'm saying they're unencyclopedic because they are explicitly, directly spelled out to be against policy. SilverserenC21:12, 7 December 2025 (UTC)Reply
Did you miss the part where I said "as an aside"? Yes, (also as an aside) I'm pissed off that a useful feature I use all the time is going to be ditched because a bunch of Wikpedians such as yourself have nothing better to do than moan about how you think they're travel guide fodder. But that isn't the reason why I !voted the way I did. I did so because knowing which destinations an airport can be reached from is vital to understanding that airport in its totality. In the same way that a football team might have a table listing past championships it's won or an author might have a bibliography table telling you which books they wrote. — Amakuru (talk) 21:18, 7 December 2025 (UTC)Reply
And that information is much better represented in prose both in context and in relation to the airport itself. Just having a gigantic list of destinations doesn't actually serve readers to understand what that means in relation to the airport. Having it instead presented as a generalized overview throughout the history of the airport serves our readers much better for their understanding of said airport's past and current status. SilverserenC21:22, 7 December 2025 (UTC)Reply
I'm on the fence about whether it's better to replace it with two sentences or to leave it alone, but I don't consider it to be inherently problematic. WhatamIdoing (talk) 21:26, 7 December 2025 (UTC)Reply
Seems easy enough to explain the content in a paragraph of prose. No reason why that wouldn't be simple enough to do? And obviously the issue is the many much, much longer lists. SilverserenC21:33, 7 December 2025 (UTC)Reply
Prose is far better here particularly for a small regional airport. "Durango is served by American and United Airlines, connecting to DFW, Denver. Phoenix, and seasonal flights to Houston" Masem (t) 21:33, 7 December 2025 (UTC)Reply
This is contradictory to your vote above. What if one of these airlines changes their routes on a whim? I would rather see a consistent format of organized infomation rather than creating inconsistency between large and small airports. — Reywas92Talk15:40, 8 December 2025 (UTC)Reply
No it's not. The sourcing given appears to be all independent, third party sources so fully covering the options from a small regional airport makes sense. If a route used to be served but now gone, as documented by sources, that can be added too. Where the problem is more apparent is large airports where there are dozens of possible destinations. With a larger airport it will probably discuss the possible destinations at the summary level grouped by airline. Basically we look to sources to determine where the summary will be. Masem (t) 05:20, 9 December 2025 (UTC)Reply
I said that too in my vote. I generally think these lists are ok, but I wouldn't stand in the way of deleting the very largest of them (the top 20, maybe), the ones that change the most and are hardest to source properly. JustARandomSquid (talk) 22:00, 8 December 2025 (UTC)Reply
@Silver seren, that's a weird way to express your disagreement. It sounds like you're claiming that NOTGUIDE is telling readers (including readers who edit) that they're not supposed to be "using" Wikipedia for whatever purpose they want. WhatamIdoing (talk) 21:24, 7 December 2025 (UTC)Reply
I'm saying that, per policy, the lists are unencyclopedic. And statements of them being necessary because they're used as travel guides just exemplifies the point that they were unencyclopedic. SilverserenC21:33, 7 December 2025 (UTC)Reply
WP:NOTGUIDE says an article on Paris should mention landmarks, such as the Eiffel Tower and the Louvre, but not the telephone numbers or street addresses of the "best" restaurants, nor the current price of a café au lait on the Champs-Élysées. For an airport, the destinations that it serves seem like landmark-level info. The policy is against finer detail such as the price and quality of its coffee. If it's long-standing practice to list destinations then this is clearly acceptable information in this context. Andrew🐉(talk) 21:29, 7 December 2025 (UTC)Reply
By that same argument, would you claim WP:NOTTVGUIDE isn't meant to apply to lists of all shows every day, all events ever held, and for other subjects, all products down to every version? The issue here discussed in both sections and in NOT as a whole is that arguments of every single destination being major don't hold water. Our lists are meant to be general overviews that are largely stable information. Occasional changes to what material is included happen, but they shouldn't be on a daily or weekly basis. A list that is inherently meant to be covering material that will be very constantly and forever changing (and not simply in the practice of occasionally adding a new line/entry such as a new year's result) are unencyclopedic. That is not the sort of information Wikipedia is meant to be covering. SilverserenC21:40, 7 December 2025 (UTC)Reply
The destinations served by a major airport like Heathrow will be fairly stable -- equivalent places like Paris are always going to be in the list. Broadcast TV schedules seem more ephemeral and so we don't tend to do them. But now that streaming is becoming more dominant, notice that we have lots of Lists of television series by streaming service. These lists will keep expanding as new programming is added but so it goes. Andrew🐉(talk) 22:12, 7 December 2025 (UTC)Reply
I'm OK with the thought a list of 100 might well have an update somewhere in it, even though individually each route is seldom created or removed. That situation seems fairly normal for any list, and the vast majority of airports are small so in general it's not an issue. And any cites for an airport or other transport hub could have the issue that WP:V cites are seldom available so may usually be a bit old. Caveat I recently was at a BLP mentioning the person was 'currently studying for Phd" with a cite from 2014, so my perspective on where 'old' is may be skewed. ;-) Cheers Markbassett (talk) 05:26, 9 December 2025 (UTC)Reply
Andrew, I believe that back in the day, some of air-travel-related lists had information about flight numbers, airport call signs, etc. In that sense, we've already removed some of the "street address" information. WhatamIdoing (talk) 22:40, 7 December 2025 (UTC)Reply
Triptothecottage, WP:TRIVIA doesn't mean what you think. Its nutshell says An article should not contain a list of miscellaneous information. It is better to present things in an organized way. Destinations are not miscellaneous; they are the fundamental raison d'etre of an airport. And putting the information in a systematic table is presenting this in an organized way as the guideline recommends. Andrew🐉(talk) 21:46, 7 December 2025 (UTC)Reply
it should be mentioned that a major problem with these lists is the use of press releases or unreliable sources like Aero route to justify inclusion. Large chunks of data sourced only to primary sources are not appropriate to WP. Masem (t) 22:06, 7 December 2025 (UTC)Reply
The irony is, the last RfC on this topic came to the conclusion that routes should only be included when sourced by reliable, secondary and independent sources - that’s what’s listed in the WikiProject style guide at WP:AIRPORT-CONTENT… but this consensus seems to be ignored frequently. The only people I’ve seen enforce it are @VenFlyer98 and @The BannerDanners430tweaks made22:11, 7 December 2025 (UTC)Reply
I feel like in places where the lists are long and deemed impossible to maintain using reliable secondary sources they should be able to be removed, and this is coming from someone who voted for 2. JustARandomSquid (talk) 22:18, 7 December 2025 (UTC)Reply
Good call. I suppose I did mean independent in this particular case. To be fair, I feel like there's a lot of confusion on primary/secondary and the independence of sources in general, but yeah, my apologies for propagating it. JustARandomSquid (talk) 22:46, 7 December 2025 (UTC)Reply
Totally agree with you about the terminology being confusing. So I'd guess then that you'd prefer a couple of local newspaper articles, rather than, e.g., the airport's own website. For US airports, these seems to be generally available. I assume the same is true for Canada and Europe. Outside that area, I've less experience, but it seems like something that should be available at least most of the time. WhatamIdoing (talk) 22:53, 7 December 2025 (UTC)Reply
An entire article sourced to a single primary source isn't great, but single sections sourced to a variety of primary and secondary sources (or independent and non-independent sources since people don't know the difference) are perfectly fine. This is not controversial or objectionable information, and primary sources are not going to be unreliable or misleading for such simple facts. — Reywas92Talk15:11, 8 December 2025 (UTC)Reply
For some of the larger lists that are out there, the bulk of the sourcing is primary, and that makes those lists a IINFO problem, it's comparable to Trivia and why we ask for summarizing to independent third party sources to avoid indiscriminate inclusion Masem (t) 05:23, 9 December 2025 (UTC)Reply
Exactly. I lean towards option 3, but only for the very largest of tables, specifically those where the majority can't easily be sourced to reliable third-party sources. JustARandomSquid (talk) 08:09, 9 December 2025 (UTC)Reply
I wonder, if we went to the work of going through one of the larger lists, how many of those we'd be able to cite to, say, a newspaper article. I just added several independent sources to the table in Heathrow Airport. I looked up two airlines in Wikipedia:The Wikipedia Library and found multiple independent reliable sources without any trouble. I'm not finding any evidence that these can't be easily sourced to reliable, third-party sources – if a WP:VOLUNTEER puts in the time and effort.
Aficionados may wish to particularly seek out the "Key Routes" feature (the headline is usually "A selection of 50 new routes starting in [Month Year]") in Air Transport World, if the desire is specifically to document when an airline begins providing service to a new airport (might be handy, e.g., for documenting the start date of a historical route). WhatamIdoing (talk) 17:56, 9 December 2025 (UTC)Reply
In the case of air route lines, the bulk of the sources are primary (related to the airline itself) or non-reliable like Aeroroutes. A primary source that lacks independence is not good to use, so that basically means we are looking towards how secondary or tertiary independent sources discuss air routes from an airport.
I would also be extremely wary of using air travel trade magazines unless we know the airlines or airports do not pay at all to have their content featured in there. That gets to the NCORP problem in regards to sourcing only via WP:SIRS (not notability). I'm absolutely certain that if we allowed any and all trade magazines to be used many more of these routes could be sourced, but how much of that was paid publicity by the airline? Masem (t) 20:32, 9 December 2025 (UTC)Reply
Once again, Wikipedia:Secondary does not mean independent. When you write things like the sources are primary (related to the airline itself), you are wrong. Sources "related to the airline itself" are non-independent. Non-independent sources can be primary or secondary (or even tertiary).
A primary source that lacks independence is not good to use, but a primary source that has independence is probably fine. If you're still struggling with this, look at the table in Wikipedia:Party and person#Combinatorics. You're talking about first-party primary sources ("Scientist publishes an original report about their experiments") and saying that the problems with first-party primary sources are proof that we can't use third-party primary sources – a category that includes quite a lot of what you'll find in any ordinary daily newspaper.
Just like newspapers run the gamut from newspapers of record to grocery store tabloids, trade rags run the gamut from excellent sources to barely disguised advertisements. Editors should use reliable sources, including trade magazines that are reliable sources. In the case of the one I recommended here, the magazine is cited in scholarly sources and books. I think that's a solid indication that this particular trade magazine is a reliable source. WhatamIdoing (talk) 20:45, 9 December 2025 (UTC)Reply
When you're talking about the bulk of the sources, are you talking about what sources could be cited (similar to WP:NEXIST), or are you talking only about the ones that have already been cited? Do you think we should make a content decision based on whether the current citation is bad, or based on what better sources say?
For example, the first row in Heathrow Airport#Airlines and destinations previously had only a citation to a random website. I added citations to two notable magazines. Was that row unencyclopedic content originally, and the addition of better citations magically changed the nature of the content from unencyclopedic to encyclopedic? Or was it actually encyclopedic content all along, and we just needed someone to spend 10 minutes finding and typing out the citations? Or is it still unencyclopedic content, and all of this about poor sources is just a red herring? WhatamIdoing (talk) 20:54, 9 December 2025 (UTC)Reply
Because a small list with just a few destinations sourced to primary sources is a relatively small part of the article, that isn't likely to change very often, and thus doesn't cause a large amount of information in an article to be not sourced to independent secondary sources. JustARandomSquid (talk) 20:49, 9 December 2025 (UTC)Reply
Am I the only one who doesn't like the focus on tables? I personally don't care how the information is presented, I care that it's readable, I care that it's sourced, and I care that the information has enough secondary sourcing to pass the 10 year test. (To put this against the example I used in the last RFC - decades after the fact, I care that Ted Stevens International Airport connected America, Europe, and Asia. I care that Iliamna Airport had flights connecting it to Anchorage, and I will care when those flights are no longer offered. I won't care that you can fly from Ted Stevens to Los Angeles on one of several flights - and other editors don't care either, given that this information is removed from the article as soon as the flight is discontinued.) GreenLipstickLesbian💌🧸22:15, 7 December 2025 (UTC)Reply
How do secondary (and yes, I do actually mean secondary) sources actually cover airline routes? From a quick search, my impression is that it is more often done by airline instead of by airport. Do these lists actually meet NLIST and/or have any selection criteria besides "all of them we can find"? Alpha3031 (t • c) 00:47, 8 December 2025 (UTC)Reply
NLIST is the guideline for whether a list warrants a stand-alone page, not whether or not a list can be included on an article, see WP:NNC. A list could not "meet NLIST" and still be permissible for inclusion within an article, which is what option 1 permits. Katzrockso (talk) 00:59, 8 December 2025 (UTC)Reply
I am aware there are other criteria for determining the appropriateness of embedded lists. I don't think I've said otherwise but I will take that under advisement. I still believe reference to sources is helpful. Alpha3031 (t • c) 08:46, 9 December 2025 (UTC)Reply
It's unclear what relevance NLIST (a part of the notability guideline) has to content with an article, given that WP:NNC specifically forecloses such a connection. "[R]eference to sources" may be helpful, but that has nothing to do with NLIST. That is what I was commenting on. Katzrockso (talk) 09:16, 9 December 2025 (UTC)Reply
I strongly disagree that NNC forecloses a connection between sources used for notability and article content. They (the sources that are in-depth and seccondary) are often, for example, the best sources for determining due weight. Alpha3031 (t • c) 18:00, 10 December 2025 (UTC)Reply
It's variable - for some airports, you can find coverage of routes (at least broadly) & their impact in academic sources. [17][18][19][20] As to whether that's enough for NLIST - I'm a bit conservative when it comes to spinouts and like WP:NOPAGE arguments, but I'm willing to bet that a collection of destinations (historic or otherwise) of at least a few significant airports could meet that threshold. I don't think most airports do- but most airports I'm familiar with don't have enough regularly scheduled flights that including the one or two that are would inherently be a WEIGHT or DUE issue. GreenLipstickLesbian💌🧸01:26, 8 December 2025 (UTC)Reply
I know this isn't within the scope of the RfC, but I saw this in the collapsed box and wanted to make a comment. - any individual routes that are specifically listed in a summary, should be sourced with reliable secondary sources, sufficient to satisfy WP:NOTABILITY. I am not sure if I am reading this correctly, but I believe this seems to say that the summary in prose would require the content to "satisfy notability"? If so, that is a misunderstanding as notability does not apply to content within articles. Katzrockso (talk) 00:56, 8 December 2025 (UTC)Reply
Just adding in my thoughts here. If anyone has seen me around editing, you'd know that more than 90% of my edits or so are airport lists. I'm kind of for any of the options in this RfC, the main issue with the lists is really the sourcing. With the recommendation that sources use independent, secondary sources, it can be hard to find sources for certain routes. This results in a lot of edits being reverted or unsourced. If we allow sources directly from the airline about a route (whether that's their schedule website or a news release from the airline), that would solve a lot of the sourcing issues, and I do think it meets WP:RSPRIMARY enough. If a secondary source is available, great, we can replace the primary one with it. If not though, using them to show that an airline is flying from A to B or launching a new route on a certain day isn't original research as long as the source outright states the route/date. This could significantly cut down on the amount of unsourced routes and reverts that happen. As someone who edits a lot of these lists the main issues I have with them is the sourcing and having to constantly monitor since content is added/removed all the time from them (specifically for bigger airports). Just my 2 cents. (VenFlyer98 (talk) 03:00, 8 December 2025 (UTC))Reply
I think that examples help, so hopefully that RFC can be drafted after this one is done and dusted, with real examples of summaries/lists/tables. It will be easier for editors to look at "United Airlines flies from Durango–La Plata County Airport to Denver[newspaper article]" or "* United Airlines – Denver International Airport[flight tracker]" and say whether it's okay or not, than to ask abstractly whether sources should provide "SIGCOV IRS" or "ordinary rules apply" or other general categories. WhatamIdoing (talk) 05:25, 8 December 2025 (UTC)Reply
The previous discussion that was closed as to required secondary sources was an utter mess, with many people not understanding what "secondary" means and a closure that was not in the scope of the question. I agree that artificially constraining the sources that can be used, unlike nearly any other content in the project, for very straightforward, uncontroversial, unbiased facts is completely unnecessary. — Reywas92Talk15:15, 8 December 2025 (UTC)Reply
User:Reywas92 thank you and User:VenFlyer98, there does seem to be a confusion with 'independent' or 'second-party' because route info might come from the airline, airport, newspaper, some government flight plan records or something else but just a route from a to b is not 'secondary' in nature that WP:PSTS says A secondary source provides thought and reflection based on primary sources. Cheers Markbassett (talk) 21:23, 8 December 2025 (UTC)Reply
The thing is, we're just trying to present facts, in the same way a sports team would present an up to date list of players. We don't need detailed analysis of why an airline started a specific route, we just need the fact to be correct and verifiable! SportingFlyerT·C23:13, 8 December 2025 (UTC)Reply
WP:PSTS actually says A primary source may be used on Wikipedia only to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge. (emphasis in original). This is exactly what these routes are: straightforward, descriptive statements of fact. Thryduulf (talk) 23:54, 8 December 2025 (UTC)Reply
@Reywas92: The idea of having the two sections is so that discussions are kept to this discussion section, and the above Survey section is for editors to place their votes and explain why. Can we please keep the discussions to this section? Danners430tweaks made14:58, 8 December 2025 (UTC)Reply
WP:NOTGUIDE does not apply -- it says an article on Paris should mention landmarks, such as the Eiffel Tower and the Louvre, but not the telephone numbers or street addresses of the "best" restaurants, nor the current price of a café au lait on the Champs-Élysées., and destinations as notable points - whether shown as a list or map -- are a common and necessary part of meaningful content on topics. That someone uses it during travel does not make it a Travel guide, because it does not provide recommendations at the location and is not providing the table as a list of things to do which is what a travel guide is. Cheers Markbassett (talk) 20:23, 8 December 2025 (UTC)Reply
WP:OR and WP:SYNTH do not apply. A collection of routes without any remarks does not do what WP:OR says original research means material—such as facts, allegations, and ideas—for which no reliable, published source exists. Nor does it do what WP:SYNTH says Do not combine material from multiple sources to state or imply a conclusion not explicitly stated by any of the sources. Cheers Markbassett (talk) 20:44, 8 December 2025 (UTC)Reply
OR absolutely applies. Per policy: Do not base an entire article on primary sources, and be cautious about basing large passages on them. If secondary, independent sources are not discussing these wide swaths of content, the content is also not BALASP. JoelleJay (talk) 17:15, 9 December 2025 (UTC)Reply
Except nobody is basing entire articles on primary sources, and the instruction to "be cautious" regarding large passages on primary sources is very far from a prohibition. With only a small number of exceptions, destination lists are not a large part of most articles. Also if multiple, very large RFCs about inclusion is not "being cautious" then I don't know what is. So, no, OR and SYNTH are not relevant. Thryduulf (talk) 17:23, 9 December 2025 (UTC)Reply
Even if we stipulated, for the sake of argument, that "be cautious" meant the same thing as "is absolutely forbidden", the entire table at Durango–La Plata County Airport#Airlines and destinations, including the column headings, contains a total of 21 words. Nobody is likely to mistake 21 words for being a "large passage".
I think it's confusing to have this rule ("Do not base an entire article...") in the "Original research" article. Relying too heavily on primary sources doesn't mean that you're making stuff up that can't be found in any source, particularly when you are repeating only very simple facts. I think that WP:PSTS needs to become its own, separate {{policy}}. WhatamIdoing (talk) 18:05, 9 December 2025 (UTC)Reply
If the only coverage a (sub)topic receives is what non-independent and/or primary sources say about it, it is unlikely to be worthy of inclusion (especially beyond a couple sentences) in the first place. JoelleJay (talk) 18:12, 9 December 2025 (UTC)Reply
I said it's unlikely, which I believe is in line with the cautions already present in PSTS. Birthdates also aren't going to take up more than a couple sentences. JoelleJay (talk) 17:46, 10 December 2025 (UTC)Reply
Yes they are? Plenty of these lists are standalone articles sourced entirely to primary and non-independent sources. And RfCs on whether a given list fails NOT does not mean there is consensus that its content is inherently encyclopedic or that it is exempt from our notability and OR requirements. Indeed, we had a "very large RfC" that explicitly determined that these lists DO need secondary sourcing. JoelleJay (talk) 18:09, 9 December 2025 (UTC)Reply
Is there any difference between these lists and a list of products sold in a shop? The list of products is easily verifiable on the shop's website, it's helpful to people coming to Wikipedia to look for that information and selling products is the shop's raison d'etre. ~2025-39432-75 (talk) 12:41, 9 December 2025 (UTC)Reply
And I've kept the TA active because the question is genuine and not rhetorical. Do people say "I'm going to this restaurant later, so I'll look up what meals they offer in an encyclopaedia" like they do with airports? If not, how do airports differ from shops or restaurants? Sorry if this has been answered before; I've read through this discussion and some related ones in the past, but not everything on the topic. ~2025-39432-75 (talk) 14:27, 9 December 2025 (UTC)Reply
I'm not sure that's the best way to understand this information. First, yes, a restaurant article should name anything that the restaurant is known/used for, which would include a famous dish. You could legitimately look up a notable, not-so-famous restaurant with an ambiguous name (e.g., Sci-Fi Dine-In Theater Restaurant or Florence's Restaurant) and expect to find information about the kind of food they serve.
But airport connections matter because they have economic effects on the surrounding community. A restaurant can sell hamburgers or burritos or stir-fry, and their choice largely affects the restaurant's own success. A regional airport that connects to several major hubs instead of to just one airport, or that has connections going in every direction instead of just in one direction, is more effective at bringing in business.
For example, we've used Kearney Regional Airport as an example in these discussions (because it appears to be the airport closest to the geographic center of the US). Right now, if you're at Kearney, you have one possible flight destination, which is Denver. Next year, they'll add service to Chicago. Who is pushing for this? The City of Kearney (i.e., not the airline). Why has the city been pushing for it? The city "hopes the renewed service will boost the Kearney Regional Airport and the surrounding area...put us on the map as a place that people can live, work, play right here in central Nebraska". In other words, this is about direct and indirect economic benefits for the whole region.
This example is true for many smaller airports in other countries as well. Routes for small airports on island nations such as Miangas Airport or Ramata Airport is very notable to the airport itself. Those routes are literally the lifeline of the airport itself and the surrounding areas. Those routes are likely be pushed by their respective governments, not just made because they are profitable. The completeness of the route may be less important on big airports but it is absolutely critical for smaller airports. ✠ SunDawn ✠Contact me!23:30, 9 December 2025 (UTC)Reply
But if these routes truly are important to those airports, that would be reflected in SIRS (otherwise the claim would be unverifiable for BALASP purposes). JoelleJay (talk) 17:49, 10 December 2025 (UTC)Reply
@Chalst As the commenter is using a temporary account, all that shows is that this is the first edit they've made to Wikipedia (without logging in) using that browser, on that computer, since cookies were last deleted (and it's not uncommon for this to happen automatically when someone logs off a shared computer) or 30 days ago (whichever is the most recent). Thryduulf (talk) 15:00, 9 December 2025 (UTC)Reply
In a parallel dimension somewhere someone is defending their listing of all the different varieties of TimBits on WP because "it doesn't include the pricing information", as if that makes anything any better. FOARP (talk) 14:01, 17 December 2025 (UTC)Reply
@Rosbif73: (replying to your reply to Thryduulf in the Survey section) The sourcing of these tables is very variable. There are absolutely exceedingly well sourced articles, especially many US airports. However, there are even "Western" airports where sourcing leaves a lot to be desired... the perfect example is Gatwick Airport - it took a draconian (as some editors put it) stripping of all unsourced content [21] to prompt editors to start adding reliable sources, with the end result that the table, while still (I believe) incomplete, is now fully sourced. Even now however there are a large number of Better Source Needed tags. The worst articles I've seen are those in non-English speaking countries (which is understandable given this is the English Wikipedia) - again, there are many very well sourced tables, but there are also some which are very poor. I think this really is the crux of the issue - none of this would ever have reared its head if all the tables were well sourced and maintained... but there are many which simply aren't. Many articles, I appear to be the only editor regularly reverting unsourced additions. Danners430tweaks made13:27, 9 December 2025 (UTC)Reply
Agree entirely: while there are indeed some airports with destination lists that are complete, up to date and properly sourced, there are a fair number more that are up to date but poorly sourced, a few that used to be well sourced but are now out of date, and a host of others that are neither up to date nor properly sourced.
But even if the vast majority were complete, up to date and properly sourced, I still have my doubts that they would be truly encyclopedic. The tables purport to be a snapshot of destinations served at a given date (generally recent but unspecified), yet the actual destinations vary over time. How can that snapshot pass the WP:10YEARTEST? Rosbif73 (talk) 14:34, 9 December 2025 (UTC)Reply
Yes, I wholeheartedly agree - this is why I voted for 3 or 4 (or potentially Blueboar's alternative solution) - I personally disagree with the use of these lists, Gatwick Airport is to me a prime example of why. I know a lot of folks disagree, hence the attempt to keep the RfC neutral though! Danners430tweaks made14:39, 9 December 2025 (UTC)Reply
Recentism is a red herring though, because there are other areas of the website which we update to be current, especially lists of players on sports teams. Someone reading this article in 10 years will absolutely not be confused - heck there are soccer teams with squads which haven't been updated in awhile but they have a date of the last update, which at least lets the reader know the information is correct, but stagnant. SportingFlyerT·C17:25, 9 December 2025 (UTC)Reply
The question is not whether all these tables are properly sourced - if that were the case then we'd need to delete literally thousands (at minimum) of lists, almost all of which exist uncontroversially and many with explicit consensus. Nor is the question whether these lists are maintained (which the majority of them are). The question is whether these are encyclopaedic, sourceable and maintainable, and per the evidence and opinions I and others have presented elsewhere in this discussion the answer to all three is "yes". Thryduulf (talk) 14:56, 9 December 2025 (UTC)Reply
It is not a WP:OTHERSTUFF argument to point out that an argument for or against something directly contradicts overlapping consensuses. Specifically in this case, if the argument for deleting these lists is that some of them are unsourced, it is incumbent upon the person making that argument to explain why that doesn't apply elsewhere in the encyclopaedia - if you argue that X and Y are different you need to explain what makes them different. Thryduulf (talk) 16:35, 9 December 2025 (UTC)Reply
If OTHERSTUFF is unsourced, that simply means that we either have to find acceptable sources for that other stuff or remove it. Same applies here.
But that still leaves the disagreement over whether THIS specific “stuff” is encyclopedic. I know you (and others) believe it is, and you know that I (and others) believe it is not. Remember that Verifiability does not guarantee inclusion. Even if these lists can be sourced, that does not mean we must include them. Blueboar (talk) 16:56, 9 December 2025 (UTC)Reply
Verifiability does not guarantee inclusion, but being presently unsourced does not require exclusion nor is it a valid justification for exclusion. I know that you believe the lists are unencyclopaedic, but I've yet to see any reason supporting that viewpoint that hasn't been fully refuted and/or shown to be irrelevant to the question. In contrast viewpoints that regard these as encyclopaedic are fully supported by what policies and guidelines actually say (rather than what some people would like them to say). Thryduulf (talk) 17:09, 9 December 2025 (UTC)Reply
As you and I have agreed many times over the years, material is verifiable if someone can find a reliable source for it, not solely when an editor has already typed a citation into the article.
One of the problems we've been having in the last two or three years is the RFC in which "I" declare that somebody else should provide sources that meet my standards, but which I'm not willing to lift a finger to find or add myself. This is incompatible with our WP:VOLUNTEER structure. An RFC cannot assign tasks to people who think their time is better spent elsewhere, so a result of "Somebody else should do this work" isn't a practical or functional outcome. But an RFC makes a visible platform for people to affirm their allegiance to high-quality sources, so we get a lot of editors saying that this is the best way to cite this material, even though basically none of them intend to do any of the work. This leads to us having too many people issuing orders and not enough people doing the useful work. We may have a cultural problem here ("Who has to do the boring, tedious work of finding good sources? Policy says not me! Policy says I get to blank everything if somebody else doesn't do what I tell them to do before my WP:DEADLINE. I'm WP:NOTHERE to collaborate with people who want accurate information in articles when I think they've cited weak sources"), rather than a rules-based problem. WhatamIdoing (talk) 20:27, 9 December 2025 (UTC)Reply
Nitpicking and wikilawyering. To be blunt, I don’t care whether these routes are verifiable or not. I don’t think they are encyclopedic. Per VNOT I would omit them.
I prefer to think of it as "clarifying", though some of it does involve quite small and potentially unimportant details.
It sounds like the bottom line for you is that even if an editor decides to find acceptable sources for that other stuff, you would prefer to remove it anyway.
Personally, in terms of an instinctual feeling about what's encyclopedic and what's not, I'd go the other direction: The airline is unimportant to an airport, and the destination is the key thing. I think this partly because of how the US market works (airlines are mostly interchangeable from the average passenger's POV; especially for Essential Air Service (10% of US airports with scheduled passenger service?), if Alice Air stops flying from A to B, then Bob's Airline will soon start flying from A to B). It's possible that people in other parts of the world would have a different choice, but if I had to pick either airline or destination for an airport article, I'd pick the destination.
The reliable sources tend to provide both, so I'm not sure that we should be choosing between the two, but it's interesting that we pick the opposite items. Are you thinking more about the global businesses? I'm thinking more about the travelers in the airport's region. WhatamIdoing (talk) 21:11, 9 December 2025 (UTC)Reply
As someone who has been very actively trying to clean up these lists...
The dream - I try, but as I'm not an avgeek I often don't know where to look.
My current go-to - but brings with it serious backlash
Has achieved nothing in my experience, aside from attracting the ire of editors that believe (understandably) that a mass of [citation needed] tags as ugly... and in my experience, I've only ever seen a single user react to them - and they are now blocked (Wibwob28).
In my humble opinion, not an option - if I see an issue, then I should be attempting to fix it instead of leaving it for someone else. If we all did this, then nothing would ever get improved or fixed.
So what does that leave us? If I can't find a source for a route (which is most of the time, darn the fact I'm a train nerd instead of an aviation nerd), the other three options wind up with an angry mob on the talk pages...
My opinion on the matter is simple - we've proven over the last multiple months just how much trouble it is to try and maintain basic standards in these tables, resulting in multiple ANIs and certain editors calling for me to be topic banned. Given that all I'm doing is trying to improve the encyclopaedia, that only leaves one other common denominator... the existence of these tables. Danners430tweaks made21:10, 9 December 2025 (UTC)Reply
I have not - primarily because of the below... what time I have on Wikipedia is almost entirely taken up on recent changes patrolling, which is what I primarily choose to do. What it does highlight is it appears that I, along with only a small number of others, actively recent change patrol these pages - and because of the amount of churn, we don't have the time or energy much of the time to actually work to improve the articles. If our time wasn't taken up dealing with the unsourced nonsense that gets added, perhaps we'd be more willing and able to actually add content... Danners430tweaks made21:31, 9 December 2025 (UTC)Reply
Maybe take a breather from this — you’re giving yourself (and everyone else!) a migraine for no reason. Stick to being a train nerd and let the AV geeks wrangle over the airport pages. Imagine them barging into the train articles and tearing up the stuff you spent hours perfecting… you’d be fuming! You'd combust like an over heated steam engine!! Dootfish (talk) 22:23, 9 December 2025 (UTC)Reply
While this comment is generally not very polite or nuanced, there is a small amount of truth. @Danners430, don't take this personally, but if this RfC doesn't close how you want it to, or nothing substantially changes (like after the last one), just... give up. The destinations are, whether encyclopaedic or not, whether well sourced or not, generally accurate, and there's no actual harm in leaving them like that. Stop taking the inadequate sourcing of airport tables as a personal affront (however much you believe in using Reliable Sources, to quote your userpage), and find somewhere else to contribute where you'll have less abuse hurled at you by over-enthusiastic inexperienced avgeeks. Just a suggestion. JustARandomSquid (talk) 22:36, 9 December 2025 (UTC)Reply
Now someone’s actually being polite about it… :D Don’t worry, I’m not precious about discussion outcomes. As I said in a completely unrelated discussion the other day, to me disagreements and consensus-building are just part of building Wikipedia. To me, what I really want from this RfC is to put the matter of these tables to bed once and for all, as there have been arguments flying about everywhere. So even if it doesn’t go “my way”, I’m still happy because a consensus will have been reached (or not) - we can say “at least we tried!” If we do decide to retain the lists, then nothing really changes for me - I stay recent changes patrolling, and gradually clean up the tables in terms of sourcing. Eventually, they will all be fully sourced - even if they don’t get removed.
As for the abuse being hurled - trust me, I have a thick skin… and if it ever gets bad enough that it becomes personal attacks, I just take a step back and let ANI deal with it :) Danners430tweaks made22:41, 9 December 2025 (UTC)Reply
I didn’t mean to offend you — it’s nothing personal. But from the outside, it does seem like you’re becoming a bit too overly focused on this, almost to an unhealthy degree. Half of Wikipedia is out of date, so it may be more worthwhile to spend your time improving the train pages, since that’s where your real interest lies. There’s no need to bring so much negativity on yourself, especially when you’re not responsible for policing the airport pages and you’re not working for Wikipedia. Dootfish (talk) 23:11, 9 December 2025 (UTC)Reply
Even if the airport tables were removed, options 2 to 5 would still lead to new issues. It would just become a cycle of fixing one problem only for another to appear. Dootfish (talk) 23:13, 9 December 2025 (UTC)Reply
UK rail pages are actually in very good shape and have generally low levels of churn. I chose to start working in this area specifically because I saw how bad the sourcing was in areas, and how much unsourced content was being added. Danners430tweaks made23:14, 9 December 2025 (UTC)Reply
Purely in the interest if illustrating the level of churn in these articles, these are all the warnings I've left on user talk pages just today regarding unsourced content on airport destination lists. TO emphasise - this is only the unsourced content...
Again - that's only in the last 21 hours, and only the unsourced additions that I reverted. Sorry, but these lists are simply a timesink in terms of maintenance. Danners430tweaks made21:27, 9 December 2025 (UTC)Reply
The addition of YYZ to SLC you reverted was accurate. The addition of passenger statistics to Tunku you reverted was already in fact sourced by the existing general reference, the IP merely didn't update the access date. The addition of West Air to Yangon you reverted was accurate. The addition of Alicante to Zvartnots you reverted was accurate. The addition of Glasgow to Alicante you reverted was accurate. Again, new or unregistered users adding information without sources is a routine editing issue we encounter across the project, not a reason to delete entire sections across thousands of articles. Just because you choose to sink your time into overzealously reverting actual improvements by helpful, good faith editors doesn't mean we should make these articles less informative. Reywas92Talk04:52, 10 December 2025 (UTC)Reply
Perhaps the concern by @Danners430 is about using the usage of the secondary sourcing. The Alicante to Zvartnots are factually correct, there is nothing in secondary sources but the website of the airline clearly confirm that the route is accurate. I do think that airline schedules posted by the airlines themselves should be able to be used in sourcing, as it is just "facts" and there is no synthesis involved at all. If Delta posted the news on their website to fly from Charlotte to Copenhagen than it is true, there is no synthesis or further analysis needed. ✠ SunDawn ✠Contact me!10:11, 10 December 2025 (UTC)Reply
No, my concern was that it was unsourced. As Reywas92 themselves showed when they posted the diff, the IP editor simply added the route without any source, which was why it was reverted. This happens on a regular basis on these lists - there are plenty of constructive contributions too by many editors, but there are an equal number of these unsourced additions. Danners430tweaks made10:15, 10 December 2025 (UTC)Reply
Anyway, this isn’t exactly the venue to be discussing why I took the actions I did - I removed unsourced content which is permitted under WP:V. I posted the above simply to illustrate the amount of unsourced churn there is in these lists. Danners430tweaks made10:16, 10 December 2025 (UTC)Reply
@Levivich: I would be all in favour of retaining the previous consensus - however, if you look at the state of the articles, it would appear basically nobody ever took heed of that consensus. The lists remain a comprehensive list of routes, and many even use the airline’s own timetable as the overarching source. If everyone ignored that decision last time, why would they listen this time? Danners430tweaks made21:45, 9 December 2025 (UTC)Reply
Because everyone knows that airline timetables can accurately verify the content without bias, and imposing additional requirements on these straightforward, uncontroversial facts is absurd and would result in incomplete lists. Since then we have in fact retained route-specific news sources rather than removing them on route start like before, but it will take time to add those everywhere, and most users are unaware of that discussion since it's inconsistent with sourcing requirements elsewhere. Overarching sources are fine for this sort of basic material. Reywas92Talk05:02, 10 December 2025 (UTC)Reply
I can't follow your reasoning. This is an encylopedia. We don't need "complete lists". We're writing a book report level summary of what other people write about topics. If Airline Timetables exist, we should NOT be copying them and just reposting them on Wikipedia. Just add a link to the timetables on the airline articles - poof! Done! Accurate, up to date information at your fingertips. Denaar (talk) 14:39, 10 December 2025 (UTC)Reply
But readers aren't looking for individual airlines' timetables, they're looking for the compiled information of what parts of those timetables relate to specific airports, and the compilation as a whole conveys information about operations at the airport generally. What in world does "We don't need 'complete lists'" mean? I'm at regular at WP:FLC and we certainly expect lists to be complete. There might be a book report summary in the lead, but that's no excuse not to bother to show the full picture. — Reywas92Talk15:36, 10 December 2025 (UTC)Reply
If complete lists don't exist anywhere else and can't be sourced appropriately (by secondary, independent sources demonstrating how such lists/info actually are important to understanding the airport), then they should be hosted on a different wiki. JoelleJay (talk) 18:01, 10 December 2025 (UTC)Reply
I'm seriously leaning toward option 5 but feel it's perhaps a bit of an over reaction. I can't help but think is there a way to write the table to suggest "here are some examples" instead of suggestion completeness, because human nature is to want things complete. Then it looks like, from some examples I followed, we've got the same info on the airline articles too, so it's in two places? It makes more sense to me to have it on the airline (this is where they go) then on the airport, the airport isn't connecting to other places, its the airline routes that are. Denaar (talk) 04:51, 10 December 2025 (UTC)Reply
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
A case was recently filed at DRN about an article about a legal case involving a transgender person. The article is currently subject to extended-confirmed protection. The filing editor is not extended-confirmed. I closed the case, because it is my understanding that editors who are not allowed to edit an article should not take part in dispute resolution about the article. I advised the filing editor that they can submit edit requests, but that is the extent of what they are permitted to do about the article. The filing editor has complained that this restriction is unfair, because they say that there is a factual error in the article. So I have two questions. First, was I right in closing the DRN request? Second, what advice can be given to the filer, who wishes to address a factual issue?
(In researching the case, I found that the filing editor had made a personal attack against another editor on the article talk page. I have warned the editor and collapsed the personal attack. This doesn't affect the questions.)
Robert McClenon (talk) 05:18, 10 December 2025 (UTC)Reply
There is a difference between extended confirmed protection and the extended confirmed restriction. Extended confirmed protection is a protection level that can be used for a variety of reasons, including to stop vandalism or sockpuppetry. To my knowledge, it does not apply anywhere outside of the article which is protected, not even to that article's talk page. An extended confirmed restriction, part of several contentious topics designated by ArbCom or the community, applies everywhere.
This page falls under the CT/GENSEX and CT/BLP. Neither has an extended confirmed restriction. The page protection was placed [22] by @Daniel Case under these CTOP regimes, which makes it easier for administrators to take admin actions to stop disruption. However, this is still not an extended confirmed restriction. Therefore, I don't think closing the DRN solely because the editor cannot edit the disputed page was appropriate. Toadspike[Talk]09:58, 10 December 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.
Latest comment: 7 days ago7 comments7 people in discussion
I think I know the answer to this question, but would like to confirm it. Are there content issues that are not worth the volunteer time that will be spent in resolving them? The dispute in question is about which unit of measurement should be listed first. The MOS and various guidelines say that, except with articles having strong ties to the United States or the United Kingdom, metric units SI should be primary. The issue is whether a pressure should be stated in bars followed by pascals or in pascals followed by bars. I am aware that the pascal is the SI unit of pressure. However, it is my opinion that a dispute over which unit to list first is not worth the time required to resolve the dispute. Does that make sense?
Robert McClenon (talk) 05:18, 10 December 2025 (UTC)Reply
It's up to the volunteers which disputes (and which matters in general) they choose to invest their time in. Me, I do a fair number of MOS:LQ fixes, which I'm sure other editors would not feel were worth the time. As such, I don't see much point in coming to an agreement as to what matters are not worth another editor's time; editors who do not feel it is a good use of their time are free to bow out of the dispute. -- Nat Gertler (talk) 05:28, 10 December 2025 (UTC)Reply
I usually see the pressure of an atmosphere or gas in the context of meteorology or astronomy, and in those contexts I usually see it listed in bars and millibars rather than pascals, but if someone's very passionate for pascals I wouldn't bother to fight them over it.—S MarshallT/C11:18, 10 December 2025 (UTC)Reply
It likely depends on the specific topic. If dealing with a article on low pressure or vacuum conditions, pascals would likely be used by sources over bars, while for high pressure applications, I'd expect to see bars over pascals. Should follow which form is used by the RSes in that topic area Masem (t) 14:54, 10 December 2025 (UTC)Reply
I also realize that Micronations arent technically real countries, but some sources, primary AND secondary all corroborate the same thing, "republic of *country name here* has a flag of green blue and red". So I am wondering if for micronations, if we should just include the flag, or keep it the same way that people in the original RFC voted to remove the symbols from the infoboxes.
My general proposal (using my micronation's country infobox for a second)
I'm not seeing anything in this proposal that wasn't brought up in the first RfC or the discussion that you linked. We should not have to "vote" on it a third time. Schazjmd(talk)20:45, 11 December 2025 (UTC)Reply
If the micronation you created ever becomes notable and gets an article, I am extremely skeptical that anything you have put in the proposed infobox template will actually be among the most relevant facts to convey about it (which is what infoboxes are meant to do). A lot of discussion went into shaping the current Template:Infobox micronation to focus on actually relevant info, and I don't see any compelling reason to revisit it so soon.--Trystan (talk) 01:26, 12 December 2025 (UTC)Reply
I've never been involved with this issue before, so I'm reading that RfC close for the first time. It says:
Consensus is against generally including the flag, coat of arms, and other purported symbols of the micronation, though it may be appropriate on a case-by-case basis. The ultimate conclusion is that these symbols are often not recognized or reliably verifiable, and could easily mislead a reader; that they are not used in the same way as countries, and so should not be treated in the same way. Certain symbols which are recognized or reported by reliable sources may be appropriate to add, as important information.
It seems to me that the close already includes the "exceptions" EditorShane is asking for. When a flag is "recognized or reported by reliable sources", it "may be appropriate to add". For instance, I remember coming across an article on "Liberland" recently that described the flag and incuded a photo of it (possibly this CNN piece). That resolves the verifiability issue and suggests this information may be due for inclusion. Toadspike[Talk]07:43, 12 December 2025 (UTC)Reply
So the very title of this section is misleading - it's not the "no Flag in Infoboxes for Micronations" RFC at all. There must be a Wiki on Fandom about micronations which doesn't have Wikipedia's rules about verifiability and infoboxes where the OP can play away to his (nearly all micronation fans seem to be male, for some reason) heart's content. Or, if not, he can create one. Phil Bridger (talk) 11:39, 12 December 2025 (UTC)Reply
No flags for micronations. I'm actually a little concerned that the micronations infobox and the way micronations are portrayed on Wikipedia is giving them, in Wikivoice, a legitimacy that doesn't actually exist. Many of them seem to be worded as Wikipedia saying they're more than some people's weekend model UN style of hobby and an actual legitimate thing. However I know this was addressed in the RFC, but I wonder if some are going to far in Wikivoice. Canterbury Tailtalk16:13, 12 December 2025 (UTC)Reply
A flag at the top of the infobox is a non-starter. Others have given arguments why. Optonially allowing symbols (e.g. flag, coat of arms or logo) at the bottom of the infobox may be a compromise. But if we allow it, how do we make sure symbols are only included where they are WP:DUE? Joe vom Titan (talk) 07:18, 13 December 2025 (UTC)Reply
I also realize that Micronations arent technically real countries. What a ridiculous comment. Micronations aren't countries at all. They are overwhelmingly fantasies and/or moneymaking schemes. As such, their flags are of no encyclopaedic interest whatsoever. Where they aren't being spammed over Wikipedia to mislead readers into thinking they actually represent anything real, they are just micronation-fantasist fancruft. Wikipedia is blighted with far too much of that as it is, and I see no reason why we should encourage more. AndyTheGrump (talk) 16:52, 12 December 2025 (UTC)Reply
Question Micronations aren't nations, but many of them are genuine projects, perhaps carried out by organizations of some sort. When we have an article on an organization, we'll display its logo. Is the flag of a micronation comparable to the logo of a conventional organization? — Preceding unsigned comment added by Largoplazo (talk • contribs) 16:56, 13 December 2025 (UTC)Reply
Off the top of my head, I can't think of any micronations that have been promoted by organizations that meet Wikipedia WP:NORG notability criteria. Most consist of little more than a website, generally one set up to gather funds. Corporate logos are ubiquitous, and many are likely to be recognised by readers. Flags of imaginary entities are recognised by nobody but those doing the imagining. So not comparable in the slightest, just promotional fluff. AndyTheGrump (talk) 18:50, 13 December 2025 (UTC)Reply
Do we ever suppress corporate logos on the grounds that the corporation is small and hardly anyone outside the corporation would recognize its logo? -- Beland (talk) 00:57, 14 December 2025 (UTC)Reply
Wikipedia is a encyclopedia which means it gives information, having a flag in a article about the micronation gives information to the reader if they want to learn more about micronations, they would want to know the flag, it's history, culture, and purported currency. shane(talk to me if you want!)01:18, 14 December 2025 (UTC)Reply
Having a flag doesn't imply the existence of a serious, territory-holding country. All sorts of entities have flags, from companies to vague social movements. The text of the article should make very clear if a micronation is a joke. -- Beland (talk) 03:24, 14 December 2025 (UTC)Reply
Principality of Sealand, for example, is substantially more than fancruft. It's a physical place with a real-world economy that was chosen because it was in international waters, and has had real territorial disputes. Its flag flies on the territory it claims. -- Beland (talk) 00:56, 14 December 2025 (UTC)Reply
Change "continent" to "continental regions" OR "major geographical region" as definition in geography articles
Latest comment: 17 hours ago60 comments12 people in discussion
Animated, colour-coded map showing some continents and the region of Oceania (purple), which includes the continent of Australia. Depending on the convention and model, some continents may be consolidated or subdivided.Sixteen principal tectonic plates of the continents and the floor of the oceans22 geographical subregions as defined by the UNSD. Antarctica is not part of the system, as it applies to member states of the United Nations.
Wikipedia is currently endorsing one of many models, and that one is specifically the one rooted in the legacy of colonialism and European exceptionalism. This would impact several articles, so I thought I'd propose here so we can try and standardize word choice. This proposal tends to invoke strong reactions, particularly in Western educated people who memorized the "continents" in elementary school and have it embedded in their core knowledge. Please keep an open mind in terms of how the model you learned is a bit of a relic and outdated.
The term "continent" is ambiguous, and from a geographic perspective is similar to Race (human categorization). The term itself goes back pretty far to the time before we had any idea about tectonic plates, and there are multiple definitions (see gif for some of the models). Like the concept of human races, as we developed a better understanding of the world, we realized our previous models were not reflective of reality, but often reflections of power dynamics and society more then something innate to the physical world. On Wikipedia, we tend to endorse the 7 continent model of Europe, Asia, North America, South America, Australia, and Antarctica, but this is a distinctly western model that is taught in the English speaking world, which is not surprising given the identity of most Wikipedia:Wikipedians. When it comes to this model of continents, they are a really antiquated compromise between Human geography and Physical geography, and reflect a Eurocentric and even supremacist world view. This is the primary problem with the 7 continent model, Europe is an outlier compared to the other 6 as the only "continent" without that is not separated by a tectonic plate (see map of tectonic plates). Europe is a peninsula on Eurasia, and the categorization of Europe as a separate continent based entirely on the prejudice of the geographers who originally made the classification. A few quotes on the topic:
Europe is not a geographical continent and geographers have little reason to continue to teach lower grade children (grades 1-4) that there are seven continents and that Europe is one of them.[1]
In lists of continents compiled outside the United States, Europe and Asia are often combined as Eurasia.[2]
If one considers Eurasia a continent, though, Europe is merely a subcontinent attached to the larger continental landmass. Other subcontinents might include the Arabian Peninsula of southwestern Asia, the southern cone of South America, and ALASKA (the northwestern peninsula of North America).[2]
Convention recognizes the existence of a number of continents which are discrete entities though contiguous with other continents. In this summary, continent-continent boundaries are drawn only along recognizable active plate boundaries.(The difficulties of plate boundary recognition are to be addressed in a future paper.) This means that Europe and Asia do not have separate existences; the Ural chain has long been an interior landform of the Eurasian continent.[3]
Europe qualifies as a continent — that is at least what we are taught in school — but a continent whose contours are difficult to define, especially toward the east (see Chapter 1). How is it that a continent, a mass of land surrounded by bodies of water, could find itself indistinguishable from bordering lands? It is important to grasp this paradox in order to think about space correctly and reflect on the way we place ourselves within it. For Europe, in fact, is only a continent through conceptual usurpation. A sort of geographic coup was orchestrated in the 19th century, almost accidentally. Until then, Europe was only a part of the world, such as Asia, Africa, America and Oceania, and there were only two continents, the "Old World" and the "New World". In fact, one of the problems perhaps arises from this toponymical oversight: What do we name the continent of which Europe is only a part: Eurasafrica? Eurafrasia (Grataloup 2007)? Africeurasia (Boucheron 2009)? Afro-Eurasia? Or Eufrasia (Capdepuy 2012)? This last suggestion is the shortest contraction and perhaps the most euphonic for saying, in one word which almost resembles a first name, Eu(rope), (A)fr(ica) and Asia.[4]
That Europe's continental status may be denied with a wink but then continually confirmed in practice does not indicate a simple oversight. Nor can it be dismissed as a mere convenience, a simplification necessary for making sense of a complex world. Rather, Europe's continental status is intrinsic to the entire conceptual scheme. Viewing Europe and Asia as parts of a single continent would have been far more geographically accurate, but it would also have failed to grant Europe the priority that Europeans and their descendants overseas believed it deserved. By positing a continental division between Europe and Asia, Western scholars were able to reinforce the notion of a cultural dichotomy between these two areas-a dichotomy that was essential to modern Europe's identity as a civilization. This does not change the fact, however, that the division was, and remains, misleading. Not only do Europe and Asia fail to form two continents, they are not even comparable portions of a greater Eurasian landmass. Europe is in actuality but one of half a dozen Eurasian sub-continents, better contrasted to a region such as South Asia than to the rest of the landmass as a whole. (It would be just as logical to call the Indian peninsula one continent while labeling the entire remainder of Eurasia-from Portugal to Korea-another.)[5]
"No other continent has so many peninsulas, in fact the continent itself is but a peninsula of Asia."[6]
To demonstrate the logic that lead to Europe's stats as a continent (and why it is problematic), here is a quote:
Europe is the center of the intellectual, cultural, scientific, industrial, and commercial world. In fact the higher civilization of the world, outside eastern and southeastern Asia, is European, or slightly modified European ; and nearly all modern advancement in the Orient is due to European influence.[6]
To address this, I prepose a small but relatively important change to relevant pages: switching to the United Nations geoscheme as our primary way of discussing regions. The UN Geoscheme is not perfect, but it is an improvement that we can at least point towards for justification of our word choice. Specifically, it focuses entirely on human geography and regions, rather then trying to fuse both physical and human geography. Rather then using the term continent, it refers to these areas as "continental regions" link. It focuses on keeping each country within the confines of one region, using human borders rather then natural to help delineate. Continental regions are: Africa, Americas, Asia, Europe, and Oceania, with each being broken down into 22 sub-regions (see map). Antarctica is not included as it has no real human geography.
We can move mention of historic inclusion of each "Continent" to the history and background sections of each page, while in Wikivoice defining them as "continental regions," citing the UN geoscheme. We can further elaborate on additional models, and discuss their status as a geologic "continent" where applicable, rather then endorsing one outdated model that hybridizes physical and cultural continental status. I believe this is a minor, rather un-invasive change that would dramatically reduce Western bias and improve accuracy across the pages. The use of the term region allows for the reader to understand the underlying areas are not "set in stone," but ambiguous human constructs that reflect a specific world view. While the United Nations is far from perfect or free of western bias, it is a better source then whatever it is we are currently using to use the 7 continent model as the default for English Wikipedia.
References
^Barton, Thomas Frank (1962). "Continents: How Many?". Journal of Geography. 61 (6): 267. doi:10.1080/00221346208985059.
^ abBaldwin, James A. (2014), "Continents", in R.W. McColl (ed.), Encyclopedia of World Geography, Infobase, pp. 214–216, ISBN978-0-8160-7229-3
What we should do is adopt a standard reliable source. The UN source isn't perfect, but defaulting to the model that divides Europe and Asia based on a 19th century model is really not better. GeogSage (⚔Chat?⚔) 21:48, 12 December 2025 (UTC)Reply
As I just explained to you today at Talk:Europe to the same discussion that you launched there in September before you decided to start it from scratch here today, it's contrary to Wikipedia's mission to spearhead new ways of doing things that differ from the way they're being done in the outside world, regardless of your opinion of what changes ought to be made in the outside world. WP:NOTFORUM. Largoplazo (talk) 22:24, 12 December 2025 (UTC)Reply
Changing all references to "continents" to read "continental regions" because one source has adopted that needless circumlocution would be a new way of doing things. Largoplazo (talk) 22:44, 12 December 2025 (UTC)Reply
The Statistics Division of the United Nations is a pretty big source when it comes to international consensus regarding the division of global regions... GeogSage (⚔Chat?⚔) 02:24, 13 December 2025 (UTC)Reply
This would result in us listing the Arabian peninsula and Caribbean as separate, while lumping Europe with Asia into "Eurasia." It also results in a large portion of what we commonly think of as Asia being in North America. GeogSage (⚔Chat?⚔) 21:50, 12 December 2025 (UTC)Reply
I meant groups of tectonic plates as a general rule of thumb not a strict delineation
The issue is one of WP:OR. Regional geography is an academic discipline, creating our own regions would be original research best suited to publication in one of their journals. On Wikipedia, we are limited to existing models and sources. The geological model explains physical geography, and I think it should be included on relevant pages along side the regional model(s), but think we should find a better one then the 7 continent model and use it as a consistent default. GeogSage (⚔Chat?⚔) 01:29, 13 December 2025 (UTC)Reply
Oppose There are a number of issues here including the majority of reliable sources, not to mention WP:COMMONNAME. Entities such as "Southern Europe", "Northern Europe" and "Western Asia" are effectively non-existent in the vast majority of RS. Black Kite (talk)22:03, 12 December 2025 (UTC)Reply
"Entities such as "Southern Europe", "Northern Europe" and "Western Asia" are effectively non-existent in the vast majority of RS." This is not true, especially when it comes to Southern and Northern Europe. There are reliable sources for every model, the one we use is used in English sources, but as noted these are subjects of criticism. The UN model is a reliable source that is closely tied to international consensus. GeogSage (⚔Chat?⚔) 22:10, 12 December 2025 (UTC)Reply
Seriously? Yes, people may refer to "Northern Europe" when they're simply referring to the Northernmost parts of Europe (and so forth), thus you will get references to them, but they're not used regularly in RS as actual separate identifying areas. To give a very simple example, I could say I'm from Northern England (and that would get a large amount of Google hits, no doubt), but there isn't an official geographical area called that. But really, WP:COMMONNAME is the deal-breaker here - that's policy. Black Kite (talk)22:19, 12 December 2025 (UTC)Reply
I commented on the Europe talk page proposal to let people know it was being discussed here. I was encouraged on my Talk page to make a broader comment, and I wanted to try and apply this to more then just Europe as it is a more extensive issue. I didn't think I needed to link to the other discussion, but if I did it was an honest mistake. GeogSage (⚔Chat?⚔) 22:26, 12 December 2025 (UTC)Reply
Fair enough, that you were in search of a broader audience. But, yes, you did need to show that there was already a history to this discussion, rather than talking to the folks here as though you hadn't already received feedback from others and without giving any indication that you'd taken any of that feedback into account. Largoplazo (talk) 22:42, 12 December 2025 (UTC)Reply
Oppose As said above, definitions of continent are ambiguous, but the given suggestion seems to go for full (not partial) adoption of geographic definition, foregoing social constructionist, historical etc. definitions. Before we go this way we must (1) agree Geography is the main science in such cases (please provide reliable sociological, historical sources [ie non geography] that agree here) and if this is decided (2) we must rigorously apply geographical definitions even if they go against common consensus. (declaring the India plate as a separate continent may be a consequence). I simply do not think consensus will ever be reached for (1) across all scientific disciplines using continent as term let alone (2). But given the common use of the term Continent moving to more technical terms seems to defeat the purpose of an encyclopedia i.e. providing readers on information on commonly used concepts. So going away from concept is a no go for me Arnoutf (talk) 22:23, 12 December 2025 (UTC)Reply
We currently are endorsing one model, that does not have full consensus across sources. I'm preposing we define the regions primarily using the UN definition, and discuss the other models within the page using the various sources. The page for Continent has a Table that includes reliable sources for the four, five, six, and seven models. GeogSage (⚔Chat?⚔) 22:29, 12 December 2025 (UTC)Reply
The UN definition does not have full consensus across sources. Which page do you mean by "the page"? The Continent article already covers all the various definitions, so I assume you don't mean that one. Do you mean to go through all of these details on every article on Wikipedia that mentions continents? Largoplazo (talk) 22:52, 12 December 2025 (UTC)Reply
Oppose For use in this English project, we should go by established usage of the term "continent" found in the vast majority of reliable sources. It would be contrary to Wikipedia's policy and mission to follow one source that has taken it upon itself to be "correct" and buck the trend. WP:RIGHTGREATWRONGS. If you'd like to see the change come to be adopted in outside sources, you'll need to take that up with them. Largoplazo (talk) 22:35, 12 December 2025 (UTC)Reply
There is no reason we can't explain the nuance and complexity of the term, and respect different models. We are currently defaulting to one, and the one that has the most Wikipedia:Systemic bias at that. There are multiple contradictory reliable sources and we do not reflect that. GeogSage (⚔Chat?⚔) 22:48, 12 December 2025 (UTC)Reply
I don't want to make every article a forum, I want to address it all at once. That is why I moved the discussion here when I realized I would have to have the same talk on every page to fix the problem, and it is a problem. This is more then a small minority opinion, and it is not reflected in our articles. Referring to an attempt to standardize the way we describe geography as "tiresome digression" does not feel very civil. You may strongly disagree, but I strongly believe that this is an example of Wikipedia:Systemic bias, and this is an area I have a bit of expertise in. I'm approaching this from critical, human, physical, and regional perspectives, and providing sources. Geography has moved away from the term continent in most academic literature, instead focusing on regions. Here is another quote from The Myth of Continents: A Critique of Metageography referenced above: "Paradoxically, almost as soon as the now-conventional seven-part continental system emerged in its present form, it began to be abandoned by those who had most at stake in its propagation: professional geographers. Whereas almost all American university-level global geography textbooks before World War II reflected continental divisions, by the 1950s most were structured around "world regions" (discussed in chapter 6). Yet the older continental divisions have persisted tenaciously in the popular press, in elementary curricula, in reference works, and even in the terminology of world regions themselves." GeogSage (⚔Chat?⚔) 01:13, 13 December 2025 (UTC)Reply
Oppose this particular scheme, but would strongly support other possible ways to move away from the 7-continent model. I agree that combining the Americas while leaving Europe and Asia separate isn't consistent enough (and indeed suffers from the same Eurocentrism that plagues the 7-continent model) to warrant a different geography. I understand that this proposal probably aimed with a hint of gradualism to not propose a sharper divergence from existing practice, given that Wikipedians are often unwilling to acknowledge their biases, but the the UNSD continental regions are not the solution. They are an attempt to mix geographical continents and geographic regions together that ends up failing at successfully representing either.Katzrockso (talk) 00:08, 13 December 2025 (UTC)Reply
Ideally, I think we should discuss all the models where due, and yes this is an iterative approach to something better (I'm not sure what that is). The UN approach is one of a few, and I'm not the biggest fan of the way they group the Americas, but it has sounder logic then what we are currently doing, and importantly, it does represent a 3rd party consensus between members of the global community. Fundamentally, when it comes to geography Wikipedia has no real standards or consistency, and defaults to the bias of editors without really thinking to consider different perspectives or "why" a thing is thought to be the consensus (even when it is not). The discussion here shows people confidently asserting a consensus that demonstrably does not actually exist outside a U.S. elementary school classroom. WP:DUE: "If a viewpoint is held by a significant minority, then it should be easy to name prominent adherents." I've given six sources above that discuss the issues with the model that includes Europe, on the continent page there are 8 sources that favor the 4 continent model, 3 that support the five continent model, 3 for the two 6 continent models, and 6 for the seven continent model we use. The geologic model has between 6 and 7 continents, none of which are Europe, and several "subcontinents" are on their own tectonic plates. This represents a "significant minority," at the very least. Across all relevant pages, we default to the western model, which is based on the belief that "Europe is the center of the intellectual, cultural, scientific, industrial, and commercial world" and gives "the priority that Europeans and their descendants overseas believed it deserved." If you have a counter proposal that is based on another reliable source, or a way to balance all these competing perspectives on the issue, I'd love to hear. GeogSage (⚔Chat?⚔) 00:59, 13 December 2025 (UTC)Reply
If 5,000 newspapers and textbooks call Europe a continent out of hand, without concerning themselves with the technical details behind the word, and dictionaries define "continent" accordingly—as I noted to you at Talk:Europe, basically, "a continent is one of those land masses that are known as continents", with zero reference to technical considerations—then it doesn't matter what a few dozen institutions holding angels-dancing-on-the-head-of-a-pin debates about alternative conclusions come up with to say about it. And I already commented to you about how changing it to "continental regions" when exactly one source does that is a non-starter, a violation of Wikipedia policy and practice.
That "one source" is used as the foundation for a multitude of sources published by the UN and other organizations. Our articles should reflect the academic consensus, not "elementary curricula." Regions is a more 20th century approach to this issue, we're currently stuck in the 1800s. GeogSage (⚔Chat?⚔) 01:15, 13 December 2025 (UTC)Reply
It's one source that apparently most aren't following. What they've decided to do, besides that, is, in the context of our purposes, a solution in search of a problem. As for centuries, we're using what 21st century sources are using, so we aren't "stuck in the 1800s". Largoplazo (talk) 01:18, 13 December 2025 (UTC)Reply
A funny thing just occurred to me. All "continental regions" does is beg the question. What's the definition of a region? Well—a region is whatever we choose to designate as a region (a choice into which—gasp!—systemic biases may come into play). Its borders are ... whatever one party or another has decided its borders are, and those are very often subject to dispute among multiple parties. It hardly solves the problem. Largoplazo (talk) 01:28, 13 December 2025 (UTC)Reply
Well—a region is whatever we choose to designate as a region EXACTLY! Region is an ambiguous term that has this thinking baked into it, while "continent" is generally perceived to be more absolute. We should ideally discuss multiple models for a place and how it fits into these distinct generalized regions. Declaring "Europe is a continent" or "America is a continent comprising of North, South, Central America, and the Caribbean" is fully investing in one model as Reality. Again, this is not something I'm pulling out of the either, this is something taught in introduction level college courses on World Regional Geography, I've taught several. GeogSage (⚔Chat?⚔) 01:35, 13 December 2025 (UTC)Reply
The page Caucasian race defines it as "The Caucasian race (also Caucasoid, Europid, or Europoid) is an obsolete racial classification of humans based on a now-disproven theory of biological race." I'm sure you can find a plethora of 21st century sources that use the term "Caucasian." GeogSage (⚔Chat?⚔) 01:40, 13 December 2025 (UTC)Reply
If you're concerned with what readers will perceive, they'll perceive "continental region" as mumbo-jumbo and probably edit it back to "continent" with the edit summary "what is this 'continental region' stuff?".
Again: We do discuss the multiple models at Continent, as is appropriate. The word "continent", where it appears in reference to specific continents, can be linked to that. We don't need to hijack the basic identification that a lead sentence and lead paragraph are meant to provide with a comprehensive overview of all the different models of the world's continental breakdown and what the implications of those diverse models are. Largoplazo (talk) 02:04, 13 December 2025 (UTC)Reply
The Europe page literally opens with "Europe is a continent," which is not appropriately discussing the multiple models or terms. It includes a note that other models exist, but that is really not adequate. We are explicitly endorsing the Eurocentric model in the lead paragraph. "Europe is a continental region located entirely in the Northern Hemisphere and mostly in the Eastern Hemisphere." with a note indicating that "historically, some models include Europe as a continent." We can then discuss that history in the body, there are plenty of sources on the matter. GeogSage (⚔Chat?⚔) 05:44, 13 December 2025 (UTC)Reply
In ancient days the List of countries in [Continent] articles at least partially followed the UN scheme, but even at the local level that broke down due to various disputes. I don't think there is any possibility of trying to force through such a wide-scale change across the 'pedia. CMD (talk) 04:24, 13 December 2025 (UTC)Reply
Oppose Is the premise even true? Does Wikipedia really "endorse" the 7-continent model you describe? And how do you propose using the UN Geoscheme to replace all mentions of continents without resorting to original research?
In each article we should follow the sources: use the same model of regions as the sources. If the sources deal with six continents, we reproduce that; if the sources talk about the Old World and New World, we do too. And when talking about the UN geoscheme or presenting data categorized according to it, we shouldn't call their regions "continents".
Also, I don't think Wikipedia has abandoned the concept of race – articles about American society talk about races all the time.
These discussions are better had on the relevant articles than here at the village pump. That would be much more productive than your half-baked WP:WALLOFTEXT proposal here.
On the page for Europe, it states "Europe is a continent." This is an endorsement of one model. It has a note about other models, but the fact remains we are using the 7 continent model as the default. Using the UN Geoscheme to replace would read something like "Europe is a continental region" with a note describing that this is according to the UN Geoscheme, and other models discussed in the main body. I'm not sure how citing the UN scheme is original research. Furthermore, I started trying to discuss this on a relevant article, but believe doing this repeatedly in multiple places will be an extreme amount of work, and only result in an inconsistent approach if it passes in some places but fails in others. This would be a violation of Wikipedia:Policies and guidelines on pages "Not contradict each other." Fundamentally, when it comes to geography on Wikipedia, we don't have a set criteria for how we describe things, or what sources are appropriate to use, and this is a bigger part of my goal of improving the representation of geography. While it might be a lot of text, I believed that citations and quotes were necessary to explain the problem (which is clearly necessary as most editors have not really considered that the continents are not "carved in stone" and establish I'm not just pulling this opinion out of thin air), however I believe calling it "half-baked" is not very WP:civil. I provided 6 citations illustrating the problem, and provided an alternative based on the consensus of an international organization. Furthermore, I believe this (and several comments here) are examples of WP:STONEWALLING, specifically, "Accusing change proponents of disruptive, tendentious, or TLDR editing." GeogSage (⚔Chat?⚔) 19:42, 13 December 2025 (UTC)Reply
Why do you think so many oppose your proposal if it's so well-thought out? You spend a lot of text explaining how continents are an ambiguous and flawed concept. We know that, see the article on continents. But your OP doesn't contain a single example of what Wikipedia does wrong. If you don't analyze the problem, you can't come up with an effective solution. How (much) to talk about continents is an important discussion to have and I agree that we should probably talk less about continents but your specific proposal wouldn't improve anything.
Maybe you can come up with a better global proposal after you've engaged in more discussions on individual articles and gained more experience with the relevant arguments. Joe vom Titan (talk) 20:41, 15 December 2025 (UTC)Reply
Objectively, I think the premise of the proposal is correct (although I agree that this specific propsal is problematic). We should follow how the majority of current scientists write about continents, but as a project, we must be also careful when or if we incorporate new scientific theories into the ledes of our articles. So, if most scientific works describe Eurasia as the continent and Europe as a subcontinent, our articles should reflect that (with appropriate statements that in many cultures, Europe is seen as a separate continent). We also must note while this is an English project, we are a global encyclopedia that gives appropriate weight to how all approach a topic (WP:5P2). --Enos733 (talk) 16:24, 13 December 2025 (UTC)Reply
How could the proposal be made less problematic, I'm very interested in any potential solution that could improve the impacted pages, while ensuring they "Not contradict each other." GeogSage (⚔Chat?⚔) 19:44, 13 December 2025 (UTC)Reply
"Continent" is not a scientific term anyway, dedicated geographers have their own jargon, other scientists will use it in the casual way other English speakers do. CMD (talk) 03:37, 14 December 2025 (UTC)Reply
I will say the community has a similar discussion when the IAU reclassified Pluto as a dwarf planet. Shortly after the pronouncement, the page was changed, despite not (yet) having the public's support. On one level, we do want to present, accurate, verifiable information, and to me, if geologists are generally in agreement here, that is how we should define a continent, while providing space for cultural or political definitions. - Enos733 (talk) 06:27, 14 December 2025 (UTC)Reply
Why are geologists the only type of scientists we should listen to, and not economists or political scientists or anthropologists?
According to Continent#Geological continents, there are seven geologically recognized continents: Africa, Antarctica, Australia, Eurasia, North America, South America, and Zealandia. That leaves people who live on islands surrounded by oceanic crust unconnected with any continent. What would you do with categories like Category:Society by continent? Following the geological definition would mean combining Europe and Asia into an overly large jumble, splitting Australia and New Zealand into tiny subcategories, and just ignoring much of Oceania? -- Beland (talk) 07:00, 14 December 2025 (UTC)Reply
I find this from the New York Times appropriate - "The dispute arises in part because there are really two types of continents: Those recognized by cultures around the world, and those recognized by geologists. Cultures can define a continent any way they want, while geologists have to use a definition. And geological research in recent years has made defining continental boundaries less simple than it might have once seemed as researchers find evidence of unexpected continental material."
Now thinking about this some more, I think we should clarify when we use the term "continent" if we are using the term to mean culture (as a geopolitical term) or as a science term (recognizing in most cases, we mean continents as culture). - Enos733 (talk) 16:56, 14 December 2025 (UTC)Reply
I'd thought of the Pluto thing. I don't know that people will find that persuasive, but perhaps it's relevant that people called Pluto a planet because scientists found an object no one had ever been aware of before and said, to great fanfare, "Look, we've discovered this object and we're calling it a planet", and people took the news at face value and celebrated the new planet; whereas people were calling Europe and Asia "continents" for centuries before scientists decided to coopt the word for their own purposes and monkeyed clandestinely with its definition while most of the world remained unaware or uninterested. Largoplazo (talk) 18:42, 14 December 2025 (UTC)Reply
Indeed, astronomers only recently got enough data on solar system bodies to figure out that dwarf planets are a distinctive and useful class. People have known that Europe and Asia are one landmass since before the English language existed. It's also not like there are people and countries on Pluto with non-geological reasons for what other solar system bodies they should be grouped with. -- Beland (talk) 18:53, 14 December 2025 (UTC)Reply
Question and alternative proposal. What are the "affected pages" you have in mind? The articles on the continents themselves seem to make clear that there are multiple definitions. The other two places I can think of where this comes up are categories with "by continent" in the name (of which there are hundreds; see Category:Categories by continent) and lists with "by continent" in the name (of which I can find 7). For embedded lists in articles, usually there are just headers for Europe, Oceania, North America, etc., without text that labels those as "continents" or anything else.
Wiktionary on wikt:continent explains there are two modern literal definitions of "continent": one is the geographical definition of a large isolated landmass possibly including islands on its continental shelf, and the other is just a large traditional region of the world. At first I found it mildly disconcerting to have "Oceania" and "Europe" described as "continents", because I had the first definition in mind, but I think over time I got used to Wikipedia using the second definition, and it does that pretty pervasively. I'm not sure it be worth the length increase of changing "by continent" to "by continental region" for a picky semantic reason that's technically not an error.
We have a huge tree of under Category:Categories by region and lots of lists with "by region" in the title. Usually we use "region" because we have to follow economic or linguistic or cultural boundaries that don't follow the continents (like MENA or Hispanic America), but sometimes we use it as a synonym for the continental regions. If we feel the cognitive dissonance problem is worth solving, I would instead propose renaming (or merging) all "by continent" lists and categories to "by region". This has the benefit of being shorter than "by continental region", though for better or worse is less clear on the intended level of geographic granularity. It might be worth considering just deleting some "by continent" categories when we already have the same thing "by country". -- Beland (talk) 00:34, 14 December 2025 (UTC)Reply
The issue of "traditional region of the world" is whose definition are we using for that world view? Like the term Orient, the seven continent model we use is based on a European world view of "traditional regions of the world." (The term orient can be seen as racist or derogatory, and has been replaced in U.S. law by Asian American, and is discouraged from use in British courts.) The other models of continent are all based on a world view, there isn't a way around this problem when practicing regional geography. I'm proposing we adopt the U.N. stance and verbiage as it is the closest thing that exists to an international consensus of human regions (at least that I can find.)
When it comes to the categories, regions have the benefit of being able to overlap. The regions your describing don't follow the continents, but the continents themselves don't have a logical definition they follow. If we were to give aliens a definition of continent and ask them to pick out 7, I do not know of one that results in Europe being a continent and India being a "sub-continent." The 7 continent model is predicated on European exceptionalism and a European world view. The underlying physical geography of tectonic plates does not have a 1 to 1 relationship with human geographic regions, which is not surprising. Importantly, the UN continental regions are broken down into 22 subregions, which contain countries. Using their schema makes categorization really easy and allows us to point to an external source for justification, rather then having editors squabble about what goes where. GeogSage (⚔Chat?⚔) 03:37, 15 December 2025 (UTC)Reply
How would you change, for example, North America? The first sentence already has an explanatory footnote pointing out that it is sometimes considered part of a single continent of the Americas, and links to a full explanation at Continent#Number.
The UN Statistics Division says here that the geographic regions defined by the UN and the continents are not the same thing. For example, it defines the continent of North America as Northern America, Central America, and the Caribbean, but only has Americas, not North America, as a geographic region. It appears they endorse the same Eurocentric 7-continent model as most English speakers, including your example of making Europe a continent and South Asia not.
That page also says that the geographic regions are based on continental regions, implying they are not the same. For example, it groups Turkey with Asia, but by the pretty much universally-agreed-upon definition of Europe, part of Turkey is in Europe. I don't think UN Statistics is saying otherwise; they are just grouping countries based on where they mostly are for more convenient reporting. That might make sense to follow if we wanted non-overlapping continent-based regions for categories, but it would contradict pretty much all reliable sources if we followed it in article text. -- Beland (talk) 04:56, 15 December 2025 (UTC)Reply
Another huge unexpected change if following the UNSD regions would be that Eastern Europe would include all of Siberia and have islands in the Pacific. -- Beland (talk) 05:05, 15 December 2025 (UTC)Reply
To be honest, there are enough eyes on the article that when someone comes along and tries to remove sourced material critical of the DI (which is the usual issue) then it tends to get reverted pretty quickly anyway. Black Kite (talk)21:59, 12 December 2025 (UTC)Reply
I think the most coherent objection to the first idea is that it is instruction creep. It should be obvious that if two articles state contradictory facts, the inconsistency should be resolved. Indeed, we get plenty of complaints about such inconsistencies, and they often motivate corrective edits. An argument that a given factual contradiction should be maintained across articles would go nowhere. Even if you believe in Wikipedia:Verifiability, not truth, the sources from one article could be brought into the other, creating a direct conflict that needs to be resolved, either by a careful editor or talk page discussion.
The question in that RFC, though, was not so much about resolving contradictory factual claims as deciding whether or not a given factual claim was undisputed. That raises the question of whether treatment of facts for neutrality purposes needs to be consistent across articles. That's a much less obvious question, and perhaps one worth talking more about.
The second question, about how consensus decisions are propagated across articles, seems to be a live one. It is partially addressed by WP:CONLEVEL, which mostly just says that a global consensus overrules a local one. Editors to tend to give a topic's primary article more weight when resolving inconsistencies, on the assumption that more people are watching it than minor detail articles. I'm not sure if it would be helpful to make that a rule, given that quality discussions can happen anywhere and sometimes bottom-up decisions work well. Generally I expect that people will eventually get on the same page as arguments and sources are shared across discussion forums, but if things do not go well that can mean multiple contentious RFCs. There's also the practice of notifying other pages that a discussion of interest is happening some other place, which helps reduce conflicts. Would adding more guidance about this reduce some argumentation, or would it give people just one more thing to argue about? Would more rules just create more bureaucracy and delay or obstruct organic consensus-building unnecessarily, or could they help bring more light than heat? -- Beland (talk) 20:57, 13 December 2025 (UTC)Reply
Yes, the treatment of neutrality between articles should be consistent, otherwise we permit single statements/issues to be POV forked all around the encyclopedia. Katzrockso (talk) 21:29, 13 December 2025 (UTC)Reply
I think slight POV forks are okay. Like the articles Zulu Kingdom and Ndwandwe, they cover the same events; the subject of the article should be the centre of the narrative and the subject of sentences, so they end up presenting slightly different perspectives. Kowal2701 (talk) 21:58, 13 December 2025 (UTC)Reply
Never liked WP:OTHERSTUFFEXISTS (an essay on AFD) being cited on article talk pages, is just wikilaywering. OTHERCONTENT should just address that article A's talk page should mainly be used to improve A, and discussions shouldn't be derailed by discussing article B (also, people saying A is fine, B is wrong, have no obligation to go fix B). An essay on why some consistency between articles is often desirable would be good, but there shouldn't be any obligation Kowal2701 (talk) 21:48, 13 December 2025 (UTC)Reply
The TL;DR here seems to be "when one side of a global politics dispute manages to win their POV in one article, should we make it easier for them to spread that to other articles?" Too bad we have to have global political dispute POV wars in the first place. Anomie⚔21:47, 13 December 2025 (UTC)Reply
No, you might recommend guidelines that make it harder to spread decisions from one article to another, or that make it neither easier nor harder but more orderly and less acrimonious. Such guidelines would apply not only to global politics, but every subject, such as how to treat flat earthism, or an alleged crime, or the gender of a real or fictional person (e.g Elliot Page or Kris (Deltarune)), or how to describe the color of something (e.g. the dress).
The danger that a given decision has been made by a non-representative group of people who cluster around a specific point of view is certainly real. If that's a concern, how would you deal with it? We already privilege community-wide discussions over WikiProject decisions and article talk page decisions; is there something else to be said? -- Beland (talk) 23:08, 13 December 2025 (UTC)Reply
Even "community-wide" discussions depend on who sees it and chooses to participate, and I've seen cases in the past (not on the Israel–Palestine topic) where people have come back with new VP discussions every few months until they managed to get their way. You don't have to go to the meta extent of https://xkcd.com/545/ to wind up with things we can't cover neutrally; you just need enough activist editors to polarize every discussion on a topic so it always becomes about "right" vs "wrong". I don't have any solution to the problem either. At best I usually just hope to bring a little more attention to the fundamentals than the surface topic, or to point out when something is going completely off on a tangent. Usually I don't seem to succeed much though. Anomie⚔23:48, 13 December 2025 (UTC)Reply
I disagree with your reading of what is occurring here. The Gaza genocide RFC had two sides: those following our guidelines on sourcing and following the strongest (scholarly) sources, and those insisting that the genocide is debatable because political actors with vested interests / significant conflicts of interest claim otherwise. voorts (talk/contributions) 23:09, 13 December 2025 (UTC)Reply
Should there be a Wikipedia guideline on consistency across articles? (referring to substance, not style) No. We already have a guideline on levels of consensus. Using the RFC that prompted this discussion as an example, the editors arguing that the Gaza genocide RFC should not control are ignoring that it was a heavily advertised RFC that was open for several months.
Should there be guidance on how to propagate consensus across articles to assure consistency? Same answer.
If the most recent RfC at Talk:Israel had been closed the other way, would you believe otherwise (e.g. that we need a guideline)? I'm not convinced that the result of that RfC was inevitable and I can certainly conceive of it having gone otherwise, as I don't think consistency as a desideratum can be inferred from existing P&G. Katzrockso (talk) 23:24, 13 December 2025 (UTC)Reply
I think if the RFC at Talk:Israel had gone the other way, it would have been because editors were ignoring a higher level of consensus (i.e., a discussion that was advertised for a lengthy period at T:CENT and was open for over 3 months, as opposed to a discussion that wasn't and was open for only 1 month) and asserting arguments that were rejected in that discussion (i.e., that we should not state something in wikivoice because politicians etc. deny its truth). voorts (talk/contributions) 23:37, 13 December 2025 (UTC)Reply
65 editors participated in the second RfC, of those 47 didn't participate in the first RfC. I think it's possible some whole have had they been aware of either the original RfC and/or it's impact on other articles. Springee (talk) 23:58, 13 December 2025 (UTC)Reply
Based on the replies a lot of editors didn't agree. Putting something in Wiki voice is an editorial choice as editors decide when a claim is something we should attribute vs put in wiki-voice. We have a conflict of facts if, both in wiki voice, article A says, "... is X" while article B says "... is not X". It isn't a conflict of facts if article A says, "... is X" while article B says, "... is X according to...". Springee (talk) 00:18, 14 December 2025 (UTC)Reply
A while back there were concerns projects were making decisions about content for the articles associated with the project. Thus, a RfC at project Automobile would dictate content for a specific make/model vehicle, superseding local consensus. There is merit to this idea and if Wikipedia were a conventional encyclopedia that would make sense. We aren’t that and it’s not always clear to editors at article B that something happening at article A is going to affect B.
Codifying that we should treat a “fact” found at article A as true across all other articles is both a problem of ensuring all voices are truly heard and also avoiding inadvertent/deliberate gaming where editors use content among sympathetic editors at article A and now can force it into all other related articles.
As Beland noted this question is born of a recent pair of RfCs. The older RfC (closed in October) had !votes from 82 editors. The later RfC had 65 !votes. Only 18 editors participated in both. This suggests that an additional 47 editors at RfC B may have had a view on RfC A. In reviewing article B’s talk I didn’t see an announcement for the RfC at A. We need to keep discussions about article content on the article’s own talk page. Springee (talk) 23:51, 13 December 2025 (UTC)Reply
The core issue, as I see it, is a procedural fairness one. How are editors focused on one article supposed to (or assumed to) know about a consensus formed on another article whose consensus is then applied to the article they pay attention to? WP:LOCALCONSENSUS seeks to address this, but there is no one-size-fits-all approach. There has been reference to T:CENT/WP:CENT, but the template does clearly advise an editor that the discussion at a different article will be viewed as binding on the article that the template is posed to. Most editors aren't even aware of WP:CENT, which, after all, is just an information page. For other things that have truly broad impact, such as administrator elections, we use a notice on talk page system; I don't see anything similar being proposed here that addresses the role that advance notice plays in truly setting consensus (let alone the broader point that there needs to be some mechanism by which WP:CONSENSUSCANCHANGE. Coining (talk) 00:09, 14 December 2025 (UTC)Reply
How are editors focused on one article supposed to (or assumed to) know about a consensus formed on another article If their interest is in article A and they decide to include content about article B, then it stands to reason for them to familiarise themselves with the article they are linking to. M.Bitton (talk) 00:14, 14 December 2025 (UTC)Reply
That perhaps makes sense in one direction -- followers of the Gaza genocide article, writing about Israel, might feel compelled to follow the Israel article (though I'm not sure all that many do), but editors following the Israel article, who might not be writing about or including material about the Gaza genocide in the Israel article, are not nearly as likely to follow Gaza genocide article. This discussion is of course about a lot more than just those two articles, but it does demonstrate that even if some editors' interest is in article A and they decide to include content about article B it doesn't logically follow that editors interested in article B are likely to follow article A. Coining (talk) 02:45, 14 December 2025 (UTC)Reply
Ok, but how many watchers of the Israel article are adding a sentence about the Gaza genocide and therefore following the Gaza genocide take page? I suspect very few, which is why it's not appropriate to assume that a discussion on one page provides notice to watchers of another page. Coining (talk) 03:26, 14 December 2025 (UTC)Reply
Would it be helpful to have an up-front expectation that certain RFCs would be noticed on the talk pages of articles that might be affected? That could be a handful, but it could also be hundreds or thousands or millions.
It seems like any reasonable notification system is going to miss people who could want to give an opinion on a given question, but at some point adding more people to a conversation isn't going to raise any new arguments and isn't going to change the outcome.
There's also the question of canvassing...we want to find people who are experts on a given topic so they can make intelligent arguments, but we also want a diversity of points of view. The editors involved in specific articles can be highly non-representative of readership and editorship, so letting an RFC proposer pick a bunch of talk pages to ping might not be the best approach?
What we use right now are WikiProjects, the RFC notification system, and centralized discussion listings. Is it reasonable to say that we don't need to notify Talk:Israel about a major discussion about the Gaza war if the WikiProjects on Palestine and Israel have been notified? -- Beland (talk) 03:49, 14 December 2025 (UTC)Reply
I do agree that at some point the discussion is likely to have all the different reasons it will get. But, if after that, if the discussion comes down to a head count, then casting the widest net, getting editors from all the potentially impacted articles is important even if only to get that show of hands. This raises a question, what articles/projects should be contacted? Which articles will be sufficiently impacted as to warrant notification? That can be difficult. For example, I did a lot of my early editing on automotive topics and I followed project Automobile. What I didn't do was follow the article that used to be called Automobile. If I recall that was a relatively small RfC where the !votes of just a few editors might have swayed the discussion. Despite being active on the project, I wasn't aware of the rename request. If these things are really going to be community wide decisions we need a proper community forum and prior to starting the RfC editors as a group should agree which articles/projects/noticeboards should be notified. Springee (talk) 04:42, 14 December 2025 (UTC)Reply
Turning to Talk:Car/Naming#RM (September 2014), it appears that was not an RFC, but a Requested Move from "Automobile" to "Car", in which over 20 people participated. According to Wikipedia:Requested moves, there's a mechanism that automatically notifies associated WikiProjects when one of these is filed. Perhaps that mechanism didn't exist at the time and that problem is now solved? (We also already have a policy on consistency of article titles.) -- Beland (talk) 05:19, 14 December 2025 (UTC)Reply
I think (and it's been a while) the issue was I was watching the project talk page but didn't know about joining the project to get alerts. The move triggers an alerts on the project page but those are autogenerated and don't trigger the watch list. Springee (talk) 05:47, 14 December 2025 (UTC)Reply
Editors interested in a topic usually have multiple relevant articles on their watchlist, so there's a high chance they already know about consensus formed on article A when commenting on article B's talk page if the two are related. SuperPianoMan9167 (talk) 00:18, 14 December 2025 (UTC)Reply
I don't know if there is a way for admins or others to tell this, but I would be surprised if even 20% of editors with Israel on their watch list also have Gaza genocide on their watch list. (I'd be decently surprised if it was 20% in the other direction as well, as I think editors are much more idiosyncratic, especially compared to frequent talk page commentators.) Coining (talk) 02:46, 14 December 2025 (UTC)Reply
I'm sure a lot of editors also just never use watchlists (like me).
One thing I've seen happen in the past is someone wanting to make a change that affects a lot of articles starts a centralized discussion. Participants are uncomfortable making a big change because they don't know all the individual circumstances it would affect and don't know if page editors unaware of the central discussion would be upset. So the proposal fails and the proposer is encouraged to start building consensus at the page level. If that succeeds, they then take the conversation to more pages and can point to the decisions so far and ask if the same trend should be continued on more pages. Sometimes the answer is yes and the big change gets made. Sometimes the answer is that certain pages are opposed and others are supported, and a new rule arises that distinguishes the two.
I've had this happen with deleting old century and decade articles, for example. Get near enough to the present and consensus flips from merge to keep. And style changes sometimes. The decision of the first page is in no way "binding" on other pages, but it can be persuasive. -- Beland (talk) 03:18, 14 December 2025 (UTC)Reply
If you think about statements in different articles that address the same specific subject as if they are competing to optimize something, let's say the various policy compliance requirements, the process of editors (with their individual source searching and sampling biases) nudging things towards better compliance over time relies on allowing some variation, mutation etc. across the project. I think imposing/enforcing cross-article consistency probably works well when there is not much variation in what sources say about X. When there is a lot of variation, maybe cross-article consistency isn't such a good idea, or at least it might have unintended consequences.
I saw similar sentiments on Wikipedia talk:Consistency proposal, and I'm starting to think it might be worthwhile to say how much consistency is actually too much.
One example of a fact where sources disagree is whether or not Puerto Rico is part of the United States. A while ago I helped negotiate a talk page compromise for the introduction of United States, so it says that the US "asserts sovereignty over" territories including PR. This avoids complaints that the US "consists of" 50 states and territories like PR is incorrect according to various sources, and avoids complaints that anything that implies Puerto Rico is not part of the United States is xenophobic and incorrect according to various sources. The article Puerto Rico does not use the "asserts sovereignty" language. It says PR is "organized as an unincorporated territory of the United States". If you look at the exact wording, you might consider this inconsistent treatment. I think it is consistent with the general compromise that Wikipedia remains neutral on the factual question, and that's the level of granularity I think is important. Given that compromise, is it undesirably inconsistent that 1988 Summer Olympics lists both Puerto Rico and the United States as participating nations without explanation? (Olympic Games does at least explain the situation.)
I'm curious if there are other examples you had in mind or could shake from the trees that would illustrate the range of scenarios relevant to this concern? -- Beland (talk) 04:54, 14 December 2025 (UTC)Reply
I don't think a consistency proposal would require that the wordings of a statement about a topic in two different articles need to be identical or even extremely similar. But a statement that is made in wikivoice in one article should be made in wikivoice in another article, while a statement that is attributed in one article should be attributed in another article, insofar as these are statements about the same information (i.e. we shouldn't have "According to A and B, X is true" in one article and "X is true" in another article). We also should not have articles that directly contradict each other.
Something is a fact or prominent enough viewpoint about a fact that it can be stated in wikivoice in one article and consequently is a fact/prominent enough viewpoint in all articles, or it is not a fact/prominent enough viewpoint to be stated in wikivoice in any articles. And similarly, it is either the case that X or ~X, we cannot have a statement of fact in wikivoice in one article that directly contradicts the claim in another article. WP:VOICE, WP:FALSEBALANCE make no mention of a particular page/article that would influence the evaluation of a statement as a fact/opinion or whether the relative prominence of a viewpoint can vary by article (such a question doesn't even make sense, given that the relative prominence of a viewpoint is determined by sourcing and not an article).
I'm not sure what Sean.hoyland's point is here. Are they saying that we should be able to say X in one article and ~X in another? Or are they saying that we should be able to say "According to A and B, X is true" in one article and "X is true" in another?
This doesn't mandate that if one article states X in wikivoice, that any other particular article needs to include that statement X in the article or even make a substantially similar claim to X, but that if another article includes the direct/exact claim/fact/opinion X, it needs to be consistent with the rest of Wikipedia.
As for your example, Puerto Rico is not listed as a "participating nation", but as having a separate "National Olympic Committee". American Samoa also has its own National Olympic Committee, as did several other dependent territories. The page National Olympic Committees goes over the specificities of what NOCs are now and how they were formed in the past. To the extent that the page confuses NOCs and nations, it should be changed to reflect what the IOC states, which refers to "teams" and "NOCs" rather than "nations" or "countries" [23]. Katzrockso (talk) 08:12, 14 December 2025 (UTC)Reply
I guess my point is that compliance with the things we value encoded in our policies and guidelines is emergent, bottom up, not top down. It's an ongoing multi-trajectory search in a giant space of possibilities. I'm not saying we should be able to say X in one article and ~X in another, I'm saying it will happen and it is not necessarily bad. There will be cases where editor A says X in one article and editor B says ~X in another (and they both have some kind of truthiness policy-wise), and that can help editor C who comes along later. I guess my concern is that imposing consistency could have a hidden cost if it reduces variations that editor C can select from and combine. One way I sometimes imagine Wikipedia working is for every statement to be a standalone object, a string that carries with it everything it needs to comply with policy, all the sources etc. and the addresses of all of the places it is used across the project. Articles would be sets of these objects. Each statement would have variations made by different editors. The statements could be in competition with each other to maximize policy compliance. Change one and it automatically changes everywhere it's used across the project. That's never going to happen. But this question of finding the right balance between consistency/stability over time and leaving space for variation/optimization is a tricky question (possibly already solved by things like the influenza viruses with their cool segmented genomes. We probably need to steal someone else's solution to this type of problem. Not a tremendously helpful addition to this discussion, but good luck. Sean.hoyland (talk) 14:52, 14 December 2025 (UTC)Reply
Isn't the point of consistency to say that editor C should resolve the conflict between X and not-X, possibly by saying Y in both places, not necessarily in exactly the same words? -- Beland (talk) 15:25, 14 December 2025 (UTC)Reply
How often do we have cases where two articles are directly contradicting one another? Debating if something should/shouldn't be in Wiki voice comes up a lot and is something that often shows up in cases like a BLP. In the actual BLP a contentious LABEL is attributed. However, in an article that mentions the BLP subject by name but doesn't cover the person in detail the LABEL is applied in wiki-voice. That may be a BLP policy issue but rarely it doesn't represent conflicting facts. In both cases, presumably, there are citations that support the label. What would be bad is to say, at one article we had a RfC that said apply a contentious label in wiki-voice and now that label is stuck for all time and editors are not allowed to open a RfC at another article where the label is used. Springee (talk) 15:57, 14 December 2025 (UTC)Reply
That isn't surprising. A good question with those is how to align them. Do we default to which is first? If editors at B don't agree with the outcome at A should they hold their own RfC and if so, which RfC should we follow or, how misalligned is OK? Springee (talk) 17:04, 14 December 2025 (UTC)Reply
My advice would be for an editor to do a fact-check, and be bold and fix the problem based on reliable sources. If there needs to be a discussion or eventually an RFC, hold it on one article talk page but link from the other so there are no conflicting outcomes.
My advice, in detail:
Fact-check the contradictory claims against reliabile sources, preferably checking beyond the sources cited to confirm they are representative.
An apparent contradiction can be a sign that the situation is complicated and need a more nuanced explanation.
If there is a clear resolution to the contradiction, be bold and update both articles, removing the tag. Link to the other article in your edit summary. Update any existing talk page discussion with the outcome.
If you are unable to come to a clear resolution, want input from other editors, fear changes would be too controversial, or your edit is reverted, start a discussion on one of the talk pages. Link to the discussion from the other article's talk page so interested editors there can participate.
Insofar as there are these discrepancies with labels in BLP, they should be resolved to be consistent. Are you suggesting we can come to a clear consensus on a BLP that a label should be attributed, but it's fine to use it without attribution elsewhere on Wikipedia? I think that would be extremely detrimental to the encyclopedia. Katzrockso (talk) 05:36, 15 December 2025 (UTC)Reply
I'm saying it will happen and it is not necessarily bad I am saying it is bad, unless you are a denier of the law of the excluded middle (not that this is inherently a bad thing). Insofar as articles contradict each other, that is an issue that needs to be resolved, not something that should be retained.
Realistically, a consistency proposal is not going to mandate that editor B, when editing an unrelated article, check every possible article on Wikipedia for a statement before adding any information to an article. It does tell us, however, that when we have statements or information that conflict, that this needs to be resolved (maybe WP:EVENTUALLY, by adding a tag/category) rather than ignored or accepted. Katzrockso (talk) 05:34, 15 December 2025 (UTC)Reply
The IOC also refers to these groups as "nations" sometimes, e.g. in the term Parade of Nations. There are also multiple definitions of "nation" (wikt:nation) - a sovereign state (as commonly used in American media) or a community of people sharing a culture or language or ethnicity or something like that. -- Beland (talk) 08:57, 14 December 2025 (UTC)Reply
Would any sort of guidance be helpful in using those terms consistently, or do we just need diligent editors to spot problems? -- Beland (talk) 09:12, 14 December 2025 (UTC)Reply
Mostly, we need diligent editors. I can say that in almost all cases, we should not use the term nation-state, as it is mostly a theoretical term (and one that has been the foundation of multiple genocides). Nation and country are both often used colloquially as a synonym for sovereign state, including in the poorly named United Nations (I suspect this name was chosen because "United States" was taken). A nation is a group of people that is relatively homogenous from a cultural/ethnic perspective, but does not necessarily control the administration of government. A state is a political entity that regulates society and the population within a definite territory. A sovereign state is a state that has the highest form of control over its territory (this is what we mean most of the time when we talk about "countries"). A Nation-state is a sovereign state with only one nation (the attempt to achieve a nation state can result in ethnic cleansing and genocide). Calling a sovereign state a nation-state is sort of a slap in the face to the existence of minority populations that live there. The United States is a Federation of federated states with multiple recognized Native American nations, the farthest thing possible from a nation state. The "One nation under God" is a bit of a play on words to say we all share a cultural identity as "Americans," but is still a bit cringe even if you consider perspective that the identity itself is one of diversity and inclusion. If I were making a bot, I'd start with swapping all mentions of nation state to sovereign state. The word country is quite ambiguous, like it can refer to essentially any land area, and is often used to refer to the hinterland of urban areas (Taking a "drive in the country"). In most places, country is fine from context clues, but a more technically correct term would again usually be sovereign state. English is really bad at clear language to describe places, hill vs mountain is poorly defined, sea and lake are used inconsistently, river and stream are used inconsistently, etc. etc.. Every time a clear term is used, it is adopted colloquially and then loses the clarity. GeogSage (⚔Chat?⚔) 23:59, 14 December 2025 (UTC)Reply
Well, according to this search, we use "nation-state" over 4,600 times. A bot substitution would not be a good idea, as in most cases we actually do specifically mean a sovereign state associated with an ethnicity. -- Beland (talk) 02:02, 15 December 2025 (UTC)Reply
Sovereign states associated with a single ethnicity are mostly theoretical, and it is a very loaded term associated with erasing minority identity. There is maybe one or two "nation-states" in the world, Iceland has a solid argument, but even countries as homogenous as Japan have minority populations like the Ryukyuans (who despite being a "a distinct genome-wide cluster within the Japanese people", having their own dialect, and distinct culture are not recognized by Japan as a minority group). The only reason people use the term nation-state is to sound smart or to invoke ideas of national purity. GeogSage (⚔Chat?⚔) 06:51, 15 December 2025 (UTC)Reply
Well, that's certainly a strong opinion, but not something that can be a Wikipedia guideline. If you want to audit those 4,600+ uses of the term, feel free. -- Beland (talk) 08:46, 15 December 2025 (UTC)Reply
...The concept of a nation state is incompatible with a "multi-ethnic" sovereign state. "The model of the nation-state implies that its population constitutes a nation, united by a common descent, a common language and many forms of shared culture." The concept of the nation state was an ideal used by imperialists European countries when they drew their land boarders, and attempts to achieve that ideal have lead to genocide and ethnic cleansing. GeogSage (⚔Chat?⚔) 19:22, 15 December 2025 (UTC)Reply
Confidently wrong, the best kind. So many results on Google Scholar. FWIW African nationalism was the exact opposite of some "imperial tool", it aims for political stability/no civil war.
Loh 2021: Every country in Southeast Asia is a multi-ethnic nation-state.
Latest comment: 3 days ago3 comments3 people in discussion
Similar to WP:WIR, Wikipedia has a known issue of systemic bias against Indigenous/First Nations people and leaders. I'd like to propose a new caveat to the Notability of People policy so that Indigenous tribal leaders have lower bars to entry than normal politicians. Legally (at least in Canada), native tribes are considered semi-sovereign, so their leaders are something akin to heads of state. While that is obviously not how they are treated on a practical level, it does make sense to think of them as something more than just a 'local elected leader' or city council member. And I am going to bring up the specific example of Lynda Price, who was in office for cumulatively a decade and has a lot of local reporting about her and her family, whose article was recently proposed for a deletion because 'local sources weren't notable enough'.
I would propose that any indigenous tribal chief that has a good amount of secondary sources about them (not just election results, but actual information) be considered notable enough for an article. TimeEngineer (talk) 09:05, 14 December 2025 (UTC)Reply
Any topic with a "good amount of secondary sources" meets the GNG. No need for a carveout. I think what you're really looking for is for the leaders of sovereign tribes to be considered automatically notable under NPOL, which is something I could get behind. But again, arguably these already are "national or state/province–wide office", so I'm not sure we need a new rule. Toadspike[Talk]10:27, 14 December 2025 (UTC)Reply
Yes, I generally see stuff like that as spam oriented, even if not intentional. There is no reason to cite a modern in print edition. Unless it's citing added material like a Foreward, footnotes. The same goes for book cover images, and the ISBN field in infoboxes or bibliography lists. -- GreenC03:23, 15 December 2025 (UTC)Reply
There are reasons to cite a modern edition because you are supposed to cite the edition you have, not the original. In infoboxes and covers and such we do the most prominent edition, which is not always the first, see for example And Then There Were None, which does not use the first edition. PARAKANYAA (talk) 02:44, 16 December 2025 (UTC)Reply
That makes sense. Even if a book purports to replicate the original exactly, who has checked that it does? Though, if that's all one has available, that's all one has to go by. On the other hand, if the original is online, an editor should use that as the source after checking that, like the more recent edition, it verifies the content. But in that case I mean a photocopy of the original, as Google Books has for many old books. If it's been OCRed, who knows how reliable it is? Largoplazo (talk) 03:22, 16 December 2025 (UTC)Reply
Latest comment: 16 hours ago10 comments5 people in discussion
Anyone who spends any length of time at the Teahouse or Helpdesk will have encountered two kinds of COI editors;
The bright-eyed, naive one who hasn't tried to make their COI article yet and comes to ask how to maximise their chances of success
The frustrated one who's already had their draft declined 6 times in the past 20 minutes and can't wrap their head around why (because they refuse to click the link people keep sending them to WP:GNG)
My question is; shouldn't we just immediately turn both of these people around at the door as blatantly WP:NOTHERE? Anyone whose express purpose for being here is to try to post a particular COI article is, by definition, not here to build the encyclopedia. Those who try to engage with policies and guidelines usually only do so with the absolute minimum amount of effort necessary to get their draft over the line (which obviously normally never succeeds), which is basically just WP:GAMING. I have yet to see a single positive thing come from this type of editor.
So, if someone shows up and their first question is "how do I get my autobiography/company's article/etc published" surely our only reply should be "Indeffed as NOTHERE" to avoid wasting everybody's time?
A related but somewhat separate idea; how would everyone feel about a guideline proposal for a three-strikes-rule about drafts? My idea would be something like if your draft receives three declines for the same reason in the space of a week then you obviously aren't meaningfully engaging with feedback and the draft should just be outright rejected until someone else wants to make it. My heart goes out to those heroic AfC reviewers telling someone for the umpteenth time that Example Inc doesn't meet our corporate notability guidelines and to please for the love of god provide some meaningful sources, and I'd love to make their life just a little bit easier. Athanelar (talk) 09:13, 17 December 2025 (UTC)Reply
Both of these sound overly heavy handed. I think the rules are already a bit to strict on things, if something passes verification, it should not matter who wrote it. People who are close to a topic in real life often have the knowledge needed to write a good encyclopedia article on the topic. If a draft is rejected 1000 times but at time 1001 it passes, then it has succeeded. Other publications don't insist that bibliographic content be written by people that have no connection to the subject, in fact in academia many memorial articles are explicitly written by people who knew the subject well. I understand there is a concern about people posting promotional content about themselves, their job, or others but the insistence that we hope someone who has no connection with notable topics will stumble upon it and decide to write a good article on the topic ultimately gets in the way of building an encyclopedia. GeogSage (⚔Chat?⚔) 09:22, 17 December 2025 (UTC)Reply
My point is that it's entirely possible for someone with a COI to contribute meaningfully; but the people likely to do so would also be contributing in ways not associated with their COI.
If someone shows up with a single-minded focus on getting their COI article published, I think they're NOTHERE by definition. I've never seen any of those types of editors contribute meaningfully to anything outside of their COI except for in a GAMING-y way, performing a few minor edits using the link suggestion feature or something just to give the appearance that they're doing something other than their COI.
I'm not saying "block anyone with a COI" i'm saying "treat people who are only here to work on their COI as not here to build the encyclopedia" Athanelar (talk) 09:29, 17 December 2025 (UTC)Reply
If a draft is rejected 1000 times but at time 1001 it passes, then it has succeeded. If reviewers' time and attention have been called for 1,000 times to no avail, particularly by someone who's paying barely any attention to the feedback, it just isn't worth it. Nobody here has signed on to babysit a single user that extensively, especially when they're doing something that is "strongly discouraged" to begin with. In that respect, it's like someone who does make useful contributions but also has been listed, justly, at multiple noticeboards multiple times over a period of several years. Eventually consensus builds that, despite the contributions of value that the user has made, they just aren't worth the damage or disruption that has come along with them. Largoplazo (talk) 13:45, 17 December 2025 (UTC)Reply
No. We already block COI editors if they are being disruptive. But we should never block people simply for asking a question about how to create an article. Toadspike[Talk]10:53, 17 December 2025 (UTC)Reply
I prefer those two kinds of COI editors than the kind that pays a third party/sockpuppets to create or edit their articles for them. Some1 (talk) 12:29, 17 December 2025 (UTC)Reply
I do keep wondering what the aftermath is after an SEO consultant charges a client for a Wikipedia "placement" only to fail at it. Does the client get their money back? How often does the SEO stop returning calls? Does the client leave the SEO consultant a bad Yelp review? Largoplazo (talk) 14:05, 17 December 2025 (UTC)Reply
We can't do that for the first type. We assume the user has asked in good faith and don't presuppose that they're going to ignore the guidelines, once they've been directed to them, or the advice given directly to them by whoever responds. Let's not create a culture of pre-crime.
For the second type, whether the issue with the draft's topic is notability or not, I think that after a certain number of submissions of drafts with updates that don't come anywhere near reflecting an understanding of the reasons given so far for rejection, or with no updates at all (I've seen resubmissions of draft with no content changes since the previous submission), the user is being disruptive in the same way that edit warring is disruptive, by placing unwarranted demands on other users' attention because they refuse to take No for an answer or otherwise refuse to listen. I'm not sure that it's appropriate to set a hard limit on the number of unsuccessful submissions of a draft, though, without taking into account the extent to which the user has exhibited an understanding of the previously explained shortcomings through edits to the draft since the previous submission. (In the notability case, this could include bona fide attempts to attach references that they might reasonably, even if misguidedly, demonstrate notability.) Perhaps a report to WP:ANI would be the way to go, as long as the frustrated reviewer has previously warned the user of the possibility of that and the what the justification for it would be. Largoplazo (talk) 14:01, 17 December 2025 (UTC)Reply
Latest comment: 45 minutes ago4 comments2 people in discussion
I have a question about plot summaries. Are they WP:OR or not? If they are WP:OR, should we remove or exempt them? Could we find sources for them? If they don't qualify as WP:OR, then how, considering the plot summaries I've come accross don't have sourcing. ~2025-31733-18 (talk) 05:55, 18 December 2025 (UTC)Reply
.svg){kind=link}
