Wikipedia talk:Talk page guidelines: Difference between revisions

Line 162: Line 162:

*:@[[User:LaundryPizza03|LaundryPizza03]] You shouldn’t just believe stuff you read on Wikipedia my dear LaundryPizza.

*:[https://en.wikipedia.org/wiki/Wikipedia:Arbitration_Committee_Elections_December_2018/Coordination/Mass_message 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. [[User:Polygnotus|Polygnotus]] ([[User talk:Polygnotus|talk]]) 04:18, 21 December 2025 (UTC)

*”’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. — [[User:GreenC|<span style=”color: #006A4E;”>”’Green”'</span>]][[User talk:GreenC|<span style=”color: #093;”>”’C”'</span>]] 04:53, 21 December 2025 (UTC)

===Discussion : Recommended maximum talk page size===

YOU MIGHT BE ON THE WRONG PAGE!

This is NOT the place for general questions or for discussions about specific articles.
This page is only for discussions about the Wikipedia page Wikipedia:Talk page guidelines. To discuss an article, please use that article’s talk page. To ask for help with using and editing Wikipedia, use our Teahouse. Alternatively, see our FAQ.

First, I realize the top of the page says this is not for general discussion, yet the editor tagged WP:AITALK and this is the talk page for that. If you want me to discuss this bias I am facing related to policy on this page, please give me a targeted policy page with a talk page, pls.

Hello, I noticed a recent instance where my hand typed, brain used content has been tagged as AI generated, for example at Talk:Infinity [Topic: Infinity, documented by Vedic text Yajurveda (c. 8th century BC)] by Leonidlednev

Whats the logic behind these? Are patrolling Editors using a AI tool which are actually not working? Getting this tag (and threats about getting comments collapsed) discourages me to want to invest time and energy.

Thank you for your comments in advanced.

Not AI Generated, Buddhimatta (talk) 08:02, 5 September 2025 (UTC)[reply]

Hi Buddhimatta, there is no tag on your comments, and no particular group of patrolling editors. This was an individual comment by an individual editor. You would have to ask the individual in question for their logic, but in the mean time you have informed them that they have made a mistake, which is likely the best response. CMD (talk) 08:39, 5 September 2025 (UTC)[reply]

Gotcha.

Regarding my other comment about creating a space for AI assisted content creator editors (accused) to have a discussion, how do we go about creating a space? This page is obviously not the right space given the notice at the top. Someone like me, didn’t know where to go have this discussion. Buddhimatta (talk) 09:12, 5 September 2025 (UTC)[reply]

There has been a lot of discussion about handling AI, but I can’t recall any proposals for a dedicated space. The best place is likely always going to be the talk page with the relevant comments, and following that normal WP:Dispute resolution steps. CMD (talk) 09:21, 5 September 2025 (UTC)[reply]

For what it’s worth — use of WP:HATGPT seems similarly flawed in that there is no way to avoid or correct from incorrect suspicion and so actual human editor inputs may get nuked.

I’ve just seen a WP:CLOSECHALLENGE cancelled by a voiced belief that “the entire request to be LLM/AI-written” and hence HATGPT was applied. But when the editor denied it and I pointed out that their Sandbox shows 12 edits over 3 days developing the challenge, there is really no point to such discussion — there is no process or means for disproof, and even if evidence is found and accepted there is no way to undo what is past. It’s obvious what the actual human wanted and seems obvious that doing or rejecting the CLOSECHALLENGE could have been quick and simple and was about the close not the challenge inputs per se — yet instead it went into a lot of wasted effort for incorrect suspicion.

I think the AI guidance is still in works and needs to work on the process flaws/gaps and get some more balance into things, but can it get some more focus on making the guidance useful and having a minimum of proof or second chance TALK to the human before unrecoverable execution ? per PackMecEng I don’t think there is any clear way to differentiate between LLM-generated proposals and human-generated proposals as of right now, (let alone as AI continues to get better) and here it was violating WP:AGF and led to a lot more time being spent in discussion so the guidance was bad in results. Cheers Markbassett (talk) 14:31, 5 November 2025 (UTC)[reply]

the editor denied it
The editor admitted to using AI to write it. See Wikipedia talk:Large language models/Archive 7 § LLM comment? FaviFake (talk) 16:49, 5 November 2025 (UTC)[reply]

??? No, that is where Locke was reporting the editor denied it. See: “in their most recent comment they claim they wrote the request” and “Tom is insisting he wrote the initial request”. Cheers Markbassett (talk) 04:41, 7 November 2025 (UTC)[reply]

Do you know how a clock works? —Locke Cole • t • c • b 05:38, 7 November 2025 (UTC)[reply]

@Markbassett Hey, it’s not too late to retract your grossly incorrect statements above. —Locke Cole • t • c • b 17:34, 5 November 2025 (UTC)[reply]

Locke – ??? Mmm, no, I think I correctly stated my concern about there being logic/process flaws. There seems no way to avoid or correct, and it lacks balance in there seems no guidance to have restraint/caution before executing that is reflective of any need/utility of doing so, the severity of impact, and whether there is any ability to undo.

For the mentioned case, it seems a distraction into HATGPT caused a needless and disruptive waste, whether it was or wasn’t a false positive. A human wanted a RFC close review. (i.e. As amply evident from his edits in the RFC on the losing side, then TALK to closer where he was sent to CloseChallenge, TALK saying that request was coming, and by your report he said he made this request.) But instead of a simple review or rejection, many times the effort got spent on this concern about the text of the request. That seems needless since reviewing a RFC would look at the RFC, and disruptive because it nuked the request and communication except about AI/LLM. The fundamental desires within WP:TALK to gather human ideas and have good communication instead by WP:AITALK wound up tossing out the human idea and inefficient, unproductive communication. The only positive I can take away was to post an addition to this WP:TALK thread stating my concerns. You might not share them, but my concerns are what they are.

Cheers Markbassett (talk) 06:21, 7 November 2025 (UTC)[reply]

a needless and disruptive waste I agree, perhaps if the editor doing it hadn’t wasted the communities’ time by posting AI-walls of text the matter they were trying to discuss could have been better addressed. Instead they repeatedly denied their use of AI, then confusingly admitted it on their userpage but hedged with claims that all their use of AI was reviewed (which depending on how charitable you want to be, was either outright false or shown to be woefully lacking). false positive It wasn’t, they admitted the use of AI on their user page, and prior to that, such use was confirmed via objective LLM text detection tools.

But instead of a simple review or rejection, many times the effort got spent on this concern about the text of the request. Two different administrators endorsed the RFC closure, and his answer was to continue insisting on another admin to voice an opinion, at one point seemingly suggesting all 800+ admins need to provide feedback. WP:LLMCOMM spells out exactly why using AI text in talk pages is disruptive to the community, and I agree wholeheartedly with the text there:

Editors should not use LLMs to write comments generatively. Communication is at the root of Wikipedia’s decision-making process and it is presumed that editors contributing to the English-language Wikipedia possess the ability to come up with their own ideas. Comments that do not represent an actual person’s thoughts are not useful in discussions, and comments that are obviously generated by an LLM or similar AI technology may be struck or collapsed. Repeating such misuse forms a pattern of disruptive editing, and may lead to a block or ban.

Editors need to communicate in their own words. It is a disservice to other editors to waste their time reading AI-generated slop or walls of text, especially since the Arbitration Committee recently passed a principle about WP:EDITORTIME: Wikipedia relies on the input of volunteer editors to maintain and produce its content, including managing its dispute mechanisms. The time editors can commit to this is one of its most precious resources. This resource should not be wasted pointlessly. The editor in question was repeatedly warned about their use of LLM/AI for generating their comments, and instead of backing down, they repeatedly posted more LLM generated text in their replies.

stating my concerns “Your concerns” lay out a false premise that ignores the true chronology of events and misrepresents the actions taken. Sadly you did not retract your grossly incorrect statements and appear to be doubling down. Luckily, diffs don’t lie. If anyone believes Mark’s claims above and wants counter evidence, feel free to reach out to me. —Locke Cole • t • c • b 16:55, 7 November 2025 (UTC)[reply]

Hi, I think this page could use a little cleanup of the shortcut boxes… I can’t be the only one thinking this box contains way too many shortcuts:

To be clear, I don’t want to reduce the number of shortcut boxes, I just want to reduce the number of shortcuts that are inside the existing shortcut boxes.

Per the WP:LINKBOXES guideline:

The point of these template boxes is not to list every single redirect for any given page […]. Instead, they generally should list only the most common and easily remembered redirects. One way to check which is the most common is through the Pageviews tool (replace the examples with the shortcuts you are testing).

FaviFake (talk) 21:52, 13 September 2025 (UTC)[reply]

Yeah, 10 is a bit excessive. I’d support trimming that one box down to 4. If you’re able to get data for these odd #-style links via “Page Information”, maybe pick the 4 most used to keep, then remove the others. –Novem Linguae (talk) 22:48, 13 September 2025 (UTC)[reply]

Ordinarily this would be the right thing to do but in this case 9 of the 10 shortcuts didn’t go to this location, they went to locations further down in the section. I’ve broken the linkbox out into individual linkboxes. Dan Bloch (talk) 20:56, 14 September 2025 (UTC)[reply]

I didn’t now that. Now it’s definitely better than before, but there are a dozen more shortut boxes on the page. I wish there were a way to avoid cluttering the page so much with these boxes. FaviFake (talk) 11:08, 15 September 2025 (UTC)[reply]

Any other opinions about this? That one was just an example, there are others like…and more. These definitely feel like they’re not following WP:LINKBOXES, since they’re just different by a few chars. FaviFake (talk) 19:35, 25 September 2025 (UTC)[reply]

I always assumed the function of these LINKBOXES included educating new editors as to which shortcuts are useful to use, say in talk discussions to save time and space. I don’t really agree with “(that’s what Special:WhatLinksHere is for)” since that easily overloads you with a truckload of links, most of which aren’t relevant. Take Wikipedia:Talk page guidelines as an example – even if I visit What Links here, and filter only on redirects, and filter only on the Wikipedia specific namespace, (something I would definitely not think to do when I was a newbie Wikipedian) I still get 122(!) hits. Which of those are created just as convenient alternates? Which of those represent legacy usage? Which ones are simply obsolete cruft nobody has bothered to clean out? …and which of those represent shortcuts currently in use by the community? I would say that the answer will naturally be “the ones we see in linkboxes”, and therefore, we should not prune these linkboxes solely to keep down the numbers, without considering the “educational” value of each and every one. Had there been a middle ground, somewhere we documented “common parlance shortcuts”, this objection of mine would fall away, but I am not aware of any other place to learn what shortcuts exist than… by reading the respective policy (or other document) or just stumbling upon them in random discussions. CapnZapp (talk) 16:25, 12 December 2025 (UTC)[reply]

the “educational” value
What’s the educational value of displaying more shortcuts than is necessary? FaviFake (talk) 18:04, 17 December 2025 (UTC)[reply]

I’m sure many of the removed shortcuts were just duplicates or legacy, and clutter cleanup is uncontroversial. But I’m also not sure all of them were. I think that for at least some, we legitimately lost value. Let me explain. We of course already have WP:TALKCOND, but we also have WP:TALKSIZE so people will see your shortcut and immediately understand you’re linking not to some generic policy on user talk pages, but specifically to relevant information regarding how long they can/should be. It is “necessary”? Technically, each section only needs one shortcut. But sections can talk about different things, or discuss a subject from different perspectives. Full disclosure: I recently created WP:USERTALKSIZE (§ shortcut to section User talk pages) so there is a shortcut to the section User talk pages just like WP:TALKSIZE redirects to section Archiving, so we have a shortcut specifically for “here’s the policy on talk page size for user talk specifically.” But unless it is shown, nobody can reasonably learn it exists and then find it useful as a convenient shorthand (i.e. what shorthands are for). That is what I considered “educational” – there really exists only two ways to learn of a shortcut: a) see it used, perhaps by you or me; b) happen upon the relevant page and see its box right there. But a) seldom happens without b) What I am saying is that if these shortcuts were removed solely from a cleanup or keep-things-to-a-minimum perspective, it’s a shame. We probably lost value there, and WP:USERTALKSIZE was probably not the only casualty of this zeal. CapnZapp (talk) 00:27, 18 December 2025 (UTC)[reply]

We of course already have WP:TALKCOND, but we also have WP:TALKSIZE
Yes of course, I never even considered removing one of these two. I almost never remove shortcuts from boxes which have less than 3. FaviFake (talk) 16:05, 18 December 2025 (UTC)[reply]

Whether the removal of useful shortcuts is more prevalent for linkboxes with fewer entries, I’m not sure and I won’t comment on that. But there certainly are exceptions of that rule of yours. In your 17:15, 7 November 2025 edit, you did remove shortcuts from boxes with less than 3 entries several times. Your basis for each selection I cannot comment upon. But I can say that if you used some tool to decide whether any given shortcut is often used, that logic is flawed, since it means new shortcuts aren’t given time to develop; again, I don’t want to make this about me, because I have a feeling this isn’t just about the example I’m about to give, but I *am* here because of this specific instance, so I haven’t really delved into your other removals. Anyway, you removed WP:USERTALKSIZE from {{Shortcut|WP:OWNTALK|WP:USERTALKSIZE}}. WP:USERTALKSIZE got less than a month to live from the date I added it. As I see it, WP:TALKCOND/WP:TALKSIZE should be mirrored for your own talk: WP:OWNTALK/WP:USERTALKSIZE. And the “educational” argument is, people can only learn these shortcuts exist by looking at the linkboxes, at least until they can instead see people use them in discussions… which they won’t if they don’t know they exist in the first place… Anyway, I don’t really see the argument to remove this. Perhaps you can enlighten me? Or better, agree to let me put it back. (Again, there’s probably a case to be made for at least some of the other removed entries, but I will have to leave those for others to discuss.) Cheers, CapnZapp (talk) 23:26, 18 December 2025 (UTC)[reply]

Sure, you can put it back. My rationale for that one was that it’s much easier and shorter to type the alternative, OWNTALK, in addition to the fact that your is basically unused, as you said. But I don’t mind you adding it back! FaviFake (talk) 14:45, 19 December 2025 (UTC)[reply]

As I said, this is still very common, just go to any WP:NOTICEBOARD right now and open the source view and you’ll find instances of it on almost all of them where people are referring back to some comment from further up in the thread, or to some talk page discussion before something came to the noticeboard) and they’ll just link to the diff of their comment. visit more 103.174.195.148 (talk) 12:29, 26 September 2025 (UTC)[reply]

Currently we have WP:OWNTALK. This appears to stand for “my own talk”.

But this guideline applies to the user talk pages of others than yourself too. You are permitted to do much more at your own talk than at the talk pages of other users, so the distinction is significant.

Can we add a shortcut that does not imply guidance on your own user talk page? (Something like WP:USERTALK except that one is already taken)

It is possible the “OWN” is meant to stand for “ownership” and not own as in “your own”. I still think it would be useful to be able to use a shortcut that implies “here’s guidance on user talk pages in general”.

Regards CapnZapp (talk) 13:29, 5 October 2025 (UTC)[reply]

Okay so nobody though this to be enough of a bad idea to object. WP:USERTALKSIZE now redirects to section User talk pages just like WP:TALKSIZE redirects to section Archiving, so we have a shortcut specifically for talk pages in the user talk space. Cheers CapnZapp (talk) 13:20, 8 October 2025 (UTC)[reply]

As a general rule I don’t favour publicizing more shortcut links, because on English Wikipedia they end up getting used visibly as jargon. In my opinion, WP:USERTALKSIZE isn’t an apt shortcut for Wikipedia:Talk page guidelines § User talk pages, as size is only mentioned once, briefly. (Although of course there’s no way to make it happen, personally I’d prefer that users not use any shortcuts visibly, and use appropriate link text instead.) isaacl (talk) 23:14, 8 October 2025 (UTC)[reply]

Your reluctance to shortcuts is noted. However, as you yourself say, users not using them is not going to happen. So let’s disregard that option for the time being. Now, I am open to rewording the shortcut, but I do believe there is value in being able to direct users to the guideline that is specific to user talk space, without needlessly confusing them with the more general guidelines for all talk pages. I created the shortcut to give myself (and others) a way to talk about the guidelines for user talk without having to provide a shortcut for talk pages in general, where the pertinent guidance for user talk requires a jump to a different section. Specifically to be able to back up the claim “the guidelines leave the size of user talk up to each user” with a directly pertinent shortcut so everybody can see for themselves. Simply a quality-of-life improvement, nothing more. Do you have a concrete proposal that hopefully doesn’t just mean “delete the shortcut and use a regular section link instead”? (N.B. If the current RFC results in consensus to rewrite the guidance on size that might of course involve changes to the shortcuts as well; I’m having this discussion on the assumption of status quo) Thank you for your input! CapnZapp (talk) 08:03, 21 October 2025 (UTC)[reply]

WP:USERTALK would more accurately reflect the section heading. I still don’t personally favour publicizing the shortcut link. To be more accommodating to those unfamiliar with jargon, I recommend for you to use appropriate link text within the context of your prose. isaacl (talk) 01:01, 5 November 2025 (UTC)[reply]

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

Straw poll: Recommended maximum talk page size

[edit]

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. E Eng 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. E Eng 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.—Odysseus 1479 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]
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 (d c̄) 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]
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]

Discussion : Recommended maximum talk page size

[edit]

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)

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]

At this page, Hazhk appears to have signed their addition of headers. Is this really what we want? Andrewa (talk) 21:34, 14 November 2025 (UTC)[reply]

No, it was just some mistake from 2012. I removed the signature. Johnuniq (talk) 02:23, 15 November 2025 (UTC)[reply]

Thanks, I was wondering seeing as how it had been there so long and that several users had edited the page with it there, whether I was missing something. Andrewa (talk) 03:23, 15 November 2025 (UTC)[reply]

That was clearly a mistake made years ago. I have to question why you have even raised this as an issue. —Hazhk (talk) 00:02, 16 November 2025 (UTC)[reply]

I believe Andrewa answered your question before you asked it, but no good deed goes unpunished. ―Mandruss ☎ 2¢. IMO. 02:05, 17 November 2025 (UTC)[reply]

“Use talk page permalinks to reference other editor’s comments or threads on a talk page. Individual editors’ comments and any thread or section title on a talk page are now permalinked as of June 2024, so even if a thread is archived, users will be able to follow it through automatic detection. This is a much better user experience than manual links to diffs of a comment.”

So which is it? Do we still need to use talk page permalinks, or is that advice obsolete because the links are now automatically permalinked?

Whatever the answer is, H:TALKPERMALINK should be updated to match. —Guy Macon (talk) 16:27, 28 November 2025 (UTC)[reply]

Presumably that’s referring to the Discussion Tools feature which will try to track archiving of comments. It won’t, however, handle deletion of comments and may break on certain types of editing, so permalinks (using Special:PermaLink) may still be useful in some cases. Anomie ⚔ 17:57, 28 November 2025 (UTC)[reply]

When will (something like) User:Polygnotus/Scripts/SectionLinks be added to MediaWiki? It is such an obvious improvement that it is weird that it hasn’t happened yet. Polygnotus (talk) 05:05, 19 December 2025 (UTC)[reply]

Straw poll: Recommended maximum talk page size

Discussion : Recommended maximum talk page size

Must Read

Leave a Comment Cancel Reply