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

Should there be a recommended limit on a talk page size? Ritchie333 ^{(talk) (cont)} 08:59, 14 October 2025 (UTC)[reply]

For many years, this guideline page has contained the text, "As a rule of thumb, archive closed discussions when a talk page exceeds 75 KB in wikitext". Since the start of this year, this has been removed, readded, removed, readded and finally removed again. The previous discussion from March is here, and to be honest, I don't see a consensus. In fact, the back and forth with the few participants there very much suggest there is not a consensus. So unfortunately, I think we're going to have to have an RfC on it.

The principal reason, as I see it, for using 75K as a general maximum talk page size is derived from the corresponding guideline for article sizes, and the principal driver for having it is that large pages can't be viewed or edited easily on a smartphone.

The principal reason, as I see it, for not having a maximum talk page size is that talk pages, particularly user talk pages, should not be subject to third-party editing by executive fiat and that Moore's Law suggests the problems with smartphone capacity will ultimately resolve itself over time.

As a balance between these two viewpoints, I am sympathetic to arguments that 75K is too low a barrier for most modern devices, so rather than a simple "yes/no" poll, it would be better to come up with some options. For the purposes of this RfC, these are:

• Option A - Retain the status quo "As a rule of thumb, archive closed discussions when a talk page exceeds 75 KB in wikitext"
• Option B - Change to "As a rule of thumb, archive closed discussions when a talk page exceeds 150 KB in wikitext"
• Option C - Change to "As a rule of thumb, archive closed discussions when a talk page exceeds 250 KB in wikitext"
• Option D - Change to "As a rule of thumb, archive closed discussions when a talk page exceeds 500 KB in wikitext"
• Option E - Remove the size clause entirely

• Option E – remove entirely. Tl;dr: instruction creep. It is pretty clear nobody paid one bit of attention to this useless rule until now. It is one of those completely arbitrary instructions, where any number you pick has no basis in reality, and is better left out. Anybody for 249kb? Let Talk page users at different articles decide for themselves what is best. Why replace it now? Are we going to start expecting compliance where we didn't before, and file warnings on user Talk pages for those who archive too soon? Just remove it, and trust people to do the right thing, or organize locally if there's a need to. Mathglot (talk) 06:51, 20 October 2025 (UTC)[reply]
• Option F - keep the current wording for WP:USERTALKSIZE: The length of user talk pages, and the need for archiving, is left up to each editor's own discretion. That is, whatever you decide for talk pages in general (WP:TALKSIZE) it wouldn't apply to user talk space specifically. While I too want to reduce instruction creep, I oppose option E: removing the current wording will only increase uncertainty. People will search for guidance and saying nothing at all will only waste people's time as they keep looking for what's no longer there. In contrast, I find the current wording to be a good compromise, hence I choose Option F. As my secondary preference, Options C or D: if we must have an instruction with specific limits, let us at least increase values that were instituted over ten years ago (the 75 KB figure was added in 2015). CapnZapp (talk) 10:07, 20 October 2025 (UTC)[reply]
• Option E. I've explained my thinking in the discussion section, below, and I might as well enter a straw poll opinion now. I don't think a consensus exists, or will exist, for a number, because there are too many other common sense factors that apply. I agree with CapnZapp, just above, that if we end up with a number, it should be a high number, and not a number that was determined long ago, given the speed with which technology advances. As for "Option F", my understanding of the RfC question is that Option E would just remove the number, not the entire section. --Tryptofish (talk) 22:03, 20 October 2025 (UTC)[reply]

  I can only interpret "Remove the size clause entirely" to mean "Say nothing on the subject of size at all". I contacted the RFC starter User:Ritchie333 but he flatly refused to engage in constructive discussion about how to clarify this RFC. CapnZapp (talk) 07:51, 21 October 2025 (UTC)[reply]

• Yes There should be a limit but I have no preference to the size. Too long talk pages lead to long scrolling distance, longer than needed loading times and inhibits editors with worse hardware. Rolluik (talk) 17:26, 21 October 2025 (UTC)[reply]
• Not E, not "F" There should be a recommendation. It needn't be a hard limit, and may be a range, but we should offer some indication as to what "too long" means rather than leaving it completely undefined. And we don't need to get bogged down in trying to account for all aspects of "page weight" or trying to figure out the vagarities of load time on different devices and connections as happened in the March discussion; it's just a rule of thumb, after all, not a hard requirement. As for what specific number or range, 🤷 75KB–200KB? I can't say I much care, but 250 or 500 seem a bit too high. I also oppose the suggestion that user talk pages should be exempt from the recommendation that long pages should be archived or otherwise cleaned up. Anomie⚔ 17:17, 24 October 2025 (UTC)[reply]
• Option A 75kb might be an old arbitrary number, but there's no point in increasing it when setting up archiving should be standard procedure for anyone planning to remain even a semi-active Wikipedian. The fact remains that if you go above that size, you should probably be archiving, even if it doesn't necessarily start to lag browsers until later on. It's meant to be a rule of thumb, not calculating the hard limits of browser displayability. ᴢxᴄᴠʙɴᴍ (ᴛ) 19:41, 4 November 2025 (UTC)[reply]
• Option E I think recommendations like this become dated fairly quickly, and that they're suggested here at all seems to encourage people to "act" on them (even in good faith) and run into people objecting. As above, it's instruction creep. If there is a disagreement on a non-user talk page, allow editor consensus to determine the correct value on a case-by-case basis. —Locke Cole • t • c • b 17:37, 5 November 2025 (UTC)[reply]
• Option E Abaciscus (talk) 15:12, 9 November 2025 (UTC)[reply]
• Option E: We have seen this play out before with the whole "mobile version of this website" situation. Cell phone makers made web-enabled flip phones with tiny screens and under-powered processors. Thousands of web sites rushed to accommodate the new phones, just in time for the cell phone makers to start selling smart phones with huge screens and powerful processors. And even of we do limit the size of talk pages to accommodate underpowered phones, will Reddit? Will YouTube comments? Will Facebook? Anyone owning such a device will already be used to the web sucking for them.Articles on the other hand, have a different limitation; human attention. No matter how powerful your PC or smart phone is, if our article on Squirrel Girl took an hour to read and a hundred pages to print, it would not be an improvement for the reader. --Guy Macon (talk) 17:16, 17 December 2025 (UTC)[reply]
• Oppose E, and enforce a limit, though I don't particularly care where the numerical value is set. This is a basic matter of accessibility: talk pages are intended for communication, and if editors struggle to load them they are failing at their primary purpose. Just as we constrain any number of other talk page behaviors - Wikipedia:Signatures comes to mind - this is necessary for accessibility, and we know it's a problem for some people. Vanamonde93 (talk) 17:43, 17 December 2025 (UTC)[reply]

  I agree with this. Just because we can predict the problem will shrink some time in the next decade doesn't mean that we should ignore it. Cremastra (talk · contribs) 18:31, 17 December 2025 (UTC)[reply]

• Option E. I see no reason why we should have any sort of limit on the maximum size of a talk page. (Also, for reference, WP:ANI is just under 500kb right now.) Sugar Tax (talk) 23:43, 17 December 2025 (UTC)[reply]
• Option A or B: While a limit is probably not strictly necessary for reading larger pages (Moore's law, etc.), editing them becomes a whole other issue. Even on pages that aren't that extreme, trying to open the full-page editor and enabling syntax highlighting on a large talk page will absolutely bog down even a fairly modern phone. --rchard2scout (talk) 16:04, 18 December 2025 (UTC)[reply]
• Option E Polygnotus (talk) 02:41, 19 December 2025 (UTC)[reply]
• Option E per the many comments above. JoJo Anthrax (talk) 03:05, 19 December 2025 (UTC)[reply]
• oppose e, and enforce a limit. overly long pages are a problem for a significant subset of editors. why some editors insist on making life difficult for them is beyond me. ltbdl (jump) 14:04, 19 December 2025 (UTC)[reply]
• Comment: Since option E has gained at least some traction, once more I would like to remind everybody that Option E can be interpreted two ways: E1) remove everything related to discussing talk size, including the current "The length of user talk pages, and the need for archiving, is left up to each editor's own discretion." Essentially, say nothing on the subject of size at all. E2) don't commit to any number (whether 75K size or any other). The RFC starter refused to clarify. CapnZapp (talk) 14:05, 19 December 2025 (UTC)[reply]

  @CapnZapp Yup, and because of that problem it is a bad RfC that cannot be used to gauge consensus.

  For example @Ltbdl: above clearly thinks that option E means that we are making life difficult for people with terribly old computers/phones.

  The problem with a limit of KB of text is that 75KBs of image embeds of the largest images on Wikimedia Commons will slow down everything, but 75KB of text in a collapse template is very quickly rendered, even on a very old device. I had an entire discussion where I explained such things over at Wikipedia_talk:Talk_page_guidelines/Archive_17#Limit but it was not a productive discussion. Polygnotus (talk) 14:11, 19 December 2025 (UTC)[reply]

  terribly old? i have an one-year-old device and it struggles to load pages more than 250 kilobytes in size. ltbdl (love) 14:17, 19 December 2025 (UTC)[reply]

  @Ltbdl I am a nerd. Can you share the make and model of the device please, and which browser you use? And can you give an example of a page on which this regularly happens (WP:ANI?) That can be useful when diagnosing the problem. Thanks, Polygnotus (talk) 14:22, 19 December 2025 (UTC)[reply]

  And would you be willing to answer some more questions in the future? I could ask a nerd to contact you who can actually fix this problem. If we understand the bottleneck it is much easier to find a solution. Polygnotus (talk) 14:22, 19 December 2025 (UTC)[reply]

  thanks for the offer, but i'd rather not. ltbdl (master) 14:30, 19 December 2025 (UTC)[reply]

  @Ltbdl Yeah that is the problem. If no one is able to diagnose the problem, then it won't ever get fixed. I even proposed asking the WMF to buy some old devices and test pages of various sizes, but if people are completely unwilling to help the WMF then it is unreasonable to expect them to understand the problem by looking at tea leaves, thrown animal bones or weather patterns. Polygnotus (talk) 14:32, 19 December 2025 (UTC)[reply]

  the problem is that pages are too long... ltbdl (dance) 14:39, 19 December 2025 (UTC)[reply]

  @Ltbdl On my old Samsung Galaxy A02s that was released 5 years ago WP:ANI loads fine. On my 14 year old iPhone 4s WP:ANI also loads fine. Yet you claim to have a 1 year old device that has trouble with pages half that size. So if you are not gonna help we can't help you. If you have something like a JioPhone then we can ask the WMF to buy one and test pages of various sizes on it. Polygnotus (talk) 14:47, 19 December 2025 (UTC)[reply]

  And I'm still using an iPhone 7 from 2016 (with a mere 32 GB of storage!), and both ANI and my own talk page load fine. And I'm astounded that there are people opining here who don't know things as basic as: the size of a page's wikisource (the size you see in the page history) is only weakly correlated to the size of what's actually downloaded to the reader's device -- that actual size is completely dominated by any images on the page, and boilerplate added by the Wikimedia software. Statements like struggles to load pages more than 250 kilobytes are absolutely meaningless. EEng 15:33, 19 December 2025 (UTC)[reply]

  Lots of transclusions also slow things down. WP:RFD has pretty short wikicode but my 2015 laptop often struggles to load it. Cremastra (talk · contribs) 15:37, 19 December 2025 (UTC)[reply]

  Right -- that too. A "50K" article heavy with citation templates will download much more bulk than a "200K" article that's nothing but plain text and section headings. EEng 15:45, 19 December 2025 (UTC)[reply]

  @EEng For fun I tried adding 655 image embeds from the large image category on wikimedia commons on a single page. It was less than 75KB text. Previewing it crashed my browser and my PCs specs are far better than the average here. Polygnotus (talk) 15:49, 19 December 2025 (UTC)[reply]

  I’ve often seen template-transclusion issues on Commons UT pages, where substituting routine notices is rare because so many of them are multilingual, needing to stay ‘live’ to retain that functionality. Beyond a certain number the servers simply give up on processing them, so that the lower part of a busy page eventually becomes a broken-looking mess. Anyway, I agree that wikitext size is a very poor measure of the burden placed on devices, be they at either end of the code-to-display pipeline, so to speak.—Odysseus1479 20:45, 19 December 2025 (UTC)[reply]

  There's a shit-storm about this going on at my user talk, and I'm going to make some observations here that I'm sure will further annoy some people, but I think this needs to be said. I see above that one editor stated that they are having problems with large pages, but when presented with a very polite and helpful offer of help, they abruptly pulled back. I've noticed that this is a pattern. These discussions attract an awful lot of talk about editors who have trouble conducting normal Wikipedia business over these technical issues, and yet such editors appear to be puzzlingly elusive to find. I'm sure there are cases where an editor just needs to ask Mommy and Daddy to cough up some more dough to buy a better connection, but I don't think that's really Wikipedia's problem. I don't use mobile, but I'm seeing plenty of editors who do, and who don't have problems, even with older systems. My desktop system is fairly good, but I also get frequent emails from my ISP, begging me to upgrade my modem so I would have a faster connection, and yet I'm not having problems here. Now I get it, that Wikipedia prides itself for being a website for everyone, regardless of wealth or infrastructure, and I'm certain that this sort of page size limit has been an issue in the digital past. And maybe there's somebody, somewhere, who has to use two coconuts connected by a piece of string to get online, but I think this is overblown. And every time I see someone suddenly lose interest when asked to provide specific data, I start to suspect that something else is really going on.

  We have editors who, for whatever reason, are inept at judging how to interact with other editors' emotions, how to relate to others as real people. And editors who, for whatever reason, like to see everything as according to The Rules^TM, with inflexible and algorithmic definitions of orderly or disorderly, and it just pisses them off to see user talk pages that appear to them to need cleaning up. I hope that these editors will eventually come to understand that it would be helpful for them to move on from this issue, because they are (unintentionally) creating needless drama. --Tryptofish (talk) 21:18, 19 December 2025 (UTC)[reply]

  there's a game i used to play where players could make their own levels. over time, the levels got more complicated and harder to run on older devices. the community's general response to this was not to optimize their levels, but to ask people to get better devices. this attitude still persists today, and it's resulted in the game being completely inaccessible to those even with mid-range devices.

  i never thought i'd see something similar happen on wikipedia, but here we are. ltbdl (free) 04:32, 20 December 2025 (UTC)[reply]

  I've responded to you at your Talk page. Mathglot (talk) 06:34, 20 December 2025 (UTC)[reply]

• I don't see any reasonable interpretation of it as your "E1". The bolding in the introduction and options A–D, and the various "removed" links showing exactly what was being edit warred over, clearly indicate what is being referred to as "the size clause". Anomie⚔ 15:34, 19 December 2025 (UTC)[reply]

  I can take this to mean one of two things: Either you are arguing "option E is crystal clear" in which case: What, exactly, do you envision it suggests? And how can you be so sure I - and many others - share that vision? (Specifically I would argue there have been responses that clearly think only the number but not the clause will be removed, something I suggested as "option F", which in turn has received some !votes against) Or, you are not disputing option E is unclear, you just don't see my specific suggested alternative interpretation E1, in which case: fair enuff, since that doesn't change the basic fact a closer will needlessly have trouble deciding what people agreeing to option E actually want. Regards, CapnZapp (talk) 16:01, 19 December 2025 (UTC)[reply]

  Option E expresses support for the "remove" edits (Special:Diff/1279030216, Special:Diff/1315574754, Special:Diff/1316602186), i.e. the clause that is bolded in all the other options. I don't see anyone above (other than maybe you, if you're serious) seeming to think that option E is "remove any recommendation for archiving whatsoever"; all E-supporting comments refer to opposing specific size limits. Your "Option F" stated above is not even what you say it is here: above you say "option F" is "don't suggest any limitation for user talk pages, regardless of what consensus is for all other talk pages". Anomie⚔ 17:09, 19 December 2025 (UTC)[reply]

  Currently, WP:TALKSIZE says nothing about talk page size. That's obviously bad and will only increase uncertainty. People will search for guidance and saying nothing at all will only waste people's time as they keep looking for what's no longer there. We can and should bring up the subject of talk size even if we only mirror what we're saying for WP:USERTALKSIZE, whose omission from the RFC is one of its great failings. I oppose Option E - Remove the size clause entirely because it makes zero sense to say nothing and because I find the current wording for WP:USERTALKSIZE quite reasonable: The length of user talk pages, and the need for archiving, is left up to each editor's own discretion. CapnZapp (talk) 09:32, 22 December 2025 (UTC)[reply]

• Option E, but I'd place a hard limit at between 512 KiB and 1 MiB. For reference, the maximum page size is 2 MiB (2097152 bytes). –LaundryPizza03 (dc̄) 04:13, 21 December 2025 (UTC)[reply]

  @LaundryPizza03 You shouldn't just believe stuff you read on Wikipedia my dear LaundryPizza.

  This page is 2.52 MB for example. If you want more examples, check out Quarry 91712 and scroll down a bit. For example User:SpaceImplorerExplorerImplorer/Em dash is 2.09MB of emdashes (for reasons beyond my understanding). Pretty sure that page will load pretty quickly, even on old devices, while my 75KB of image embeds of the largest images on Commons would cause problems for most browsers on most devices. Polygnotus (talk) 04:18, 21 December 2025 (UTC)[reply]

  2097152 bytes is derived from the current value of $wgMaxArticleSize (which is 2048 KiB), which among other things is the maximum size that will be accepted when editing a page. Pages that don't use the standard edit form, such as Wikipedia:Arbitration Committee Elections December 2018/Coordination/Mass message, may not be subject to the limit. User:SpaceImplorerExplorerImplorer/Em dash is exactly at the limit—your "2.09MB" is in 1000-based megabytes rather than 1024-based megabytes (a.k.a. mebibytes). It's also possible that there are or have been bugs that allowed for exceeding the limit. Anomie⚔ 14:03, 21 December 2025 (UTC)[reply]

  FWIW, I checked a few days ago & I believe we have just four pages anywhere on enwiki that currently exceed the notional max article size. One is that mass message page, then two userspace pages from 2014 (created at that size & never edited), and one bot-maintained list (went over the threshold in 2024 and has not been expanded since). I've not been able to figure exactly out why those three other edits were able to be saved - phab:T211331 suggests there are still some not-well-defined API bugs that may allow this to happen - but as I understand things, a normal editor on-wiki shouldn't be able to do it. Andrew Gray (talk) 18:23, 23 December 2025 (UTC)[reply]

• Option E - Talk page archiving is a necessary evil, done because of practical limits. Otherwise, it is much better to retain the village. I've seen communities that form around talk pages decimated by archiving. Once active talk pages are paved over and new energy and community never fully returns, the old discussions buried where few bother to read and almost never restored to active discussion. One talk post breeds another, that creates another.. they feed off each other. Kill them off and it destroys an ecosystem. -- GreenC 04:53, 21 December 2025 (UTC)[reply]

  @GreenC: do you have an example of what you're describing? ltbdl (challenge) 10:14, 21 December 2025 (UTC)[reply]

• E - this is not something Wikipedia needs to have a rule about. Also, the proposed rule (limit page size) does not in any way solve the identified problem (some pages loading slow for some users). Nothing says "I have no idea how the web works" like suggesting that a web page is loading slowly because of the size of the page. Page size is not what makes pages load slowly; it's resource calls, like images, code, etc (a point that has been made over and over again in these discussions, yet some editors nevertheless seem to fail to understand it). If we wanted to make sure all pages load in a certain time, we'd limit the number of external resources being called, not the size of the text on the page. By the way, there are external tools that provide objective measurements of how long it takes a particular web page to load, like pingdom, pagespeed, gtmetrix, and many more. Anyone seriously concerned about accessibility of wiki pages should identify (or create) a suitable tool to use as a measuring stick (kinda like how we use earwig for copyvio), and then propose a policy that pages must load within a certain time according to that tool. I don't know which of these tools are good or bad, but I'm pretty sure the WMF has an entire department of people who concern themselves with page loading speed (a serious challenge for one of the world's most popular websites), and they'd probably know. Levivich (talk) 15:13, 21 December 2025 (UTC)[reply]
• Option E and if guidance is given, that editors cool off with aggressive archiving of talk pages, and that the archiving settings should be much, much more generous than set currently. Archiving is obviously necessary for high-traffic articles like Donald Trump or Russian invasion of Ukraine, but for 99% of Wikipedia articles, there should be very little need for archiving. The whole point of a talk page is to be used. There's a small subset of editors who believe that they're helping out via "cleaning up" talk pages, not realizing that this is the entire point of talk pages. SnowFire (talk) 20:47, 21 December 2025 (UTC)[reply]

  Please define what you mean by "aggressive archiving"? I'm not asking facetiously, as if it's somehow important talk sections gets swept under the rug as soon as somebody stops talking. Instead, would you agree that once a talk page has more than perhaps half a dozen sections it makes sense to archive years-old stale discussions? CapnZapp (talk) 09:20, 22 December 2025 (UTC)[reply]

  I have seen talk pages with just two sections "cleaned up" and archived because the sections were old, despite them being old but relevant due to raising still-unfixed problems. That is what I would consider aggressive archiving. SnowFire (talk) 04:30, 24 December 2025 (UTC)[reply]

  I think the perfect example is Talk:Saint Valentine's Day Massacre § See also - List of organized crime killings in Illinois. If you look at the page's history, that talk page has been blanked many times despite the discussion being so relevant that there's an ongoing RfC created because of it. FaviFake (talk) 15:29, 24 December 2025 (UTC)[reply]

  Your example is off topic… This thread was asking about USER talkpages… not article talkpages. Blueboar (talk) 15:40, 25 December 2025 (UTC)[reply]

• Option E but editors should just accept if archiving is setup and happens, it may not effect you but large pages do effect some users. Why make there lives harder just because you happen to like seeing old discussions. -- LCU ActivelyDisinterested «@» °∆t° 14:00, 22 December 2025 (UTC)[reply]
• Option C I have to speak against the editors who seem to want unreadably-long talk pages, despite 20 years of consensus that archiving (and auto-archiving) talk pages is good. Do they want a 5MB long talk page on a contentious topic with 200 discussions from the past 18 months, so these editors can then blame "the developers" or "mobile phone" users for the inevitable difficulties of rendering and using those pages? That is, to me, obviously not acceptable. Wikipedia should pick a number as a soft estimate (not a hard requirement) for when auto-archiving should happen and when manual archiving could be necessary, and 250KB seems the best of these 4 options. ~2025-35132-06 (talk) 16:26, 22 December 2025 (UTC)[reply]
• Strongly support Option A Long talk pages are a mess to navigate. Especially ones on noticeboards which have conversations that go on for ages. Swordman97 ^{talk to me} 19:14, 22 December 2025 (UTC)[reply]
• Favor Option E. If archiving a thread is controversial, it very likely should not happen. If it's not controversial, there's no reason to wait until the page reaches some arbitrary size. With user talk pages in particular, the user should themself have near total discretion. I also agree with the comments by Mathglot, Levivich, and Tryptofish. —Rutebega (talk) 22:35, 22 December 2025 (UTC)[reply]
• Option E. The guideline can suggest the size of the talk page, but there shouldn't be any "rule of thumb" or enforcement on the matter. I use archiving on my talk page, and this is the first time I have read that the "rule of thumb" is 75 KB. ✠ SunDawn ✠ Contact me! 23:40, 22 December 2025 (UTC)[reply]
• I'd go with Option D to help with usability. Stifle (talk) 10:56, 23 December 2025 (UTC)[reply]
• I support having some kind of limit, but am ambivalent on where to draw the line or how it should be enforced. The discursions above on images etc. highlight that perhaps a better metric is needed than wikitext size, one that correlates more with device performance. Toadspike [Talk] 19:31, 26 December 2025 (UTC)[reply]
• Option E Talk page technology is the responsibility of the Mediawiki project which is run by the WMF, as I understand it. And so the English language Wikipedia should not be trying to micromanage this. Myself, I've never had much success with archiving options because they seem to be varied and customised and I've never gotten attached to any particular implementation. Our infrastructure ought to be very standard but there seems to be a huge spectrum from WP:ERRORS which bizarrely doesn't have any formal archives and is ruthlessly purged as fast as possible, At the other extreme is WP:ITN/C which has massive archive pages such as Wikipedia:In_the_news/Candidates/October_2025 which are usually over 1 Mb in size. Andrew🐉(talk) 21:13, 26 December 2025 (UTC)[reply]

Your thoughts, please. Ritchie333 ^{(talk) (cont)} 08:59, 14 October 2025 (UTC)[reply]

I think I would support somewhere around A or B but... I've never noticed it before, but now that we're looking at it in detail, it seems a little odd that it says to archive closed discussions when EEng (and I assume, most people) are (presumably) more worried about active discussions being archived. I think we should distinguish between discussions that are closed, stale but not formally closed and active, at least in this discussion even if it doesn't end up in the guideline. I don't think we need to worry too much about formally closed discussions if it doesn't look like anyone is going to challenge the close, people can archive them whenever. Active discussions should not be archived, and the section goes into that in the next paragraph. Stale discussions can also be archived whenever in my opinion, the issue for setting a threshold is mainly in deciding what counts as stale.

What are the sizes of our larger talk pages anyway (say, top 10%). Is there an easy query to find that out? Alpha3031 (t • c) 11:30, 14 October 2025 (UTC)[reply]

There's a database report for talk pages here and for user talk pages here. Ritchie333 ^{(talk) (cont)} 12:45, 14 October 2025 (UTC)[reply]

From what I recall in longer discussions about specific talkpages that wouldn't load for people, it was not just the total size that affected things but also various scripts and effects. I have seen people say, for example, that they did not inform another user of a discussion because the page wouldn't load. That is an outcome that will have to be accepted for those unwilling to archive their talkpages, and perhaps the guidelines help create expectations for when that sort of incident might be more expected. CMD (talk) 14:06, 14 October 2025 (UTC)[reply]

Are we talking about article talk pages or user talk pages? My thinking is that article talk pages should have a maximum length and archiving. User pages, on the other hand, can be left to the individual user to decide. Blueboar (talk) 14:44, 14 October 2025 (UTC)[reply]

The discussions I refer to are of user talk pages, where people are required to drop things like AN/I notices or they get badgered. CMD (talk) 16:38, 14 October 2025 (UTC)[reply]

I am not sure article talk pages and user talk pages should have the same rule. I tend to be more concerned about stale article talk page discussions. In any case, as to all the options above, my understanding is that user talk page discussions can either be archived or deleted, depending on the preference of the user, so that option for user talk pages should be clarified in the proposals. Coining (talk) 18:09, 14 October 2025 (UTC)[reply]

I think that if we are going to specify a number, there ought to be a consensus for such a number, and I think it's very clear that such a consensus does not now exist, nor has it existed for a very long time. I agree with editors above, that we need to avoid setting strict rules for user talk pages (something that I see as falling under WP:MALVOLIO). I can see some value in not letting article talk pages, or project space talk pages, get too lengthy, but in my experience, that usually happens organically, when discussions get closed or peter out. From time to time, we also have situations in article talk pages where, as a result of current events (the recent assassination of Charlie Kirk comes to mind), talk pages can become very long in a matter of a day or so, but it may be necessary to keep individual sections open while discussions are playing out. So I'm very wary of a one-size-fits-all solution. --Tryptofish (talk) 20:59, 14 October 2025 (UTC)[reply]

• Two comments on the above discussion, provided in the spirit of helpfully hoping to avoid irrelevant discussions: first, here we're discussing size concerns, so distinguishing between active and stale discussions isn't really pertinent: if you experience loading times or other problems, it doesn't matter if the discussion is still active or not, now does it?
  Second, is this about user talk pages, take pages in other spaces, or both? Note how we have two shortcuts that lead to different sections of the guideline: WP:TALKSIZE and WP:USERTALKSIZE. There's even a hat note at the start of the WP:TALKSIZE section that alerts readers to this fact. I've asked the RFC creator to clarify. Best regards and good luck with your discussion, User:Alpha3031 User:Ritchie333 User:Chipmunkdavis User:Coining User:Blueboar User:Tryptofish and anyone else involved! CapnZapp (talk) 10:20, 20 October 2025 (UTC)[reply]

• Comments: (Summoned by bot), I had not run across WP:MALVOLIO but it is applicable to this discussion. There can be a multitude of reasons why a page may not load, or load too slowly, including cell phone issues. Not informing another user of a discussion, because the page wouldn't load, sounds like an after-the-fact excuse. I mean, I assume if a page didn't load, the person can still inform the other user from their own talk page using one of the various user templates and a rationale for the choice? I also assume there are other easy workaround options? I am not sure there is, or has been, a serious issue brought about because of a lengthy talk page or "where people are required to drop things like AN/I notices or they get badgered". I think this should be left to user discretion, avoiding "strict rules". Believe it or not, some people may not know how to archive a page. I have heard that Wikipedia already has too many rules. -- Otr500 (talk) 02:52, 19 October 2025 (UTC)[reply]

  Since this is quoting me, I will reply, and not that there has been an issue brought about because of lengthy talk pages, they have appear on AN/I many times. There is no "easy workaround", because AN/I rules explicitly bar such workarounds. I also assume those raising it did so after-the-fact, but I don't really see how you could expect them to know that a talkpage wouldn't load before the fact. CMD (talk) 03:44, 19 October 2025 (UTC)[reply]

  The discussion started fairly simply about talk page size (Recommended maximum talk page size), a link to show long talk page sizes, and various elements were added in like: 1)- Those worried about active discussions being archived, 2)- Something about ANI discussions (no links), 3)- archiving stale discussions, and 4)- what counts as stale. I assumed there was a problem with "where people are required to drop things like AN/I notices or they get badgered", but this was rendered moot with "not that there has been an issue brought about because of lengthy talk pages". My mention of "after-the-fact" was if someone was using a mobile device and was cornered for not advertising the discussion to a particular person, and the reason used was that the user's page did not load. I am nearly computer illiterate, and I can think of more than one solution to that issue. Maybe that user's phone is bogged down, too many open tabs, slow or bad internet connection, etc.. Ping the target user, and state that the user's page will not open. Another editor might do it for you? At any rate, this is simply: Should there be a talk page size limit, and if so, what would the "rule of thumb" be for that size? I would like to point out that, in my opinion, "stale discussions" are a consideration. All but the last choice state "archive closed discussions", and two others and I have concerns about this. It seems it possibly should have been included? I think I would swing to E: "Leaving the size clause out", in agreement with it should be "left to the individual user to decide" (per Blueboar), as I would be "wary of a one-size-fits-all solution" per Tryptofish -- Otr500 (talk) 20:39, 19 October 2025 (UTC)[reply]

  Lengthy talk page issues have caused issues before, as I mentioned. Not making a one size solution is all well and good as a decision, but that must take into account the impacts. For example, if you wish to propose that pinging when unable to post counts as a substitute for an AN/I notification I would likely support, but that is not the current practice and should not be treated as if it already is. CMD (talk) 08:28, 20 October 2025 (UTC)[reply]

If this Rfc is using pagesize as a rough proxy for page load time, then it seems to me it should be rewritten to say page load time. We can't know every user device's characteristics and limitations, but we could easily do a dozen trials and determine the average real cpu time usage to generate the page, and could base options on that: Option A) archive the page when cpu > 9 seconds; B) > 6"; etc. Regardless what device a user has, it will take at least that long to load. If a page loads in 1.5", it can be 4 megabytes, for all I care. If it is not about page load time, then what is it actually about? Scroll-fingeritis? Mathglot (talk) 18:02, 21 October 2025 (UTC)[reply]

An observation regarding this has been removed, readded, removed, readded and finally removed again – please note that two of these removals were by editors {{redacted}} widely known in narrow circles to be near the top of the database report of the longest user talk pages. A recent reminder: Special:Diff/1323645993#c-JPxG-20240103064000-EEng-2019-01-03T20:16:00.000Z. —⁠andrybak (talk) 16:49, 17 December 2025 (UTC) Rewritten to avoid personal attacks. —⁠andrybak (talk) 00:23, 19 December 2025 (UTC)[reply]

I redacted part of that, as needlessly insulting. I'll also note that the redacted part might or might not have referred to me. --Tryptofish (talk) 23:38, 17 December 2025 (UTC)[reply]

I'm sorry. It was wrong for me to use "notorious" here. The redaction made the sentence lose sense, so I replaced it. —⁠andrybak (talk) 00:23, 19 December 2025 (UTC)[reply]

• I have no real feeling on whether we specify a number, but I think it's worth noting that there is an objective limit - $wgMaxArticleSize caps pages at I think 2048 KiB, which is just under 2,100,000 bytes. (There are mysteriously two or three pages above this, but in general it seems to be a hard limit). Once a talk page hits that point, I assume we would be required to archive parts of it regardless, as otherwise no new comments could be added. Andrew Gray (talk) 17:40, 18 December 2025 (UTC)[reply]

  Sounds like something we should test on [ https://test.wikipedia.org/ ]. If something very bad happens, that could give a clever vandal a new way of screwing with us. --Guy Macon (talk) — Preceding undated comment added 00:15, 19 December 2025 (UTC)[reply]

  Better go post that over at WP:Tools for vandals; nobody that needs to, is going to see it here. Mathglot (talk) 01:40, 19 December 2025 (UTC)[reply]

• To be honest, I don’t understand why usertalk pages even need archiving. I think of my usertalk the way I think of voicemail or a text message… ephemeral communication. Once I have read a message posted to my usertalk, I rarely want to refer to it again. Perhaps I will keep a thread active while that particular conversation is on-going… but when done, I simply blank the thread. I don’t bother to archive. Abd, if someone else needs to review something that was posted to my usertalk, they can always search the page history and find it.

So… having a mandatory size limit is not something that I even think about… I never reach the limit. And I am curious as to why others feel a desire to keep old (stale) messages and threads? Blueboar (talk) 15:52, 19 December 2025 (UTC)[reply]

@Blueboar People generally don't. There are few very large pages. See Quarry 100159 and Quarry 91714 and Quarry 91712. Polygnotus (talk) 15:58, 19 December 2025 (UTC)[reply]

@Blueboar, in the context "this page needs archiving" just deleting stuff (assuming the page in question is your own talk) is a fine alternative. Please don't read "this page needs archiving" to say it specifically needs archiving. It needs to get smaller. On your own talk page (but nowhere else) deleting is a fine alternative: you still accomplish the reduction in size. CapnZapp (talk) 16:05, 19 December 2025 (UTC)[reply]

Oh, I know that my method is permitted… I am just curious to understand the other extreme. Why other editors even want to keep old threads (to the point where archiving is potentially necessary). It’s a viewpoint that baffles me. Blueboar (talk) 16:29, 19 December 2025 (UTC)[reply]

I can only speak for myself, but I find it very natural to archive my talk page. After all, we see other talk pages being archived all the time. There's no mystery, no grand design - it's just handling every talk page the same. Cheers CapnZapp (talk) 16:32, 19 December 2025 (UTC)[reply]

@Blueboar The reason I do not think the 75KB restriction is a good idea is not because I think talkpage threads should never be archived.

I know how people on Wikipedia deal with the existence of such "rules". User_talk:Wizmut#Merging/condensing_archives.

Stuff like this just shows a fundamental misunderstanding of how computers work. Polygnotus (talk) 20:34, 19 December 2025 (UTC)[reply]

I do find it interesting how many of the "Option E" supporters themselves have large user talk pages with years-stale sections, and focus solely on the "load slowly over slow connections" aspect in their arguments to try to poke holes in the heuristic with "what about short pages with lots of transclusions or images?". Anomie⚔ 15:29, 21 December 2025 (UTC)[reply]

This discussion was opened as an "RfC", but without being listed formally as an RfC, and it has been open since mid-October (with it now being late December). I don't think it should just be left open indefinitely, and perhaps it's time to start thinking about when and how it should be closed. --Tryptofish (talk) 22:52, 21 December 2025 (UTC)[reply]

• Sigh, another widely-advertised poll with 5 or 6 options, none of which adequately address the issues.
  • Option X – As a rule of thumb, archive closed discussions when a talk page exceeds 75 KB in wikitext or and has numerous resolved or stale discussions
  • I see too many talk pages where one or a few short discussions have been archived simply because they have been resolved or are considered "stale", leaving the impression that there have never been any discussions about the topic. There is usually no harm in keeping the most recent old discussions on the main talk page, and waiting to archive them until after the page has exceeded 75K in size.
  • In certain topics with high-volume discussion the talk page should be allowed to grow larger. HERE's a requested move discussion that grew to 280K before it closed. It shouldn't be arbitrarily closed and archived just because it exceeded 75K.
  • In summary, this shouldn't be an "either or" – it should be an "and" – wbm1058 (talk) 20:16, 22 December 2025 (UTC)[reply]

  Wbm1058: it wasn't quite clear to me if you placed your bolded, voteish-looking comment here intentionally because it isn't a !vote and you wanted to underline that as a discussion point, or whether you intended it as a !vote and didn't realize this is the discussion section. Either way, subsequent users wishing to cast your vote: please do so at the bottom of the § Straw poll section above and not here. Mathglot (talk) 02:37, 23 December 2025 (UTC)[reply]

  It seems clear to me that the consensus is leaning towards Option E - Remove the size clause entirely. I think we really need to have a consensus to keep a (maximum) size clause, and even if there is "no consensus" rather than a consensus for option E, the end result will be to remove the size clause as there is no continuing consensus to have one. At which point we just have As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions. In practice, I see editors entirely blanking talk pages, but for the boilerplate banner forest at the top, and creating a very small archive holding just one or a few very brief "discussions". This wastes editors' time by making them click to load another page to see the most recent talk, and adds an extra maintenance burden, the need for moving archives when a page moves, cleaning up after page movers who neglect to do that, etc. Since editors don't seem to understand "numerous" we might consider clarifying that with a number: "As a rule of thumb, archive closed discussions when a talk page has resolved or stale discussions exceeding 75 KB in wikitext." But that's an entirely different discussion than the one we're having here. The rationale for this discussion is "large pages can't be viewed or edited easily on a smartphone", not "small archives are a time-wasting maintenance burden". – wbm1058 (talk) 14:50, 24 December 2025 (UTC)[reply]

  The only trend that can be argued to be visible at all is precisely the opposite of the 75K prescription or suggestion. Also please read the post below. CapnZapp (talk) 11:21, 26 December 2025 (UTC)[reply]

• Many people have !voted for E, believing it really means "mention no number but keep the size clause in". The size clause is already removed. WP:TALKSIZE currently says nothing about talk page size. This is precisely what I've always argued option E would result in, and why I wanted there to be an option F that doesn't specify a specific number, but keeps a size clause in. Also, WP:USERTALKSIZE is removed as an advertised shortcut 😒, but it currently does contain a size clause, one that does not mention a number. This entire RFC was incomplete and sloppy from day one, and the originator refused to fix the issues. I expect all the effort to be wasted and a new RFC appearing in mere months, no matter what the outcome is. (The likely outcome is "no consensus to do anything, no clarity what's even been discussed") CapnZapp (talk) 11:12, 26 December 2025 (UTC)[reply]

  See User talk:Ritchie333/Archive 142 § Re your recent RFC on user talk page size. – wbm1058 (talk) 03:01, 27 December 2025 (UTC)[reply]