Wikipedia talk:Talk page guidelines

When to archive

The guidelines say that a page should be archived when it gets over around 75kb, but this seems adapted to the age of dial-up internet. If the constraint is based on loading speed, I propose significantly increasing the guideline - perhaps to something like 200kb. Riposte97 (talk) 23:16, 19 October 2023 (UTC)

Loading speed is not just download. Rendering also takes time, and memory. And bandwidth costs money, on both sides of the connection. Carbon footprint should also be a consideration. Then there are still regions with very low bandwidth, even in rich countries like Germany. Last mile restrictions limit my parents to 2 Mbit. 🤷 Paradoctor (talk) 00:08, 20 October 2023 (UTC)

P. S.: And yes, there are still people on dial-up: "A survey conducted in 2018 estimated that 0.3% of Americans were using dial-up by 2017.[16] The CRTC estimated that there were 336,000 Canadian dial-up users in 2010.[17]" Paradoctor (talk) 20:14, 21 October 2023 (UTC)

Data from, respectively, 6 and 13 years ago doesn't seem particularly pertinent. But it is correct that rendering time and capacity are a factor. Weaker platforms can crap out entirely, and even on my honkin' fast desktop PC with stupid amounts of RAM, excessively long and code-complex articles can take an annoyingly long time to load, both in reading and in editing mode.  — SMcCandlish ☏ ¢ 😼  21:54, 21 October 2023 (UTC)

On the other end of the spectrum, when is an article talk page overarchived? Is it OK to have a totally blank talk page? (This came up inconclusive here a while back.) I dearchived the last four threads of Talk:30 (album), the latest of which was less than a week old, and got blowback. Aside from linking to a move request discussion that had just closed and not finding it, a blank talk page just looks weird, especially in this case with a single archive at only 24K. —  AjaxSmack  08:19, 11 January 2024 (UTC)

I don't like a blank talkpage either (and default to 4 remaining threads as well), but not to the point that I revert when others archive beyond that. I speculate that having a couple helps newer editors/IPs know what a talkpage section should look like. CMD (talk) 09:37, 11 January 2024 (UTC)

not blank lines

As the page notes, don't put blank lines where they don't go. Someone, some time ago, told me about putting lines with only the colons. Usually the same number as the following line. I often do that, and it seems to work fine. It also makes it more readable when editing, to separate the different comments. Gah4 (talk) 02:52, 9 December 2023 (UTC)

What works for you may not work for others. See WP:TALKGAP. Paradoctor (talk) 08:00, 9 December 2023 (UTC)

WP:TALKGAP says to avoid blank lines, i.e. lines with nothing on them at all, because each one starts not a new list item (as it should), but actually an entirely new list. But if you are in the middle of a chat with three colons for indenting, and you insert between two of these lines a line with three colons and nothing else, my understanding is that it does not have these negative impacts. Thus, you get the positive benefit of separation in the wiki markup without the negative impact that completely empty lines cause. YBG (talk) 05:18, 10 December 2023 (UTC)

Still not ideal, since it creates an empty list item, which a screen-reader would probably announce. Worse, it actually results in invalid markup due to a parser problem; it (sometimes, under conditions I've not narrowed down yet, though I was able to do it on purpose yesterday in a preview of this very discussion)creates an empty <dd> which never closes and which encloses anything that comes after it. And it produces no blank line in the rendered output anyway, only in the wikicode, which pretty much no one cares about in the first place. If you want rendered vertical spacing between list items without breaking the list, you can use either <br /> or {{pb}}, on the same line as other text, not on its own line, and follow it (again, on the same line) with a   so it is not "erased" by the parser. Demonstration, part 1:

 

Demonstration, part 2.

Demonstration, part 3. Notice that there is more space between parts 1 and 2 than between 2 and 3. Another technique within the same list item is to use {{pb}} between what are intended to be paragraphs, but keep it all inline...

...as I just did there. Using a <br /> tag will also do this...
...as here, but producing less spacing. If you want the more spacing, then <br />&nbsp;<br /> will also work, as...
 
...shown here. A more tedious vesion is to use <p>...</p> elements, and keep them all inline in the same list item, as done with all this following material, including a demo of using HTML comments to show spacing in the wikicode, too:

Basically, when spacing in a list item, do whatever it takes to keep the parser from seeing a line break (carriage return, linefeed) that tells it "this list item has ended".

And when spacing between list items, do whatever it takes to not introduce an actual blank line in the wikicode (other than one enclosed in an <!--HTML comment-->), since such a blank line tells the parser "this entire list has ended".  — SMcCandlish ☏ ¢ 😼  11:26, 10 December 2023 (UTC); note added 19:46, 11 December 2023 (UTC)

My comment above was based on the presumption that what was desired was a spacing in the wiki text, not in the rendered text. My experience is that on talk pages many editors wish to space the wikitext to make it more readily editable. I think I recall being told that the empty list item is NOT rendered but swallowed up and so causes no issue for screen readers. I might easily be wrong because (1) I have never verified this (2) I might have mis-remembered and (3) I cannot recall when or where I heard it. Pppppppp YBG (talk) 22:51, 10 December 2023 (UTC)

The MediaWiki software detects when a list item has no content and adds a class to it so it isn't displayed. Graham87 has previously confirmed that these undisplayed list items aren't announced by screen readers. So while the semanticist in me isn't a fan of empty list items, pragmatically, they don't affect those using screen readers or the visible rendered output. isaacl (talk) 01:42, 11 December 2023 (UTC)

Meaning of collapse

Collapse. If a discussion goes off topic (per the above subsection § How to use article talk pages), editors may hide it using {{Collapse top}}/{{Collapse bottom}} or similar templates. This normally has the effect of ending the off-topic discussion while allowing people to read it by pressing the "show" link. Involved parties must not use these templates to end a discussion over the objections of other editors.

I think the "hiding" is more important than the "ending". I.e., editors need not and should not be discouraged from continuing within the collapsed portion. Sometimes the OT (usually a related tangent) is important enough to discuss among interested editors, but not important enough for a separate thread. Editors can easily bypass a collapsed portion, so it's not a distraction. The text in the collapse box should briefly describe the nature of the collapsed content, so editors can decide whether to read it and possibly add to it. ―Mandruss ☎ 02:06, 20 December 2023 (UTC)

As for ending entire threads, that's what closure (usually {{atop}}) is for. Or should be; we don't need two or more ways to accomplish the same thing. We could easily do without {{hat}}, for example, but that's a separate discussion for a different venue.

If guidelines are to be descriptive, this one sorely needs updating to reflect the common usage of collapse, without objection, for less than an entire thread. (If it already supports that, it could use clarification; "discussion" usually equates to thread.) ―Mandruss ☎ 03:36, 20 December 2023 (UTC)

Seems like a WP:Be bold matter to me. I routinely fix bone-headed policy and guideline wording and rarely get reverted as long as it's not a substantive change (i.e., making a meaningfully different rule).  — SMcCandlish ☏ ¢ 😼  03:29, 13 January 2024 (UTC)

I think removal of the "ending" part would be a substantive change and meaningfully different; hence this discussion. I'm also looking for input as to new wording. ―Mandruss ☎ 16:13, 14 January 2024 (UTC)

User talk page size

There's recently been discussion about ANI about a user's talk page that is very long and causes some browsers to crash. There was (correctly, I think) no consensus to enforce archiving on their talk page through a bespoke editing restriction, but very large talk pages do cause accessibility issues and I think it's worth discussing whether there should be a maximum acceptable size for user talk pages. I'd be willing to support an addition to this guideline along these lines:

While editors are generally given a good deal of freedom over their own user space, their talk pages, and their talk page archives, very large talk pages may be difficult for some browsers to load and can cause accessibility issues. For this reason, user talk pages and associated archives should generally contain no more than [number] bytes of wikitext. If a user talk page exceeds this size, any uninvolved editor may set up automatic archiving of the user's talk page as an administrative action.

I'm not putting this forward as a formal proposal yet because it definitely needs some work, but I think it's worth discussing. Thoughts? — Callitropsis🌲[talk · contribs] 06:29, 9 January 2024 (UTC)

I'm not convinced that this problem is a significant one. I've checked almost a dozen machines, and the only one that had issues opening EEng's talk page was an ancient Samsung Galaxy S5 - and that also has trouble opening the main page, so I don't consider its failure indicative. BilledMammal (talk) 06:44, 9 January 2024 (UTC)

My computer (bought less than a year ago) has trouble opening it, so I don't think your experience is necessarily the most representative. ChaotıċEnby(t · c) 07:47, 9 January 2024 (UTC)

Maybe it is not your computer the problem but your internet connection. And maybe it was a temporary problem at that? Regards, Thinker78 (talk) 22:17, 10 January 2024 (UTC)

No, I have both a good computer and a good internet connection. Tested again today, same results. Possibly due to various factors, but the point is that some people do have difficulties accessing it. ChaotıċEnby(t · c) 18:27, 11 January 2024 (UTC)

I agree with Enby, especially if you have a userscript that processes talk pages. Aaron Liu (talk) 14:35, 9 January 2024 (UTC)

I'm strongly against the idea of someone else messing with an editor's talk page. I do archive mine, but if I were to not do so, then it's my choice, and WP:OWNTALK applies here. With that said, yes, there should be some restrictions on how long a talk page may be. LilianaUwU ^{(talk / contributions)} 12:17, 9 January 2024 (UTC)

100kb of wikitext was proposed as an upper threshold, which is roughly analogous to articles (which tend to be pruned or split out at that size). The main problem already reported is using the desktop site on mobile, which can give "repeated problem occurred" messages on iOS.

Additionally, the desktop site has a tendency to jump to the wrong place on large discussion pages, possibly before all templates are transcluded and the final HTML rendered. For example, clicking on the last section in User talk:EEng from browsing its history left me looking at a conversation from August 2023. Ritchie333 ^{(talk) (cont)} 09:36, 9 January 2024 (UTC)

Another metric, leaving this comment took 25 seconds, above the general 15 second limit beyond which users think the site's dead or crashed. Ritchie333 ^{(talk) (cont)} 09:43, 9 January 2024 (UTC)

Can't load "EEng's" talk page at all. Moxy- 23:57, 10 January 2024 (UTC)

I think the last sentence is a little problematic. Every opportunity should be given to the editor to archive the talk page themselves, or at the very least, give a compelling reason as to why they require a talk page that is 939,878kb long. Isaidnoway (talk) 10:00, 9 January 2024 (UTC)

• I absolutely support enforcing a reasonable limit on talk page size. Talk pages are primarily intended for communication; if they load slowly they are not serving that function. Since this was triggered by EEng's talk page; on a fiber-optic broadband connection the page was noticeably slow to load; on a phone with a 5G internet connection in the middle of the city it was almost impossible. If someone wishes to preserve content in userspace that they like to look at, the userpage and any subpages are available. I don't love enforcing this via a mandatory bot; that is bound to trigger edit-warring over the bot code. Escalating blocks are simplest. Vanamonde93 (talk) 10:47, 9 January 2024 (UTC)

  I would imagine enforcement to be analogous to somebody who the community thought should change their signature, but declined to do so. Ritchie333 ^{(talk) (cont)} 11:31, 9 January 2024 (UTC)

  I'm open to being convinced otherwise, but I'm not sure blocks are the best idea. I imagine any action on that would descend into an ANI thread with people incredulous that an admin would block over something as small (as they would see it) as a talk page. A bot creating standardized archives likely has less potential for drama. Ed ^{[talk] [OMT]} 17:34, 9 January 2024 (UTC)

  For a typical case study, see Wikipedia:Administrators' noticeboard/IncidentArchive1027#InedibleHulk's signature Ritchie333 ^{(talk) (cont)} 17:43, 9 January 2024 (UTC)

  @The ed17: I'm actually not opposed to archiving being enabled on all talk pages, no exceptions. My issue is with allowing someone else to add archival code to your talk page, because if you are a recalcitrant editor who is being difficult about archiving, I'm fairly certain you would just revert the addition and dare us to block you. Whereas, if we codify talk page size within the TPGs, a passing admin would be able to block with a solid backing in policy. Vanamonde93 (talk) 19:40, 10 January 2024 (UTC)

  Yes, a passing admin absolutely should block the busybody jerk who came along and decided to archive somebody else's talk page. --Tryptofish (talk) 19:43, 10 January 2024 (UTC)

  @Tryptofish:, I assume you meant that sarcastically, but I want to respond to your broader point below since it's clear I've been misunderstood. I'm not in any way suggesting that immediate blocks be handed out at the slightest sign of a length issue. I'm suggesting that if an editor is being difficult about archiving an inaccessible talk page, allowing an admin to block them via TPG is a superior and more direct solution compared to allowing another editor to add archival code to their talk page. That latter option will only engender drama. Of course we should talk to them first; I'm willing to bet most inaccessible talk pages are accidents, and EEng's might be somewhat intentional but is certainly not malicious. But if I were hypothetically formatting my talk page posts so they displayed in a non-readable color (fairly trivial to do) and if I ignored reasonable requests not to do so, I would be rightfully blocked. If I had an obnoxious signature and refused to change it, I would be rightfully blocked (many experienced editors have been, over this). How is page length any different? Vanamonde93 (talk) 19:57, 10 January 2024 (UTC)

  Yeah, I was indeed being sarcastic, and I appreciate your thoughtful reply, especially in the way that it gets more nuanced than what you had said before. Sure, I agree with you over those examples, and I can agree over what may need to happen in the (rare) instance when an editor really is unfriendly about being helpful to other editors who want to post at their talk page. At the same time, I also meant what I said, to the extent that someone who self-appoints to go to another editor's talk page and set up archiving without consent really is being a jerk, and the fact that the editor might revert that should not be taken as having risen to the point where it's time to hit the block button. --Tryptofish (talk) 20:04, 10 January 2024 (UTC)

For the record, I don't want the discussion to be specifically about EEng. User talk:Tagishsimon is another example of a lengthy talk page, where the editor has been asked about archiving, to no response. Ritchie333 ^{(talk) (cont)} 11:30, 9 January 2024 (UTC)

I agree and it's a problem I've seen with other user talk pages, which is why I specifically avoided mentioning EEng by name. Perhaps it's just dancing around the elephant in the room, but I think the ANI thread should probably just be closed at this point and I don't want to give him any more grief. — Callitropsis🌲[talk · contribs] 17:00, 9 January 2024 (UTC)

Agreed with Isaidnoway and Ritchie, I think this is a very sensible guideline to put in place, given how painful it is to navigate some of the really long talk pages on mobile. Any addition to the guidelines should make it clear, however, that any intervention ought to come after an unsuccessful discussion with the editor. WindTempos ^{(talk • contribs)} 12:06, 9 January 2024 (UTC)

Editing talk pages on mobile is quite a pain in the ass, so we should pragmatically enforce/strongly encourage every measure that makes collaboration easier. I strongly support enforcing a page size limit, and allowing other users to boldly implement an archive solution if after being pinging an active user does not do anything about it. That said, I also find this other situation quite difficult, where editors remove text without archiving it, for example User talk:thewolfchild who insists on talking on other Users' talk pages but will not host a conversation on their talk page. That said, their general preference for talking on Article talk pages is certainly reasonable. ~ 🦝 Shushugah (he/him • talk) 13:52, 9 January 2024 (UTC)

I would say to forget creating a rule and instead impose an artificial technical limit at around 350k, with automated warnings at thresholds approaching that level, and automated archiving of the page upon reaching that threshold. Make it impossible to save an edit that takes the page over that number. BD2412 T 14:41, 9 January 2024 (UTC)

I don’t think that’s something we should entrust to WMF bureaucracy to develop, and you’d have to define the rules for automatic archiving. I’d rather we create a rule. Aaron Liu (talk) 14:58, 9 January 2024 (UTC)

• Support This absolutely should happen, and treated like we do article size; rules of thumb that we bring in as needed. We already police user pages, user signatures, and user talk pages for various reasons, and considering editing another user's talk page is a requirement for certain actions (pinging isn't considered acceptable), then that's something where users are technically inhibiting other's ability to engage with them. That's unacceptable, and "just get a new computer (which may or may not solve the problem", or "well turn off the scripts that are causing trouble (just for these one or two users who refuse to be courteous)" are unacceptable defenses. Der Wohltemperierte Fuchs ^talk 15:10, 9 January 2024 (UTC)
• I agree with the people in favor of this above, and think that the comparison to user signatures is appropriate. 100k might be a bit low for an upper limit, but 350k sounds fine. Ed ^{[talk] [OMT]} 17:34, 9 January 2024 (UTC)
• Support This really should've been a policy before, but most users are willing to voluntarily archive their pages when asked. I expect we'll have very few instances where this policy is needed, but it absolutely needs to be put in place, as we've seen that a handful of editors will just refuse to archive their pages for whatever reason. These large pages make it difficult to even read the discussions occurring there, much less interact with the user, and communication is a requirement. Whether it's enforced by users/admins manually archiving the page, or by making bot archiving universal across the wiki, it needs to happen. — The Hand That Feeds You:^Bite 17:40, 9 January 2024 (UTC)
• Oppose. Actually, I don't absolutely oppose this, but I figure that putting that bold font label at the beginning, just after some bold-font supports, will get more people's attention. I'll say that I'm sympathetic to concerns that some users encounter technical problems with accessibility, and that all members of the community have some obligation to make it accessible to contact them via their user talk pages. So this isn't a strict oppose. But I'm strongly put off by the draft language in the proposal, that "any uninvolved editor may set up automatic archiving of the user's talk page as an administrative action." If that means "administrative" in the sense of what Wikipedia admins are entrusted to do, that would be the worst kind of back-door unbundling. And I'm strongly opposed to self-appointed busy bodies going around and enforcing what they think are Teh Rulz^TM (see also WP:MALVOLIO). Vanamonde93, whom I respect very much as someone with a lot of clue, nonetheless gives me the chills when whipping out "escalating blocks". If we're getting to the point of blocking editors for stuff like that, well, sheesh. The draft proposal sensibly doesn't define a number for when the line is crossed. So I suggest this bit of homework, before we get to the point of making anything formal in policy. Let's do some empirical study of how many kb it takes to really interfere with accessibility in a meaningful way. Not just one editor saying something anecdotal. Then see how many talk pages exceed that. And then see how many of the editors of those talk pages will or will not archive after a friendly request. --Tryptofish (talk) 17:46, 9 January 2024 (UTC)

  Let's do some empirical study of how many kb it takes to really interfere with accessibility in a meaningful way

  Completely impractical, given the wide array of different computers, phones/tablets, internet connections, and ISPs involved.

  And then see how many of the editors of those talk pages will or will not archive after a friendly request.

  The entire reason for this proposal is ANI's failure to deal with the worst example of this problem on the site. This proposal is intended to prevent that kind of mess happening in the future. It needs a bit of tweaking for language and scope, agreed, but "let's wait and see what happens" is just kicking the can down the road, when it's been kicked down the road for years already. We can absolutely ask people to archive it themselves, but this proposal is for what to do when people just refuse & things get unwieldy. — The Hand That Feeds You:^Bite 17:55, 9 January 2024 (UTC)

  Reply to me like that, and I'll switch to a strong oppose. If it's so completely impractical, I'm spectacularly impressed with your genius at determining that it was the worst example site-wide, not the second worst or the third worst, but the worst. Really, that's amazing! --Tryptofish (talk) 18:00, 9 January 2024 (UTC)

  Guys, chill out. As I understand it, Tryptofish agrees with the general principle but not the specific resolution. So, to be clear, Tryptofish, would you be okay with the wording except for the part starting "If a user talk page exceeds this size...." In which case, I'm happy with leaving this up to administrator discretion. Ritchie333 ^{(talk) (cont)} 18:07, 9 January 2024 (UTC)

  Thanks, Ritchie. Yes, I would feel a lot better with that revision. But I still want to insist that we need more of an empirical basis for this to become meaningful as policy. Tamzin says correctly below that we should not base this on anecdotes, so it's not just me that feels this way. And Ivanvector makes a very good point that image files are very important to consider, as opposed to just page size. --Tryptofish (talk) 18:38, 9 January 2024 (UTC)

  Basing it on numbers should not need much testing; it should only need an agreement on a measurement for how much is too much, and users opinion on if a limit is too small, for which I think 350kb is big enough. Aaron Liu (talk) 18:44, 9 January 2024 (UTC)

  I'm neutral as to whether it needs "much" testing. I certainly don't feel strongly that it has to be a lot of testing. But it needs to be more substantive than you just saying that you "think" a particular number is big enough. --Tryptofish (talk) 18:48, 9 January 2024 (UTC)

  Tryp, I don't recall now if it was you who complained in the EEng civility parole proposal (I wasn't watching closely before it was wisely closed) that doing things like that just creates an unreasonable burden on the sanctioned editor and makes them a target for the "civility police", but aren't arbitrary size limits on talk pages a form of the same thing? If we write into the guideline that users' talk pages cannot exceed <some number>, we will certainly have threads at ANI about users whose talk pages are <some number plus a bit> but which nobody has identified as a problem for any other reason. That's another reason my preference is to word this as an advisory and deal with complaints case-by-case, rather than relying on a hard limit. Or as I pointed out yesterday, an SEO optimization tool I consulted suggested that properly accessible pages should not exceed 5MB in download size, and the same tool had EEng's talk page downloading just under that limit. Further evidence that page size does not correlate with usability, neither database text size nor data transfer size. Ivanvector (^Talk/_Edits) 19:43, 9 January 2024 (UTC)

  We could also set up an ANI thread for things similar to the InedibleHulk situation said above. Aaron Liu (talk) 20:16, 9 January 2024 (UTC)

  Ivanvector, I agree entirely with everything you said there. As I keep trying to get across, the last thing that we need are talk page police, and whatever we do should be based upon empirical reality rather than somebody's hunch of The Right Number^TM. And since editors are continuing to give personal anecdotes, I might as well report that my own computer is getting a little old and buggy (come to think of it, so am I), and I find that EEng's talk page loads more slowly for me than other pages, but it has never made my computer literally crash (in the sense of freezing up or of causing my browser to become unresponsive) or made me feel unable to post there or read what other editors post there. --Tryptofish (talk) 00:08, 10 January 2024 (UTC)

  Have you tried any talk page–enhancing user scripts like Convenient Discussions and Factotum? Aaron Liu (talk) 00:47, 10 January 2024 (UTC)

  No. --Tryptofish (talk) 01:10, 10 January 2024 (UTC)

  Well, I can tell you that the page requires more than twenty seconds to load. And I have a Ryzen 2700. Aaron Liu (talk) 01:41, 10 January 2024 (UTC)

  Ivanvector, a couple of comments: "users whose talk pages are <some number plus a bit> but which nobody has identified as a problem for any other reason" would be already a reason, so who cares? There is no "there must be two or more reasons" rule with regard to any noticeboard. This being an ANI matter is extremely unlikely unless someone stubbornly refuses to comply, and the entire matter would be made moot by having a bot auto-comply for them.  — SMcCandlish ☏ ¢ 😼  03:27, 13 January 2024 (UTC)

  If a lot of people agree that it's big enough, it'd be big enough, and that would be substantive enough by Wikipedia standards. Aaron Liu (talk) 20:16, 9 January 2024 (UTC)

  Reply to me like that

  What? You're acting like I kicked a puppy, when all I did was disagree with your points. Fuck it, I'll leave this to everyone else, I don't need your impressed with your genius insults and hollow "threat" to change your !vote. — The Hand That Feeds You:^Bite 18:16, 9 January 2024 (UTC)

  That is not an ANI failure at all; EEng is aware of the technical issues with his very large talk page and has been more than willing to archive his page when asked to do so, but he prefers to do so manually. He has offered to do so now, but can't because he's blocked for completely unrelated reasons. Saying that this proposal is entirely the result of EEng's failure or refusal to comply is wholly unreasonable. Ivanvector (^Talk/_Edits) 18:07, 9 January 2024 (UTC)

  I recall at various points over the years EEng flatly refusing to archive when asked. But regardless, I'm bowing out of this discussion now. — The Hand That Feeds You:^Bite 18:16, 9 January 2024 (UTC)

• Rules for page size should really be based on the actual amount of data transferred when loading, not the "page size" visible in a page's history/information, which is just a measure of text on the page. The actual size includes images, scripts, templates, etc. which must load in the browser even if they only constitute "File:filename.jpg" in the "official" page size. Here's one way to measure: in Chrome, open an incognito window or log out, right click the page, "inspect", click the "network" tab, ensure "disable cache" is selected, then reload the page and wait. Look at the bottom. "Transferred" is the actual amount downloaded. "Resources" is the size of the page content once it's uncompressed (what's loaded in the browser). When logged in, your user scripts, gadgets, etc. can increase the size/time. For me, EEng's talk page transferred 4.6 MB and occupies 12.0 MB in resources. Tagishsimon's talk page transfers 2.9 MB and takes up 7.1 MB in resources. For me, while yes it's annoying to deal with a massive page, the difference is primarily on mobile. In the past, EEng's talk page crashed my mobile browser. Today, it doesn't crash but takes a long time to scroll, for different parts of the page to appear, etc. (and that's without trying to edit). There are people for whom amount transferred or resources loaded matter more or less, of course (connections and devices vary), but that's the sort of thing we should probably be going by.
  Talk pages, unlike a user page, have an essential function -- to facilitate communication. I'd therefore support an intervention to ensure the normal functioning of those pages. The balance is to ensure highly active users can have a functional talk page. Highly active users may have many conversations happening at once, frequent bot notices, etc., with autoarchiving challenging. I retain a handful of old conversations as something like a to-do/reminder/unresolved list, for example. I suppose there are things like {{DNAU}} to prevent autoarchiving, but many of our talk pages will inevitably go fairly long. What we should do is figure out a number rather than an "I know it when I see it" system that's wildly unevenly applied. — Rhododendrites ^talk \\ 18:05, 9 January 2024 (UTC) Adding, for the record, that I support some kind of clear limit. The only questions are (a) what that limit should be based on, (b) what that limit should be, and (c) how is it enforced. — Rhododendrites ^talk \\ 16:41, 10 January 2024 (UTC)

  That would be ideal from a technical standpoint, but it seems way too impractical to be good in practice. Page size in the history is definitely less accurate, but it seems "good enough" and has the advantage of being easy to check on any browser or device including mobile. Not every editor will be able to access a Desktop browser with a Chromium-based browser at all times to verify. The Wordsmith^{Talk to me} 18:35, 9 January 2024 (UTC)

• Like I said at ANI (or maybe it was somewhere else, I don't know any more) the computer that I am currently using regularly cannot load EEng's talk page, but has not had a problem with any other page on Wikipedia. Like Rhododendrites tries to explain, that's not a function of the page's database size but of the amount of (mostly media) content that needs to be transferred and then rendered into memory; my old backup laptop just can't handle it. It does, however, run media-intensive web apps like Youtube and Plex and Netflix with no problem at all other than not being able to hear the tiny speaker over how fast the fans spin. My point is that this should not be based strictly on page size; I've seen many talk pages that were much longer than EEng's, but had no trouble loading them as they were primarily text. ANI itself is a good example. If we're going to require users to maintain accessibility of their talk pages, and we should, it should be complaint-based as each one is likely to be a bit different, and we can help a user to set up archiving if page size is the issue or to troubleshoot the problem otherwise, and maybe we should impose automatic archiving for users who won't cooperate or break their talk pages on purpose, but we should not do any of this with arbitrary size limits. Ivanvector (^Talk/_Edits) 18:19, 9 January 2024 (UTC)
• For starters, I wish people would stop commenting, essentially, "Works on my machine". Cool. Good for you. That's not how discussions about technical issues work. If long talk pages crash on a significant portion people's machines (as they do on my Chromebook), no one cares if they don't crash on yours. So I agree that the guideline should be given some teeth here. For numbers, I would endorse 100kB advisory, 350kB mandatory. (Personally, I'd be between these two numbers, currently 272kB.) This could be worded, as a slight amendment to Callitropsis' proposal, as ... users are encouraged to keep their user talk pages and associated archives below 100 kilobytes of wikitext. Leeway is allowed past this, but if a user talk page exceeds 350 kilobytes, any uninvolved editor ... -- Tamzin^{[cetacean needed]} (they|xe|she) 18:24, 9 January 2024 (UTC)

  That also sounds like a reasonable guideline to me, though maybe further amended with warnings before forced archiving. Aaron Liu (talk) 18:31, 9 January 2024 (UTC)

  Sure, could add and the user does not archive it upon request. -- Tamzin^{[cetacean needed]} (they|xe|she) 19:24, 9 January 2024 (UTC)

•  Comment: A lot of people have been debating the particulars of how this should be implemented and/or disagreeing with aspects of my suggestion, so I'd like to make it clear that my suggestion was intended to be an example of a possible addition to the guideline and I'm really not at all attached to any one part of it. I suppose I should have made it clear in my initial comment, but I started this discussion with two principles in mind:
  • There should be an upper limit to user talk page size. I'm certainly no technical expert so I don't have any strong opinions as to how this should be measured (wikitext or file transfer data, for example) or what the limit should be, although I used wikitext in my rough draft because it seems easier to measure. Tamzin's suggestion for a discretionary range seems reasonable, although I don't have an opinion on the specific range they suggested.
  • This limit should be enforceable. Again, I don't particularly care how it's enforced as long as it has teeth. I wrote any uninvolved editor because at the time it seemed unnecessary to me to gatekeep maintaining talk pages to admins only. As far as I'm aware, one doesn't need to be an admin to remove 30/500 violations from people's user pages, for example (please correct me if I'm wrong). With that said, I think Tryptofish's comments about overly zealous busybodies are reasonable, and I wouldn't be opposed if we decided that setting up auto-archiving on the talk pages of other editors without their explicit consent is something that only admins should do. I do think blocks should be on the table as a last resort because this restriction would otherwise be practically toothless, but I don't think such needs to be said in this guideline because Wikipedia:Disruptive editing Wikipedia:Blocking policy is a policy and authorizes the use of the blocking tool to enforce policies and guidelines.
    To reiterate, I really don't care if someone decides to rewrite my suggested language from scratch as long as it follows these principles. I went to great lengths to avoid using the word "proposal" in this comment because the language I used in my initial comment was intended to be a rough idea to kick-start the discussion, not any sort of concrete proposal. I would welcome any workshopping and/or rewriting that people think is appropriate (although I obviously don't want people editing my initial comment and I'd prefer if people instead made new comments with their proposed language). Hope that clears things up. edited 19:17, 9 January 2024 (UTC) — Callitropsis🌲[talk · contribs] 18:51, 9 January 2024 (UTC)
• Strongly support this. My own browser was one of the ones that crashed out on the page in question, and I have more RAM than god. There have to be some technical limits on this, and the sky is in no way going to fall if we have a bot auto-archive old stuff off a talk page of insane length. Our weird fetish for treating user talk pages as a magically special fairyland has to end.  — SMcCandlish ☏ ¢ 😼  19:44, 9 January 2024 (UTC)

  PS: I'm fine with the alternative wording below. As long as we get this done in some enforceable form.  — SMcCandlish ☏ ¢ 😼  03:32, 13 January 2024 (UTC)

• Support a formal limit, although also suggest an alternate wording. With the suggested wording, an editor can swoop in and impose a style of archiving that a user might disagree with once a magic limit is hit. We should trust editors to set up whatever archiving system they prefer, instead, and save the imposed version for the combination of a very long talk page and a refusal by the editor to do anything about it. Suggested revision:

  ...If a user talk page exceeds this size, an uninvolved editor may give notice of the problem to the user on their talk page. If the talk page remains over the size limit 7 days after the notice with no attempt to correct the issue, any uninvolved editor may set up automatic archiving of the user's talk page as an administrative action.

  SnowFire (talk) 20:06, 9 January 2024 (UTC)
  • That sounds a bit too unverbose for just a simple "they've been warned". I think Tamzin's version would be enough:

    ... users are encouraged to keep their user talk pages and associated archives below 100 kilobytes of wikitext. Leeway is allowed past this, but if a user talk page exceeds 350 kilobytes and the user does not archive it upon request, any uninvolved editor ...

    Aaron Liu (talk) 20:21, 9 January 2024 (UTC)
• In between, I like the idea, but I'm not so sure about the wording. Specifically the wording

  any uninvolved editor may set up automatic archiving of the user's talk page as an administrative action

  . To me this reads like "If there is refusal you can simply just set up archiving anyway." Not exactly sure what a solution to this would be, as if they refuse there's not a whole lot to do. What, should we suggest we take them to ANI? That seems rather extreme for something like this. ― Blaze Wolf^Talk_{blaze__wolf} 20:51, 9 January 2024 (UTC)

  I mean, the idea is to enforce archiving. Aaron Liu (talk) 21:05, 9 January 2024 (UTC)

  Oh, God no, to any of that. The last thing that we need is for self-appointed busy bodies to go around as the talk page police. --Tryptofish (talk) 23:59, 9 January 2024 (UTC)

  Why not? We already have janitor police, signature police, and the civility police. Aaron Liu (talk) 00:48, 10 January 2024 (UTC)

  There's always been this tension between a prescriptive and a proscriptive approach. I'm not a fan of fear-based, negative outcomes. For example, I don't speed on the highway, not because I'm afraid of getting a ticket, but because I want to avoid accidents, give animals on the road more time to survive the crossing, and generally want to get from point A to point B in safety. So the idea of outside enforcement rather than self-enforcement doesn't work with me. Viriditas (talk) 01:44, 10 January 2024 (UTC)

  Not everyone can be served by prescriptives, which is why we have highway police. Aaron Liu (talk) 01:54, 10 January 2024 (UTC)

  That kind of argument falls apart when you look closely at it, and it raises other issues, some of which have to do with using the highway police as local tax collectors and criminalizing normal human behavior. And there's the counterargument of the German autobahn, most of which has no speed limit, but safety is still guaranteed due to other factors. It's not as black and white as you think. Letting people do what they want has certain advantages. Viriditas (talk) 02:04, 10 January 2024 (UTC)

  Maybe it's because I've lived under an authoritarian state for quite a while, but I don't see how there'd be much subjectiveness that would lead to criminalization or what part of this fits the metaphor of tax collectors. From a cursory glance at search, the autobahn has safety because it has quite a bit of other rules. That'd be like "there's no size limit but you must archive threads more than 3 months old". Aaron Liu (talk) 02:09, 10 January 2024 (UTC)

  In the US, the police often act as tax collectors, and use the rule of law to extort money from drivers for local coffers, often with confusing speed traps that are designed to target travelers from out of town who pass through their communities. This is a big problem in certain parts of the country. It's not really a metaphor so much as it is one of many examples of the law being used to oppress people. Viriditas (talk) 03:23, 10 January 2024 (UTC)

• Strong support. My devices struggle to open this user's extremely long talk page, and it is clear to see that this is the case for many other contributors here, also. Talk pages should be accessible; not ensuring that they remain so is disruptive. Patient Zero^talk 00:26, 10 January 2024 (UTC)
• Support in concept. I've long found it puzzling why user talk pages are treated the way they are; their purpose is for communication, and anything that impedes that purpose is undesirable. However, I oppose the "any uninvolved editor may set up automatic archiving" part. That is only going to cause problems and drama. Any "enforcement" is fraught with risk, but I think with a reasonable guideline established (Tamzin's 100kb advisory, <350kb mandatory is a good starting point, but I'd consider going lower), a polite "Your user talk page exceeds the size limit, please archive it" would be enough in 90+ percent of cases. For the rest, yes, they will probably end up at AN/I, but that's where "User:Example set up archiving on my talk page that I didn't want" is going to end up anyway. And an editor who'd refuse to archive their talk page would also probably just revert the auto-archiving - therefore also likely to end up at AN/I. Best not to open that can of worms, and simply let it be handled like other user conduct issues. --Sable232 (talk) 00:44, 10 January 2024 (UTC)
• Support Why is this even a discussion?
  • first sentence of the lead of WP:MOS: provisions related to accessibility apply across the entire project, not just to articles
  • lead of WP:USER: User pages are available to Wikipedia users personally for purposes compatible with the Wikipedia project and acceptable to the community; Wikipedia is not a blog, webspace provider, or social networking site. Wikipedia policies concerning the content of pages can and generally do apply to user pages, and users must observe these policies. Paradoctor (talk) 00:46, 10 January 2024 (UTC)
  • P.S.: For those complaining about uninvolved editors setting up archiving: That's in keeping with the Spirit of WP:TALKO™. Paradoctor (talk) 00:53, 10 January 2024 (UTC)
• Comment: I want to personally thank User:EEng for forcing me to buy a new computer. If it wasn't for his long talk page, I don't think I would have made an effort. I am happy to report that his page loads in less than a second now. I think I have a different opinion about these things than most people. If it wasn't for people like EEng and Tryptofish giving us the ability to benchmark and check our systems, some of us might never do what needs to be done. I think these users perform a valuable service and should be allowed to keep their talk pages as long as they want because of the beneficial impact it has on the economy. Viriditas (talk) 01:17, 10 January 2024 (UTC)
  • Yes, we're making America great again. In the interests of changing the subject, I'm going to link to this: [1]. Anyone want to block him posthumously? --Tryptofish (talk) 01:30, 10 January 2024 (UTC)

    A good point, which I was about to make less pithily. Blocks are meant to be preventative, and we should almost never block anyone for failing to make an edit. In particular, I shouldn't be able to get someone blocked just by dumping a 101 kB wall of text on their talk page next time they take a holiday. Certes (talk) 13:58, 11 January 2024 (UTC)

    If they’re on holiday, they wouldn’t be able to respond to a request for archiving and won’t get blocked, plus dropping a wall of text would probably be against some policy by itself. Aaron Liu (talk) 14:01, 11 January 2024 (UTC)

    I would hope any sysop would just ignore the block request under IAR, even if they don't consider 101kb disruptive editing. Sincerely, Novo Tape^{My Talk Page} 02:09, 15 January 2024 (UTC)

• Support in some formulation. The variability in computing power and other factors that impact opening such pages makes specific limits difficult to pin down. What should happen is that someone notes they have an issue accessing a page, and in response that issue is resolved. That this does not happen, despite much previous attention to the matter, means apparently a policy is needed (a similar point was made above by The Hand That Feeds You). I'm not sure Wikitext is the best metric for addressing issues (variability etc.), given there are other items that can cause lag, but it seems a better proxy than having nothing. I'd consider a certain number of talkpage sections as another proxy. Agree the signature precedent works here, for things that appear minor but are long-term disruptive. CMD (talk) 01:28, 10 January 2024 (UTC)
• Oppose. Wikipedia is not a bureaucracy, and user talk pages are also the most important locus of our community. Advocating for roving policing of people's talk pages, not even for content but for length, will be corrosive to that community beyond its benefits, which are debatable: note the wide range of experiences loading EEng's talk page reported both at AN/I and here (including Ritchie333's own mention here that he was able to leave a note on the page, but had to wait longer than is recommended in usability guides). And I struggle to see how it can be anything but a huge legislated exception to WP:TALKO; Paradoctor, you claim above that it would be in keeping with [its] Spirit, can you explain please? am I being dense? We may have a gathering problem with access for (some) cellphone users; I wouldn't know, I am fortunate enough not to have to use one to edit. We maybe should encourage users to create talk page subpages and move the season's greetings templates, convivial/joke discussions, and things that some editors have on their talk pages instead of their suer pages such as transclusions of Main Page sections, RfA and and deletion alerts, and highly formatted achievement lists to those, leaving the main talk page for businesslike discussions, Contentious Topic alerts, AN/I notices, and the like. We could also deprecate fancy borders, slanting text, and floating widgets on user talk pages as opposed to user pages. But as it is we don't even strongly suggest archiving rather than blanking, which makes checking an editor's history difficult. Implementing this proposal will be a huge change from the status quo and will disproportionately affect editors who collaborate, who respond to concerns raised on their talk pages, and who are sought out for advice and discussion, and won't impact those who seek to escape answerability by simply deleting ... or who haven't been around long enough to discover that talk pages are more than where templates get dumped informing you you did something bad. To start with, please: more polite requests to people to archive. And maybe an easy help page on setting up auto-archiving, if there isn't already one? (Someone set it up for me many years ago, back when I didn't even realise those numbers in the history of the page were byte counts, and I am only slightly more technically competent now; can anyone explain how you get a double column of archive numbers in the display box, rather than the great long tail I've got?) IOW: substantially per Trypto. Yngvadottir (talk) 09:57, 10 January 2024 (UTC)

  Perhaps Paradoctor means that the meaning isn’t changed?
  Notburo means that most rules do not need to be strictly adhered to, not that we shouldn’t regulate things.
  Yes, it disproportionally affects people who don’t remove stuff from there talk pages, and how is that bad?
  There are already a bunch of guides on archiving. Help:Archiving (plain and simple) is the short, default version, while Help:Archiving a talk page is the longer, configurable version. By default, {{archives}} will automatically format subpages into columns. Aaron Liu (talk) 14:09, 10 January 2024 (UTC)

  am I being dense? [...] problem with access for (some) cellphone users; I wouldn't know, I am fortunate enough not to have to use one to edit. [...] Someone set it up for me many years ago

  Well...

  Irony aside, it's good to see that you acknowledge that you are privileged in that respect. I'm getting the feeling, though, that you don't realize how far that puts you ahead of others. About two out of three users use phones to access Wikipedia.[2] You can bet your ass that a significant fraction of them is lucky to use old/low end hardware .

  Accessibility is not merely a nicety. In effect, it is the prime goal of this project: make existing knowledge accessible to everyone. Technical accessibility is an indispensible prerequisite for that. Can't access knowledge if you can't display it, now can you? (Or listen to it, if that works better for you.)

  If you mention WP:NOTBURO, you should always mention WP:NOTANARCHY/WP:NOTDEMOCRACY.

  more polite requests to people to archive That's reasonable. So we modify the proposal to say that setting up archiving should be preceded by asking the user to do it themselves beforehand. That do it for you? Paradoctor (talk) 15:20, 10 January 2024 (UTC)

  I can't let this go without pointing out that the statistic on accessing Wikipedia above is just that ... it refers to reading, not editing. This discussion concerns user talk pages, which aren't even indexed by search engines. The sometimes quite long wait while my browser loads some of our increasingly template-heavy articles (and the issue of accessibility to screenreaders of those articles) is not the focus of this discussion, but yes, it's ironic from one perspective. Part of my point was that apparently even EEng's user talk page does not present an insurmountable obstacle to those using less than current mobile tech, rather than the less than current desktop and laptop tech I use. We should distinguish between impossibility and difficulty / slowness; but I do recognize that some have said the page crashed their browsers. Yngvadottir (talk) 22:23, 10 January 2024 (UTC)

  We have existing guidelines and practices in place to deal with articles. We know specifically that template-heavy articles break things (WP:PEIS). I've even seen editors substitute citation templates to reduce the load on an individual page. There's no irony and no need to focus on that, because those processes already exist. CMD (talk) 01:39, 11 January 2024 (UTC)

  I'm curious, how do you substitute a cite template? Last time I tried that I got "empty citation". Or do you mean changing it to a template-less format? Aaron Liu (talk) 02:23, 11 January 2024 (UTC)

  @Aaron Liu: That is one option. I've also seen editors wrapping citation templates in an #invoke...| function specifically to avoid PEIS (Help:Template says this doesn't work, whether the people using it know otherwise I'm not sure). CMD (talk) 03:16, 11 January 2024 (UTC)

  @CMD What Help:Template is trying to say is that if you wrote a module that just called the {{cite web}} template and spat out the output, it wouldn't reduce PEIS. However, since {{cite web}} is aready a wrapper for {{#invoke:cite web|‍}}, replacing it with a direct call to {{#invoke:cite web|‍}} does cut the PEIS in half. --Ahecht (TALK
  PAGE) 21:03, 1 February 2024 (UTC)

  Thank you, that's very clarifying. CMD (talk) 09:16, 3 February 2024 (UTC)

  In fact, Tamzin made a wording that includes the last part. Aaron Liu (talk) 16:10, 10 January 2024 (UTC)

  @Yngvadottir: I actually agree with you about most of that, but being able to load a talk page is critical to its use for collaboration, no? If I can't write to you, it's a real problem. I've noted my opposition to the third-party-bot-archival above, but the size limit itself I see as no different from (for instance) requiring your posts not be in colors and fonts that are inaccessible. Vanamonde93 (talk) 19:50, 10 January 2024 (UTC)

  100% agree. critical part of collaboration. And on the theoretical arguments brought by Yngvadottir. We have all of this: Wikipedia:User_pages#What_may_I_not_have_in_my_user_pages? with things that people seem to really care about ppl not doing on their pages, so I don't see the problem with adding one more rule. There already is plenty bureaucracy on Wikipedia we are not crossing some sort of magical line in that regard. —TheDJ (talk • contribs) 09:47, 12 January 2024 (UTC)

• Oppose Insofar as there's a technical problem, it's a general one with all types of page – see Wikipedia:Database reports/Long pages. This general problem should be addressed in a general way as a standard part of the MediaWiki software which is supported by a huge technical staff who are paid to solve such problems. For example, if a page is large then perhaps the interface software should offer the reader an option of delivering it section by section or with dynamic pagination. Ad-hoc local kludges are a bad idea because they generate complexity and confusion across the projects and languages. Volunteer users should not be harassed or burdened by this in the meantime, per WP:BURO, WP:CHOICE, WP:CREEP, etc. Andrew🐉(talk) 10:25, 10 January 2024 (UTC)

  "This general problem should be addressed in a general way as a standard part of the WikiMedia software which is supported by a huge technical staff who are paid to solve such problems." It SHOULD, but the odds that it WILL are, in my view, about as likely as Boris Johnson being a credible and trustworthy politician. Ritchie333 ^{(talk) (cont)} 11:54, 10 January 2024 (UTC)

  Do we see graphs working? Dynamic talk pages, aka Flow, were abandoned and deprecated. We can’t hope on the WMF to do this in the near future. Aaron Liu (talk) 12:07, 10 January 2024 (UTC)

  huge technical staff who are paid to solve such problems Nice theory. Doesn't work that way, but it's a nice thought. Paradoctor (talk) 15:28, 10 January 2024 (UTC)

  The Discussion Tools extension was created by the WMF Editing team as part of MediaWiki and seems reasonably successful. That has been implemented across all the projects, as I understand it, and it's obviously sensible to make such functionality a common standard rather than having each project create its own kludges. We just need to engage with people like Trizek (WMF) and PPelberg (WMF) to explain the issue and see how they plan to address it. Andrew🐉(talk) 23:50, 10 January 2024 (UTC)

  The technical solution here would be lazy loading of sections, which both is complex to implement and presents a worse user experience on pages that are not extremely long, as it interferes with Ctrl-F and makes jumping to sections more difficult. That's not to say it's impossible such a thing would be implemented in MediaWiki, but we should not expect it to happen. AntiCompositeNumber (talk) 22:53, 11 January 2024 (UTC)

  It has already been done. This morning I was using my phone to browse Wikipedia in bed, as I often do before rising. I tried EEng's talk page and it loaded almost immediately. The display offered me a scrolling list of section headings which could be expanded as needed. And there was a prominent <add topic> button should I want to send him a message. This is the standard mobile interface which is designed for such mobile devices and seems to work fine in this case.

  The problem here seems to be that some editors are using non-standard interfaces such as Convenient Discussions. I'd never heard of this thing before and it turns out to be a kludge on Commons, not even hosted by the English Wikipedia. We cannot be expected to cater for every conceivable piece of alien, external technology. Users should stick to the standard interfaces provided and, if they don't, they should accept responsibility for any resulting difficulties.

  Andrew🐉(talk) 10:25, 12 January 2024 (UTC)

  No, that is not the problem. I just tried on a desktop incognito tab and it was over 10 seconds before I could click the new section button. (That said, this is a qualitative improvement over the last time I tried.) Many people have pointed out they have issues, at least honestly say it's not something important rather than inventing reasons on their behalf. CMD (talk) 11:09, 12 January 2024 (UTC)

  I am not the only one who has had difficulties, with or without scripts. The mobile site and desktop site load in about the same time for me without userscripts. Just having collapsible section is not lazy loading; everything is already loaded. Aaron Liu (talk) 12:06, 12 January 2024 (UTC)

  Sure CD aggravates the symptoms, but the main points stand both with and without CD usage. —TheDJ (talk • contribs) 12:14, 12 January 2024 (UTC)

  Bear in mind that EEng has been archiving some discussions piece by piece since this came up so we are not dealing with the page as it actually was. —DIYeditor (talk) 14:06, 12 January 2024 (UTC)

• Oppose - I briefly explored the possibility of automatically setting up auto-archiving on all content talk pages here. After consideration, I came to the view that the opposers were correct. Talk page text (including on user pages) can serve as a convenient source of information. Also, any size-based constraint is arbitrary if it doesn't take other media into account. Riposte97 (talk) 10:45, 10 January 2024 (UTC)

  "Talk page text (including on user pages) can serve as a convenient source of information." ... unless your iPhone 5S (that is all you can afford) displays "This page cannot be loaded because a problem repeatedly occurred". Ritchie333 ^{(talk) (cont)} 13:01, 10 January 2024 (UTC)

a handful of devices will outright start overheating (my work pc in particular slows down to a crawl and blue screens in around 2 minutes) when exposed to unnecessarily heavy pages like eeng and tagishsimon's talk pages for too long. my phone just takes way too long to load and render them (and also overheats to the point where it hurts to hold ow ouchie), but i hear other people's phones haven't been able to fully load them without errors at all

that's just flat out not good for keeping hardware usable

keeping wikitext under an arbitrary amount seems easy enough, but a small handful of lines could potentially still have a whole bunch of other heavy shit load, so i don't think there's a way to do it with only bots

so i support keeping talk pages, as rendered by an average pc or phone at this current time (i'll assume windows 10, android 9, and ios 13) and the view point of an ip (so no wacky gadgets, no superior dark mode, but maybe test under both desktop and mobile modes), under a memory usage threshold like 200-300 mb or something, and cutting down whatever might be clogging it the hardest. that number might still be highballing it (this page is only currently using around 100 mb, for example), but the problem is already complicated enough as is, so i really don't know if anything here would be possible to quantify in guideline format

tldr: heavy pages (in terms of total things loaded, not total wikitext) make my phone and work pc cry, make them do less of that pwease cogsan _{(nag me) (stalk me)} 12:41, 10 January 2024 (UTC)

The worst performing talk page I've seen yet is User talk:Wolfgang8741 which causes Safari on macOS Ventura running on a 2020 M1 Mac mini to lock up for a second or two. Ritchie333 ^{(talk) (cont)} 13:14, 10 January 2024 (UTC)

I just tried that talk page and it worked for me, albeit sluggishly. In that case, it seems that much of that page is weekly newsletters, especially Wikidata weekly summary. I've signed up to a few such newsletters and it's a chore to clear away the old ones every time a new one arrives. Their default behaviour ought to be to do this automatically - removing the previous newsletter when posting the latest one. Such newsletters can link to a central archive, in case editors wish to read back issues, but there's no need to duplicate the content of every issue across many talk pages and archives. I don't want these cluttering up my personal archives and so just delete the old ones. Andrew🐉(talk) 23:30, 10 January 2024 (UTC)

I think such newsletters should be unquestionably archived at sight automatically, see the top of my talk page for how to configure that. Aaron Liu (talk) 23:41, 10 January 2024 (UTC)

Aaron Liu seems to have a bot configured so that every time a newsletter arrives on his talk page, it is then copied to another user page and deleted from the talk page. I don't want that behaviour. What I'd like is for the original bot that posts the newsletter to remove the previous issue in the same edit -- a one in, one out policy. Creating additional bots to clean up after the first bot is inefficient and over-complex. Andrew🐉(talk) 00:08, 11 January 2024 (UTC)

Ah. Well, on the technical side, that would require a bit more work on the part of message delivery. Such messages are not sent by a bot, but by an extension that simply adds more wikitext to a list of pages. That would introduce a ton of new maintenance in that suggestion and introduce new goals, so such a feature would be better left done by something external instead (at least from the perspective of me, a unix philosophy liker). Aaron Liu (talk) 02:28, 11 January 2024 (UTC)

• Oppose opting anyone in to any sort of bot list. If a talk page is technically disruptive due to size, just trim it (i.e. archive to history). — xaosflux ^Talk 15:12, 10 January 2024 (UTC)

  So you're not opposed to archiving other user's pages, just as long as it is done manually?!? Paradoctor (talk) 15:30, 10 January 2024 (UTC)

  @Paradoctor I think it should be handled on a case-by-case basis, when there is significant disruption - and suggest that it is just done by archiving to history instead of creating even more copies of the text. — xaosflux ^Talk 16:11, 10 January 2024 (UTC)

  Even worse. SMH Paradoctor (talk) 16:23, 10 January 2024 (UTC)

  A golden rule of volunteers (and their bots) is that you should never rely that a future action will be made by someone else - if you think an edit is important to do, do it yourself. — xaosflux ^Talk 16:51, 10 January 2024 (UTC)

  Now it's spinning. Paradoctor (talk) 17:10, 10 January 2024 (UTC)

  what is that supposed to mean
  Personally, archives are better than deletion as I can just search for something. Aaron Liu (talk) 17:13, 10 January 2024 (UTC)

I've left that user a message at User_talk:Wolfgang8741#Your_talk_page_size - perhaps they just don't know. — xaosflux ^Talk 15:19, 10 January 2024 (UTC)

• Has anyone talked to the editors who keep large talk pages (and choose not to archive) to ask them why they do so? Perhaps there is a reason why they don’t archive. Blueboar (talk) 15:29, 10 January 2024 (UTC)

  Of course there is. Setting up archiving is a not completely insubstantial task for those comfortable with scripting / researching new tasks. For the vast majority of the rest, it's a major hurdle without (sufficient) support.

  Make it a checkbox on userpages, and the problem goes away. Better yet, make it the default. Apart from a handful of adventurous non-conformists, I don't see anyone turning off archiving on purpose. Paradoctor (talk) 15:37, 10 January 2024 (UTC)

  To set up Lowercase Sigmabot archiving, add {{subst:Setup auto archiving}} at the top of your talk page. I think it was harder to format this post than for a new user to set up archiving. Ritchie333 ^{(talk) (cont)} 16:44, 10 January 2024 (UTC)

  Sigmabot is the worse but faster one. For cluebot do {{subst:Setup cluebot archiving}} Aaron Liu (talk) 17:02, 10 January 2024 (UTC)

  Curse of knowledge. Paradoctor (talk) 17:08, 10 January 2024 (UTC)

  It’s a repeat of the instructions at Help:Archiving (plain and simple). Aaron Liu (talk) 17:14, 10 January 2024 (UTC)

  SMH Paradoctor (talk) 17:26, 10 January 2024 (UTC)

  I have been successfully confused. Aaron Liu (talk) 17:49, 10 January 2024 (UTC)

  Not my intention. But I still can't help you there. If what I've already said won't work, more of the same won't either, right? Paradoctor (talk) 18:07, 10 January 2024 (UTC)

  I don’t get what you mean, I already have archiving set up. Aaron Liu (talk) 18:23, 10 January 2024 (UTC)

  Yes, I have seen this question asked of editors. The primary response I have seen is that the editors prefer to archive manually. Sometimes they are picking-and-choosing what to archive; sometimes they are using a specific structure for their archives and presumably prefer to control this manually. Some editors like to keep threads on their talk page as a prompt to review them (DGG I believe fell into this category). One editor didn't seem to like any discussion page being archived, as it made it harder for them to find older threads on them (as I recall they used more flamboyant language). isaacl (talk) 19:54, 10 January 2024 (UTC)

  That's my position. When my talk page started to get large, I looked at archiving tools but they seemed confusing and klunky so I have been curating it manually. The main thing I'd like is a way of editing such pages at section level, like the high-level view of an inbox in an email interface. I could then manage the page at section level, selecting specific sections for actions such as deletion or moving. I have the impression that there's OneClick tools that might do this but it's also my impression that such homebrew tools are unreliable and klunky. I want a professionally supported and universal MediaWiki feature, please. Andrew🐉(talk) 10:40, 11 January 2024 (UTC)

  No, userscripts are not clunky. They have been accumulating development since 2013, and I don’t trust that the feature request for moving will be implemented soon. Aaron Liu (talk) 12:28, 11 January 2024 (UTC)

  Thanks for finding and linking to the Phabricator ticket for that feature. I'm not understanding your reference to 2013 though. Surely user scripts have been around for much longer as all early development was done by volunteers? The page Wikipedia:User scripts was created in 2005 and, now I look, I see there that there's a long list of them.

  The list indicates the number of users of each script but doesn't seem to have any kind of quality rating. I'm quite wary of code that hasn't been through an approval and QA process as there's a lot of malware out there. In my limited experience of such scripts, they usually warn that they can't be trusted and some of the scripts that I've found useful in the past are no longer supported and don't work any more. Now that there's a professional support organisation for this system, we should use it. "Why keep a dog and bark yourself?" Andrew🐉(talk) 20:17, 11 January 2024 (UTC)

  User:Evad37/OneClickArchiver's history traces back to 2013.

  While I understand the concern about code quality, as the self-appointed editor of WP:Scripts++ for the last month, I can attest that there is no malware on US/L. Scripts that are productive enough usually get featured into an issue of S++. I feel like allowing any user to edit a script's rating at US/L would create chaos. Aaron Liu (talk) 21:06, 11 January 2024 (UTC)

  If any popular script had malware, you'd probably know about it because the account holder of the script would be globally locked by the WMF. As long as the script is open source, there are easily enough techies around to be able to review code reliably. See Linus's law. Ironically enough, I sort of agree with Andrew with respect SineBot, as I can't see the source code, and started coding an open-source replacement in case it ever went offline. Ritchie333 ^{(talk) (cont)} 11:45, 12 January 2024 (UTC)

  I just looked at the OneClickArchiver page and it says

  Code that you insert on this page could contain malicious content capable of compromising your account. If you import a script from another page with "importScript", "mw.loader.load", "iusc", or "lusc", take note that this causes you to dynamically load a remote script, which could be changed by others. Editors are responsible for all edits and actions they perform, including by scripts. User scripts are not centrally supported and may malfunction or become inoperable due to software changes.

  My experience with other scripts indicates that, if there's a problem, one can wait forever for a resolution. These javascript hacks seem to be a big vulnerability so I prefer to wait for something that is safer and supported. No-one should be forcing such scripts on other editors because of the issue of responsibility. You can't be responsible for a script that you have been forced to use and don't understand. Andrew🐉(talk) 22:07, 12 January 2024 (UTC)

  Every script has that. Maybe you're just extraordinarily patient, but I'm tired of waiting for the WMF to finish this giant list Aaron Liu (talk) 21:07, 13 January 2024 (UTC)

• Question (mostly rhetorical): how do you ask someone to shorten their talk page, without making the talk page even longer? I've been thinking about this discussion, and the more that I think about it, the more I'm becoming annoyed with those editors who are Oh So Upset at the thought of other editors with lengthy talk pages. (Find some content to improve. Or get a life.) This is a genuine issue only to the extent of when an editor wants to post something at another editor's talk page and cannot, because the talk page length causes a computer problem that makes the amount of effort needed impractical. It doesn't mean that the page loaded a little more slowly than some other pages (oh, the horror). I've been thinking about my own posting at EEng's talk page, and it's never been a matter of anything worse than being just a little bit slower than average for me, which makes me suspect that some editors have been exaggerating how difficult it was for them. Above, I posted a permalink to the talk page of the late DGG: [3], which I've repeated here for convenience. DGG was a long-time admin, and was a member of ArbCom. Throughout that time, his talk page was long, as in that link. That's easily in the same ballpark as EEng's talk page has been. But it was not a Big Awful Issue while DGG was elected by the community to positions of trust and respect. Why, editors who needed to communicate with him about administrative or ArbCom matters were even able to do that! We don't need to make any changes in policy over this stuff. --Tryptofish (talk) 19:39, 10 January 2024 (UTC)

  "We don't need to make our entrance wheelchair accessible. We haven't had a single customer in a wheelchair come in here in the past ten years, so that would be a total waste of money." Paradoctor (talk) 19:58, 10 January 2024 (UTC)

  You don't know me in real life, of course, but I'm actually someone who has some disabilities, and I actually won a lawsuit under the Americans with Disabilities Act. What we are discussing here is not about accessibility for people with disabilities. (Yes, someone who needs to use a screen reader might encounter issues with a long talk page, but they also encounter a lot worse with WMF software.) --Tryptofish (talk) 20:08, 10 January 2024 (UTC)

  Then you should be aware that disability is often caused by the environment rather than by the impairment. And you're ignoring several comments stating they couldn't access these pages. Paradoctor (talk) 20:20, 10 January 2024 (UTC)

  Wow, just wow. --Tryptofish (talk) 20:57, 10 January 2024 (UTC)

  Respectfully, @Paradoctor, the analogy of poor hardware with disability seems to be in rather poor taste.

  Taking your point, though, to what extent do we make allowances? Should we set guidelines such that a first-generation iPhone being operation halfway up Everest should be able to load every Wikipedia page within a second? I'm yet to see much in the way of concrete metrics here.

  I am loathe to set yet another vague guideline which some overzealous admin will inevitably use as a cudgel. Riposte97 (talk) 10:20, 11 January 2024 (UTC)

  Respectfully, look up "social model of disability". You can keep whatever lesson you learn from that. Just don't start a discussion with me here, that's OT. If you really need to, you can do so at my talk. Paradoctor (talk) 15:24, 11 January 2024 (UTC)

  I interpreted the above comment as being in the theme of survivorship bias rather than specifically about accessibility for disabled people. As in, perhaps the lack of complaints about DGG's talk page on his talk page is due to those who would have a complaint not being able to leave a message at all. JoelleJay (talk) 04:45, 14 January 2024 (UTC)

  Even if it was about what you call survivorship bias, that doesn't justify the reply to me. And as for your wild speculation about DGG, I'm not seeing that EEng's detractors had any difficulty finding places where they could complain about his talk page. --Tryptofish (talk) 21:56, 14 January 2024 (UTC)

  The comment seemed like a pretty straightforward analogy to me. You were the one who brought up successful posts to DGG's large talk page as evidence that the size wasn't a problem for people. I'm simply (back)translating Paradoctor's analogy to that particular scenario. JoelleJay (talk) 02:37, 18 January 2024 (UTC)

  After I had explained, in response to what you call an analogy, that in real life I am a person who lives with disabilities and that I had been discriminated against because of it, the proper reply would not have been that I am at fault for supposedly not being aware of what people with disabilities face. I don't want to drag this part of the discussion on for so long, but I also don't think that I should have to explain to people how offensive that was. --Tryptofish (talk) 19:27, 18 January 2024 (UTC)

  I was responding to your misapprehension of the analogy (that it was implying the "long talk page" issues actually had anything to do with, or were being compared to, disability, when really it was simply invoking a perfectly apt example of non-response or coverage bias). I had hoped that clarifying the intent of that analogy would make you feel less personally targeted and alleviate some of the tension. JoelleJay (talk) 03:00, 19 January 2024 (UTC)

  I didn't misapprehend anything. Those of us who oppose rigid rules about user talk pages are not doing so as non-response or coverage bias. --Tryptofish (talk) 21:06, 19 January 2024 (UTC)

  Then why did your response to the analogy completely miss the point and go in an unrelated, personalized direction? And what you said about "no one having complaints about DGG's talk page" literally is non-response bias... JoelleJay (talk) 19:46, 20 January 2024 (UTC)

  Here's a non-response for you. I'm not going to respond to this any more. --Tryptofish (talk) 20:19, 20 January 2024 (UTC)

  I am not exaggerating when I say that it requires over 20 seconds to load EEng's talk page with the userscript Convenient Discussions. I should not have to suffer for WMF's snail pace at implementing features into DiscussionTools, and yes, it has been quite annoying to post on EEng's talk page, whether it's an edit conflict that freezes up everything, the fact that I have to wait for scripts to finish loading, or the 500+ MB of memory usage it brings. Janitors are good people, and they should not be seen as bad police. There's no reason to antagonize change to help people improve the encyclopedia.

  how do you ask someone to shorten their talk page, without making the talk page even longer?

  You can never measure something (analog) without changing it. Making the talk page longer is not a problem; people are already asking people to archive. Aaron Liu (talk) 21:04, 10 January 2024 (UTC)

  Twenty seconds? That's what you're complaining about? Was there someplace you had to go in a hurry? --Tryptofish (talk) 21:08, 10 January 2024 (UTC)

  Ok, thanks to you, I've actually went ahead and measured it. On my Ryzen 2700 with 16 gigs of RAM and an RX 580, it takes a minute and three seconds, expending 611 MB of RAM. Even twenty is a ton of an annoyance when you just want to post a message. And I have "improve performance of long pages" checked in CD settings. Aaron Liu (talk) 21:12, 10 January 2024 (UTC)

  Thank you for testing that. Yes, that's a disturbingly long time, I agree. It's also vastly longer than anything I've experienced there. This is why I've been saying that we need to base this on empirical data, and not on impressions. If you are interested in further testing, I have a suggestion. I'm completely sincere about this. Do the same test for Sissinghurst Castle Garden. I've picked that page because it's a Featured Article (one that I co-wrote), that fully complies with Wikipedia's norms, and which is rather long in text, and also has a significant amount of images. My guess is that it will be quicker than EEng's talk page, but non-zero for your system. I'm genuninely interested in how different it will be. --Tryptofish (talk) 21:55, 10 January 2024 (UTC)

  Thanks. That article takes milliseconds to load on my iPad, but it’s not a talk page. Let’s say ANI instead. It takes two seconds to load on my iPad (both tests in V22). Aaron Liu (talk) 22:01, 10 January 2024 (UTC)

  That, you say, is on an iPad, but your data for EEng's talk is from a Ryzen 2700. We need to compare on a single device. --Tryptofish (talk) 22:05, 10 January 2024 (UTC)

  My PC is faster than my iPad in this case. My PC also takes 2 seconds to load ANI and milliseconds to load the article, while my iPad takes 1 minute and 21 seconds to load EEng's talk page. Aaron Liu (talk) 22:31, 10 January 2024 (UTC)

  I'm trying to figure this out. My own PC, which is now a couple years old and I've been thinking about replacing it, loads the article and ANI in barely a second, and EEng's talk in maybe 4 seconds. My PC is running Windows 10 (and the current version of Firefox), with a 3.4 GHz cpu and 8 GB RAM, and I have a pretty fast broadband connection. I'm not sure how to account for how you and I get such different results for his talk page. As I've said from my first comment here, I actually do support the need for editors to be able to communicate with one another. I realize that this means that we have to allow for the fact that different people have different resources, and some people have slow systems that are not the state of the art, and that's OK. On the other hand, there comes a point, I think, where the burden does not rest entirely on the editor whose talk page it is, but also, to some extent, with the editor who has a slow system – the tricky part is how to be fair about that, from a policy perspective. --Tryptofish (talk) 22:47, 10 January 2024 (UTC)

  I have said several times that I use a talk page–enhancing userscript. Anyways, lower-tier devices should also be considered, and some people have expressed that they encounter significant difficulties with EEng's talk page.

  Either way, 350 kb is definitely too much, even just to navigate. Aaron Liu (talk) 23:08, 10 January 2024 (UTC)

  Is the script the reason that it runs slower for you? If so, there may be a way to troubleshoot that script, which could be beneficial regardless of what goes on with talk page policies. About navigating long user talk pages, Template:Skip to top and bottom is very useful. --Tryptofish (talk) 23:16, 10 January 2024 (UTC)

  The script does some UI transforming that threads everything. It's a design limitation.
  Going all the way through with archiving is better than scaffolding. Not to mention some users do experience much bigger problems on much lesser hardware, which aren't outdated enough to warrant not considering. Aaron Liu (talk) 23:28, 10 January 2024 (UTC)

  When you say that the script does that, is that in the edit window (as in threading edits automatically), or on the display of the page itself, while loading? If it's the latter, then that's almost certainly the reason for the slowness. --Tryptofish (talk) 23:42, 10 January 2024 (UTC)

  The display, and I'm pretty sure this is the sixth time that I've said the script is a large contributor to the slowness, and that this doesn't void the argument much. Aaron Liu (talk) 23:43, 10 January 2024 (UTC)

  OK then, that's clearly the explanation. So for his talk page, it takes loading time from a couple of seconds to well over a minute. As I said just above, I think it's important that we pay close attention to making user talk pages usable for editors with a wide variety of systems, including keeping things accessible for those editors with systems at the slower end of the spectrum – but I also don't think that this should be an absolute, where the editor whose talk page it is, has all the responsibility, and the editor coming to the talk page has zero responsibility. I think the proprietor of the talk page should have the primary responsibility, and if editors want to make changes to policies or guidelines about this, then the issue to be examined thoughtfully is how to get that balance right. --Tryptofish (talk) 23:52, 10 January 2024 (UTC)

  Yeah, I agree. 350kb seems like enough leeway to me, though, and there's no use keeping such a long talkpage anyway. Aaron Liu (talk) 23:57, 10 January 2024 (UTC)

  see my comment somewhere above this one for why something taking a lot of time and memory to load is not very #awesomesauce for a device's lifespan, and why heavy pages being slow and clunky is only the more immediately notable half of the problem cogsan _{(nag me) (stalk me)} 21:46, 10 January 2024 (UTC)

• Support a limit in some formulation, since WP:UOWN's provision that user pages are part of Wikipedia, and exist to make collaboration among editors easier applies equally well to user talk pages. That limit should be generous, though — certainly not lower than 200k. I've haven't read the discussion about implementation details above enough to have a view on it. {{u|Sdkb}} ^talk 19:57, 10 January 2024 (UTC)
• Oppose More harm than good. And we skipped past a simple notification and advice/request. Or a place to ask for somebody to set your page up for archiving. This would solve almost all of them. North8000 (talk) 20:29, 10 January 2024 (UTC)
• Query: How do y'all say we start over with Tamzin's wording? It seems that many are calling for things incorporated in that wording and assuming the original proposal's wording to be the only wording that'll be implemented. Aaron Liu (talk) 21:04, 10 January 2024 (UTC)
  • Oppose. --Tryptofish (talk) 21:08, 10 January 2024 (UTC)

    Based on your rapid fire responses and tone, I think you'd might want to calm down a bit. Aaron Liu (talk) 21:12, 10 January 2024 (UTC)

    I'm calm, really. You've made two separate replies so far, to my merely saying "oppose". Let me say to you, very seriously (and calmly), that what you proposed to start over with is unlikely to get consensus. But what I said does nothing to stop you from giving it a try. Instead of asking everyone else to come up with something from the start-over, you could actually formulate a proposal. --Tryptofish (talk) 21:19, 10 January 2024 (UTC)

    The reply below about being an idea lab was conceived separately from your reply. I didn't see it when you were typing, else I would've consolidated my replies. I put in this query because I thought this was the proposal, not the workshop. I don't think there's much more to formulate besides simply starting it.

    My remark about calmness was not solely about your "Oppose" without a rationale. Besides that, you've jumped at the thought of people growing impatient because they have to wait twenty seconds to leave a message (and ignored my initial input on userscripts), threatened someone's reply with switching to a strong oppose, and ignored Paradoctor's telling you that you've been ignoring several comments that state that EEng's talk page is inaccessible. Aaron Liu (talk) 21:35, 10 January 2024 (UTC)

    I'm not the issue here. Please comment on the substance of the discussion, and not on the contributor. If you think I'm being disruptive, ANI is thataway. --Tryptofish (talk) 21:46, 10 January 2024 (UTC)

  • Hold up, the opening comment says that this was only an idea workshop. Aaron Liu (talk) 21:08, 10 January 2024 (UTC)
• Absolutely opposed to giving "any uninvolved editor" the right to play with another editor's talk page operation. This will just create disputes and become a method of harassment. Also, 100K is far too small for a guideline when we have articles at least 4 times more than 7 times that length. If a talk page is creating a problem, then leaving a friendly message should be the compulsory first step (as a standard template so that all such pages can be located easily), then if the problem isn't fixed an uninvolved administrator can take care of it. Zero^talk 01:06, 11 January 2024 (UTC)
  • But if it is too big to edit, then how is someone supposed to edit it to add the friendly message? As well as I know, we can have subpages of talk that aren't named archive. If someone really needs a big, but not archive page, they could make it a subpage, use it there, and put a link in the main talk page. The main page could then suggest adding new entries to the subpage, if possible. If someone can't, they can add to the main page. Gah4 (talk) 01:30, 11 January 2024 (UTC)

    (1) Use a different browser, (2) write on your own talk page with a ping to the offending editor, (3) ask another editor to do it, (4) send email, (5) report it on a noticeboard. I.e., there are plenty of ways to get the attention of an editor apart from writing on their talk page. Also, I don't think there has ever been a talk page "too big to edit", unless some vandal made one. What there has been is a talk page that some limited number of people using particular software found too big to edit. Zero^talk 04:02, 11 January 2024 (UTC)

    I can't access these talk pages on any of my devices using any browser. At this point, it's just restricting some editors to be able to use it. ChaotıċEnby(t · c) 20:53, 11 January 2024 (UTC)

  • Regardless of 100k, 350k should be enough, no? WP:TALKO is another guideline where editors can fix bad things from other users, and I don't see why this should be treated much differently.
    Note that this is a workshop, and so far I don't see much people opposed to Tamzin's amendment. Should we add a section break with this information? Aaron Liu (talk) 02:44, 11 January 2024 (UTC)
    • No, 350K is not enough and seems to be an arbitrary hard limit chosen for no particular reason. I recall corporate email systems that enforced such hard limits and they were quite vexatious. There was general relief when we moved to cloud-based systems that had no limit. That's the general trend of technology – to provide ever increasing capacity. We should make our technology more advanced, not less. That's our policy. Andrew🐉(talk) 09:40, 11 January 2024 (UTC)

      I don’t think the limits of single emails are much of a comparison. Aaron Liu (talk) 12:30, 11 January 2024 (UTC)

      When I started at one corporation, their email system restricted standard users to just 100 saved messages -- emails would bounce after that. But that was in the 20th century. They've moved on since. Andrew🐉(talk) 12:01, 12 January 2024 (UTC)

• Support in some formulation. Large talk pages have crashed/frozen the tab in my laptop's browser before. 100k seems like a reasonable maximum size (supports about 100 sections). Any editor being allowed to add or modify an archive bot config template to summon an archive bot at that size seems reasonable to me. –Novem Linguae (talk) 02:16, 11 January 2024 (UTC)

  You have very short talk page sections. Mine average 2380 bytes and there is nothing unusual about them. Zero^talk 04:22, 11 January 2024 (UTC)

  True. Maybe it'd be a good idea to start with a higher number of bytes. From this list of largest user talk pages, #1 is 2 million bytes, #50 is 1 million bytes, #100 is 850k, #500 is 517k. Maybe we start with a 500KB limit, fix those 550ish talk pages, then see if it's still a problem. –Novem Linguae (talk) 05:11, 11 January 2024 (UTC)

• I think talk page pruning should be enforced but strongly oppose "any uninvolved editor". Egalitarianism and sharing the load are good but we know that any uninvolved editor would end up meaning that opponents and SPA gnomes would use the rule to needle good editors. It would be better to require a polite non-templated request with a link to a standard explanation of the issue. If a repeat after two weeks does not get a good result, post a message at WP:AN. An uninvolved admin should do the pruning after giving the TPO another opportunity. That makes it impersonal and just a matter of how things are done. Johnuniq (talk) 03:24, 11 January 2024 (UTC)

  Anything can be used to harass and abuse people. Aaron Liu (talk) 12:36, 11 January 2024 (UTC)

• Incidentally, from Special:LongPages I find that we have 46 articles above 500K, 255 above 400K, 1213 above 300K, and 5766 above 200K. The list doesn't go down to 100K but a plausible extrapolation is 25,000–30,000 articles above 100K. We need a very good reason to restrict talk pages to a size that we tolerate in a large number of articles. I'm wondering if we have any example of a talk page less than 500K which anyone with modern hardware and software cannot edit due to its size. Zero^talk 04:46, 11 January 2024 (UTC)

  Interestingly, the two largest articles (>700,000 bytes) load much faster for me (in seconds) than any of the talk page examples listed in this discussion. If this experience is consistent for others, then that seems a good reason to treat the article and talk spaces differently, although I'm not sure what the cause of the difference is. CMD (talk) 05:21, 11 January 2024 (UTC)

  User scripts and gadgets seem like they could be a cause of that. A user highlighter script could be performance intensive only on talk pages, for example. –Novem Linguae (talk) 05:53, 11 January 2024 (UTC)

  I spot-checked those articles, and all the ones that I did are tagged with "This article is too long". Ritchie333 ^{(talk) (cont)} 09:59, 11 January 2024 (UTC)

• I have 0 respect for users like this. Archive the page and if they don't like it they can use a different website. People thinking they have special privileges in this world, come on. Users need to be considerate towards others and this is clearly behaviour that is not considerate towards others. Archive, and move on, this is not THEIR website, they can host their own website and do whatever they want there. If we can tell people not to host any of the things listed here: Wikipedia:User_pages#What_may_I_not_have_in_my_user_pages? then we can easily do this —TheDJ (talk • contribs) 10:21, 11 January 2024 (UTC)
• Support something - either a size limit and/or age limit. Somebody with more technical knowledge will need to suggest a size limit, but I don't see why any old threads more than a maximum 6 months need to remain on talk pages. I manually archive my own at least once a week. GiantSnowman 13:00, 13 January 2024 (UTC)

(Not quite) arbitrary break re talk page size

 Note: I've posted a notice of this discussion to WP:VPT. There's been a lot of productive discussion here and many valuable perspectives have been offered, but my impression from reading this discussion is that most people participating here became aware of this discussion by reading the ongoing ANI thread. There's nothing inherently wrong with that, but I think the perspectives of technical editors who may not check ANI regularly would be useful. Here are some questions I have (speaking only for myself, of course):

• Do we have any data regarding of the types of devices and applications people use to access and Wikipedia and how often they are used? If so, is this data broken down by namespace or type of action (e. g., editing pages versus merely viewing them)?
• If such data exists, do we have a good idea of the download limits (that probably isn't the correct technical term, but whatever) of the slowest device/application combination that is regularly used to access and edit Wikipedia? If so, how does this (roughly?) correlate to size as measured by wikitext? (As noted above by Rhododendrites wikitext may not be the most reliable indicator of how quickly a page loads, but it seems like the simplest and most easily measurable metric and I think any formal guideline regarding talk page size should probably use it as a yardstick.)
• Are there any additional technical considerations that apply to editing pages but not to simply viewing them? Similarly, are there differences between any of the commonly used tools for editing talk pages (standard editing window, VisualEditor, 2017 wikitext editor, DiscussionTools, Convenient Discussions, Factorum, etc.) in terms of performance and tolerance of large page sizes?

As a side note, I checked Novem Linguae's query and was alarmed to see that EEng's talk page is only the 69th-largest user talk page at the time of this comment. I know the ANI thread regarding him was the precipitating incident that led to this discussion, but I'll take this opportunity to reiterate that I really don't want this discussion to be about him and his talk page—it seems to be a widespread issue and I don't think there's much to be gained from further anecdotal discussions of specific cases here. — Callitropsis🌲[talk · contribs] 05:52, 11 January 2024 (UTC)

• Apparently the average page on the web as of 2022 was 2.2MB. If we are having trouble with pages a fraction of that size, it isn't due to the amount of wikitext. Zero^talk 07:14, 11 January 2024 (UTC)

  Seems like this might be an apples to oranges comparison. The total size of the wikitext of my user talk right now according to the history tab is 46 KB. But if you measure that by the amount of HTML generated (view HTML source -> copy paste it to a text file -> look at how big it is in File Explorer), it jumps to 363 KB. If you measure it by the total size of all assets, including images, js files, etc. (measured by opening DevTools -> going to network tab -> looking at "resources" in the footer -> hard refreshing) then it jumps to 7800 KB (7.8 MB). The 2.2 MB number in your citation is using the same methodology as the 7.8 MB number. The latter number will also vary based on whether you're logged in and how many user scripts and gadgets you are using.

  These same stats for https://en.wikipedia.org/w/index.php?title=User_talk:EEng&oldid=1194559025, which is a user talk page with 298 sections, is 942 KB wikitext, 6.4 MB HTML, 27.7 MB all assets. Also, on my well spec'd desktop computer, scrolling to the bottom of the page took 16 seconds until text was visible, and 23 seconds for my user scripts such as my UserHighlighter to kick in. Maybe if I get curious I will retry this experiment on my laptop and my smartphone, but I can't imagine these numbers will get any faster on those less powerful devices. More likely things will lag more and/or freeze. –Novem Linguae (talk) 07:47, 11 January 2024 (UTC)

  This is a good point. Introducing a hard limit measured in K seems quite laughable nowadays. I downloaded an update for the navigation database of my car recently and it was about 100 Gb. I did this on this same browser and same laptop that I use for Wikipedia. It took a while but so it goes. My smartphone has a memory size of 250 Gb but I'm planning to get a new one soon as it's becoming obsolete. And the capacities of personal devices are starting to be measured in Terabytes now ... Andrew🐉(talk) 10:19, 11 January 2024 (UTC)

  NL makes a good point. Perhaps we should ask the techies to give us a tool for html+images, as a more useful measure of page size. Zero^talk 10:44, 11 January 2024 (UTC)

  I’m not concerned about the size of files embedded on a page. MediaWiki serves thumbs anyway. I also don’t see why we should compare the length of HTML code instead of Wikitext. Aaron Liu (talk) 12:38, 11 January 2024 (UTC)

  "It took a while but so it goes." This reminds me of something that Vincent Flanders wrote on his seminal webpagesthatsuck.com website about 25 years ago ... "Unfortunately, people won't wait for images unless they're of naked or dead bodies". Ritchie333 ^{(talk) (cont)} 10:58, 11 January 2024 (UTC)

  The download for my car took about an hour to download and unzip and then an hour to install to the car. That required some care and patience but I've worked with software that took days to run. But people seem to be freaking out here if they have to wait for a few seconds. If they want instant gratification then they should stick to sites such as Instagram, TikTok and Twitter, which are explicitly designed for short-form content. Wikipedia is an encyclopedia and so a sedate and scholarly pace is fitting. Festina lente... Andrew🐉(talk) 23:02, 11 January 2024 (UTC)

  Communication between editors should not be comparable to the installation of software. Aaron Liu (talk) 02:22, 12 January 2024 (UTC)

  That software update was measured in Gb and took hours. EEng's talk page is measured in Kb and takes seconds. This difference is several orders of magnitude. See Make a mountain out of a molehill. Andrew🐉(talk) 09:51, 12 January 2024 (UTC)

You are asking good questions, but these are all overly detailed, technical aspects that in the grand scheme just don't matter here and will only serve to facilitate discussion and create details for people to disagree about. In the end this is very simple, lot's of wikitext becomes way way more HTML, which will eventually cause very slow page loads and crashing browsers, with an easy and widely accepted solution... ARCHIVE the contents. We don't need to have 20 000 hours of wasted discussion, because we already know it's happening, people reported such. —TheDJ (talk • contribs) 11:09, 11 January 2024 (UTC)

• Support some formulation but not the invitation for any editor to just go modifying someone's talk page. It should be a reason to take them to WP:ANI and possibly have their refusal to archive it or use a bot looked into as disruption. —DIYeditor (talk) 16:11, 11 January 2024 (UTC)
• Oppose - Didn't we just have a problem with certain editors policing userspace through WP:MFD? And now we want to do the same thing with user page lengths? Heck no. Any such rule should be a guideline and not a cudgel that bad-faith users employ to police other people's talk pages. _{Duly signed,} ⛵ WaltClipper -(talk) 17:55, 11 January 2024 (UTC)
• Convenient Discussions apparently makes it much harder to load these talk pages. ChaotıċEnby(t · c) 20:56, 11 January 2024 (UTC)

  Unsurprisingly, since it is 762K of compressed javascript. I think that people who add lots of bells and whistles to their download should expect it to be slower, and I don't think they should expect other people to modify their archiving to help them out. Zero^talk 12:03, 12 January 2024 (UTC)

  Just because you find something that makes it even more annoying, doesn't take away that is already plenty annoying on its own. It's like a Ford F-650 for grocery shopping. Super annoying and unnecessary, even though it might fit. Get out of the way of others, stop being selfish or find yourself being regulated by community. —TheDJ (talk • contribs) 12:22, 12 January 2024 (UTC)

  That is, if we were the only ones having troubles. There are a lot more, and we should cut the curb to help everyone out. Aaron Liu (talk) 12:37, 12 January 2024 (UTC)

  I don't know of a lot of people have problems, nor do I know of any serious attempt to determine why they are having problems or whether the amount of wikitext is a fair measure of the amount of problems. Zero^talk 12:48, 12 January 2024 (UTC)

  i don't think the amount of wikitext is the problem, honestly

  1 mb of plain ol' copypastas might be a little annoying to load, but 200 kb of templates, images, videos, and an mp3 file of some guy screaming about among us... that may be a little worse

  unfortunately, i don't think it's easy to quantify that in guideline format when pretty much everyone with an account has gadgets cogsan _{(nag me) (stalk me)} 13:04, 12 January 2024 (UTC)

  Regardless, you shouldn’t need a talk page with over 350kb of Wikitext, even if it’s all plain text. Aaron Liu (talk) 14:11, 12 January 2024 (UTC)

  They are having problems because the page is giant. This isn’t too hard to eliminate as they don’t have trouble with this page or other user talks. Aaron Liu (talk) 14:10, 12 January 2024 (UTC)

• Oppose any lower limit than the size of WP:ANI, measured as its max size over the last year, and currently approximately 718kb. We should clean up our own house first before moving on to individual users. —David Eppstein (talk) 21:30, 12 January 2024 (UTC)

  What‽ That is true! That doesn't make sense! Why would 100kb make that much of a difference? Is there an overabundance of templates at EEng's talk page? Aaron Liu (talk) 21:40, 12 January 2024 (UTC)

  David was joking. And so am I, when I say that we should block ANI for being so... um, what was I talking about? --Tryptofish (talk) 21:45, 12 January 2024 (UTC)

  I don't feel like they were joking and they have a good point for why the proposed limit isn't a very good one. Aaron Liu (talk) 21:47, 12 January 2024 (UTC)

  Indeed. And ANI is just one of many large pages out there. I try to avoid that one but often load ITN archives to check an old nomination. These are quite large and correspondingly slow. For example, Wikipedia:In the news/Candidates/January 2023 is 945 Kb. Andrew🐉(talk) 22:18, 12 January 2024 (UTC)

  • ANI is now up to nearly 765k [4]. And no, I'm serious: we should not make stricter limitations on individual user talk pages than we place on our big public noticeboards. The only valid reason presented here for such a limitation is technical: some people's browsers cannot handle it. That issue is, if anything, much more salient for public noticeboards than for individual talk pages, because many more editors have good reason for needing to access the public noticeboards. —David Eppstein (talk) 19:15, 13 January 2024 (UTC)

    The very weird thing about this is that ANI loads in ~4 seconds while EEng's talk page loads in ~1 minute. Even logged out, ANI loads in ~3 seconds while EEng's talk page loads in ~14 seconds. I'm counting load time by the time it takes to get to the bottom and have the page be responsive. Aaron Liu (talk) 21:03, 13 January 2024 (UTC)

    David, my apologies. --Tryptofish (talk) 22:14, 13 January 2024 (UTC)

The main issue would seem to be the media loading on a large talk page -- a relative small page in terms of wikitext/HTML could still entirely consist of image galleries that'd overwhelm a browser, while a page that's 300kB of wikitext could be entirely innocuous. This makes deciding whether a page is "too big" sort of challenging when trying to set limits.

There's a technical solution to this, which is adding lazy-loading attributes to images (T148047). There were some historical issues with doing that (thus why we haven't), largely around it not working well when you wanted to print an article page, but I gather that progress has since been made on that issue by browsers... DLynch (WMF) (talk) 17:30, 17 January 2024 (UTC)

WebKit (Safari) still has the bug. Aaron Liu (talk) 17:41, 17 January 2024 (UTC)

Thanks, DLynch, that's important information. In particular, it means that editors who have been analyzing this on the basis of the number of kb of plain text have been barking up the wrong tree. --Tryptofish (talk) 21:53, 17 January 2024 (UTC)

That still doesn't explain the giant difference when loading with userscripts. Aaron Liu (talk) 22:05, 17 January 2024 (UTC)

Well duh. Of course the kb is just a lever to modify the problem. If you only used one long series of a's instead of words on the entire page, it would be even more efficient than not using images. There is not a single uniquely triggering issue here. If you fill a bucket with water, then throw pebbles in it, you won't solve the problem of overflowing by saying "no more pebbles". You say, stop filling it to the brim, so that we have some room to spare if someone throws in a pebble. —TheDJ (talk • contribs) 22:08, 17 January 2024 (UTC)

Using that analogy, the question is whether to stop adding more water, to stop adding more pebbles, or to consider whether there are different sized pebbles that are different in the amount of water they displace. Editors are real people, and hassling someone because a "lever" gave an incorrect result isn't doing anything to improve the project. And using kb in a simpleminded way to boss other people around, when we know that kb are the wrong measure, is suboptimal conduct, duh. --Tryptofish (talk) 22:20, 17 January 2024 (UTC)

We don't know the precise measure for when a talk page will cause issues, but we do know that most user talk pages have no reason to be over that measure and that a lower value of the measure loosely correlates to faster loading. Aaron Liu (talk) 22:33, 17 January 2024 (UTC)

Given that we don't know the precise measure, we should pay close attention to whether editors have trouble communicating on a given talk page. If someone has trouble loading the talk page, or has trouble leaving a message, that matters. And I'm not disputing that. But if no one is having that trouble, and if we don't know how to measure it, then using a measure that we know doesn't work, to boss that editor around, is just bossing an editor around. --Tryptofish (talk) 22:40, 17 January 2024 (UTC)

I picked out the longest pages listed in Wikipedia:Database reports/Long pages/User talk (no subpages) (a report that JPxG generated) and tried to set up automatic archiving on the top three results. (FWIW none of these users have recently edited so asking them to do it is unlikely to happen). I made a minor mistake and forgot to subst: the template, so went back and did it again. As you can see, it took ten minutes, several of my edit summaries were eaten, and the attempt on User talk:OswaldClara failed because it comes back with the error "ERROR: The text you have submitted is 2,048.071 kilobytes long, which is longer than the maximum of 2,048 kilobytes. It cannot be saved.". While I was trying to make the edits, one CPU was throttling on 100% usage; one of the few instances where I've seen an Apple Silicon CPU get hammered. Ritchie333 ^{(talk) (cont)} 14:03, 13 January 2024 (UTC)

• Support some formulation. A pagesize limit won't catch all problematic pages, but it will resolve enough problems to be worthwhile. That some pages such as ANI sometimes necessarily exceed that limit won't make it any less worthwhile (and ANI is usually lighter on mark-up and images than the problematic user talk pages). Oppose opening the door for any and all uninvolved editors of whatever standing to capriciously interfere with user talk pages. NebY (talk) 14:45, 13 January 2024 (UTC)
• Support, per WP:COMMONSENSE if anything else. Archived talk pages are just one click away, nothing gets lost, I don't get all the drama and the stonewalling that is getting raised here. Cavarrone 18:47, 13 January 2024 (UTC)
• Support in principle. I am not the most tech savvy editor but I will agree that in general there should be some commonsense limits on talk page size. And I will qualify by saying that as much latitude as possible should be accorded users in terms of how they handle their talk page, and for that matter their user page. But we already have rules in place that make it clear that nobody owns their pages and we do have a few restrictions already in place in terms of content and behavior. So while I am content to leave the more technical details to others to hash out, I do think that a user talk page that is so large that others have difficulty opening the page, navigating it, or being able to comment there, is ipso facto disruptive in that it defeats the intended purpose of the page. My preferred approach would be a four-step process.

1. Politely notify the user of your concerns and ask them to prune or archive their page.

2. Issue some form of formal caution possibly in template form.

3. Request assistance from an uninvolved admin who assuming the two previous steps have been attempted w/o satisfactory results could review the matter and if necessary in their judgement, issue a point blank directive to the user to get their talk page under control within a specified time frame.

4. If all of the above has failed, some form of compulsory archiving can be set up.

It would be understood that any user could appeal to WP:AN if they felt this was unreasonable. All of which said, this is thankfully not a common problem, and I would imagine having to actually go through all of the above steps would be exceeding rare. -Ad Orientem (talk) 20:05, 14 January 2024 (UTC)

• I would support a maximum user talk page size policy only provided that any discussion with activity in the last 2 weeks is allowed to remain regardless of page size. Otherwise we may have users with one or two humongous threads on their page either try and prematurely close/archive those threads or complain that new threads are disappearing before they can see them. This exception will probably be rare (the maximum length should be chosen such that it is), but it should explicitly be permitted. David Eppstein, this should deal with your ANI issue, as ANI gets auto-archived every 24 hours while only keeping threads with activity in the previous 60, making it only 25% of the stated age maximum. Animal lover |666| 21:30, 14 January 2024 (UTC)

  No, this does not deal with my issue. My issue is that taking over and forcibly archiving someone else's talk page is an extreme measure, something that should only be done with very good reason. The only reason being promoted here is that somehow (maybe because of something hidden in how they are rendered to html) very long talk pages cause browsers to choke. If the length of the page is what is causing browsers to choke, then we urgently need to address that on the most important talk pages that editors see, our noticeboards. Pushing new rules on user talk without addressing the noticeboards is grandstanding. Making exceptions that allow our noticeboards to be huge because we really need them to stay exactly as they are in order to retain current discussions is sweeping the problem under the rug rather than doing something useful about it. If, on the other hand, it is not a length problem (maybe it is really #images not text size, or maybe some user talk pages have some weird coding that we do not see in the noticeboards) then length is not the problem we need to solve and we are succumbing to the "we must do something! this is something! therefore we must do it!" syndrome. —David Eppstein (talk) 21:37, 14 January 2024 (UTC)

  Unfortunately, Wikipedia is in the real world, where not everything fits into perfect models. Yes, we want all pages to be reasonably short. However , we also want the ensure proper communication can take place at the correct venue. Yes, we should see if we can find a way to reduce the size of ANI; however, we can't hold other policies hostage over that. I came up with my issue before seeing your ANI comment, but the same concern I expressed is the issue with ANI. Animal lover |666| 21:50, 14 January 2024 (UTC)

  This "unfortunately we're in the real world and we must do this thing even though this thing totally fails to address the actual problem" is rhetoric, not a valid argument. —David Eppstein (talk) 22:51, 14 January 2024 (UTC)

  Frankly, I agree, although in the case of ANI it's not quite as straightforward (it is getting archived on a regular basis, it's just so damn high-volume that even a 24h auto-archive doesn't help). The most obvious thing after that would be to split its functions out among several different pages, but as far as I can tell, most efforts to spin up additional noticeboards the last few years have failed for want of adoption. jp×g🗯️ 22:49, 14 January 2024 (UTC)

  The problem is clear. Pages overloading devices. When crashing, this is generally a memory allocation issue of either CPU or GPU by the OS to the browser application. Larger pages with more content and more images, more scripts or other forms of complexity, expand into bigger pages, that need more memory to run and more memory to layout and render. Consider that cheap phones have just 2GB of shared RAM for CPU and GPU, while a Chrome tab on the desktop will easily run in excess of 100MB and you can see how relatively quickly a large webpage becomes problematic on such a device. Next to the main problem, there is the issue of slowness. The time that it takes the server to render a very large page from wikitext to html (20+ seconds) and the transfer time of a very large page (25MB+ is still a lot of data to download for a lot of people using Wikipedia). Now the times at which any of this becomes a problem differs of course for each user, each device, each amount of open browser tabs, each additional script/modification running (CD, or dark mode, and perhaps a inefficient browser extension) and a dozen other factors that none of us can really control. This is why generally, you try to keep webpages small. MediaWiki gives users lots of freedom however to NOT keep pages small. In general for content pages that is less of a problem because a lot will be cached and because people are there to consume the content and willing to wait. There are also things like google snippets and the lead (which generally renders early in the process) that takes away much of the discomfort. On (very active) talk pages however, due to the nature of interactions (lots of edits often quickly succeeding eachother, at the bottom of the page) the cache cannot be used as efficiently and people need to wait for the entire page to render to html, download completely and finish rendering on their screen completely, after which all modifications need to be made in order to interact with the page. You essentially happen to miss every single possible optimization and use every system to their max capacity that way. Notice boards (while often problematic), are less of a problem here as they DO archive, and they DO split out content when a discussion becomes to massive. The most common approach to solving this problem is lazy loading of content/sections with Javascript. But Wikimedians hate lazy loading and they probably hate Wikimedia/MediaWiki developers who would implement this lazy loading even more. The quick and reliable solution is a social one. Show restraint and be considerate towards other users by setting up archiving. —TheDJ (talk • contribs) 22:45, 17 January 2024 (UTC)

  Dynamically loading a large page reduces the effect of limited network bandwidth/computing resources, but browsing through the large page is still a problem. The common approach is to load from the top of the page downward, but with English Wikipedia's tradition of adding new sections at the bottom of the page, this would mean a lengthy, manual scrolling process to see the latest threads. This is arguably worse than just loading the whole page at once, since it requires constant user interaction. The community could invert this tradition, but the need for manual interaction in order to browse would still be present, just in reverse chronological order. This also makes searching the page more difficult. isaacl (talk) 03:17, 18 January 2024 (UTC)

  "but browsing through the large page is still a problem" yeah, if you decide to load every section, you still have a problem. But this is not impossible to solve with lazy loading. Remember that every app with a chat interface works with a bottom first approach. You'd just have to scroll up inside a subcontainer. And searching within a chat isn't uncommon either. Or you can have a forum index, with pagination as a concept (but fora are top first) etc etc. But our current conventions do not match any of the common UI and programming interfaces that generally are used to solve problems like this. —TheDJ (talk • contribs) 12:44, 18 January 2024 (UTC)

  That was Flow, basically. Apparently people hated it enough for WMF to abandon it when they realized the changes needed for IP accounts. Mayyybe someday we’d get similar enhancements to DiscussionTools. Aaron Liu (talk) 14:17, 18 January 2024 (UTC)

  It's pretty technically possible, and in fact is more or less how the mobile-apps talk pages are done -- we made an API that exposes DiscussionTools' parsed data, and the apps display that rather than the raw talk page HTML. Similarly you can see a Special page that does a reformatting of a talk page as a visualization of that same parsed data, which would be pretty functional as a "modern" talk page view if we turned on reply-buttons in it (and, you know, worked out all the edge cases)... DLynch (WMF) (talk) 16:25, 18 January 2024 (UTC)

  Yes, I didn't want to get into details in discussing potential solutions; I just wanted to note that there are problems related to English Wikipedia's current ways of working (and some of them were discussed during the Flow deployment). New search tools or indices would help with searching, but browsing is a common activity for users to get a sense of the topics that have been discussed over time, and seeing the threads in context helps with identifying related clusters. Linking to threads is also common; supporting this would require dynamically loading the appropriate section, thus replacing a basic cross-referencing feature with one that requires the reader's browser to support Javascript (although I personally feel that this is increasingly becoming a necessary default assumption across the web, I understand why minimizing English Wikipedia's dependency on Javascript is a significant concern for some users). Regarding a bottom-first approach: whether the scrolling direction is up or down, that's what I was referring to by reverse chronological order. isaacl (talk) 18:02, 18 January 2024 (UTC)

References

Some perspective (the actual hundred largest user talks)

Lest we restrict ourselves unjustly to shitting solely on EEng for having a talk page that's insanely long and breaks browsers, keep in mind that his is not the longest, nor is he even in the top 10... or top 20... or top 50. Here is the actual table of the top 100 from the database report I set up last night:

#	User talk	Bytes	Last edit		#	User talk	Bytes	Last edit
001	OswaldClara	2096907	2022-11-11		002	DBWikis	2096322	2022-07-27
003	Miya	2088263	2021-07-07		004	MargaretRDonald	2005349	2024-01-12
005	DotCampbell	1987681	2022-11-13		006	Philosopher	1898053	2022-09-27
007	Philip Trueman	1874334	2024-01-08		008	Ruud Koot	1724397	2018-06-08
009	Jeffreyehall	1668661	2020-10-08		010	Waydze	1650960	2023-02-03
011	Chitetskoy	1563820	2023-08-11		012	Dakinijones	1547327	2024-01-12
013	AwfulReader	1495017	2023-09-22		014	Newyorkadam	1472759	2023-08-24
015	Oil0518	1449212	2019-10-11		016	Laru0004	1338263	2022-06-24
017	SireWonton	1332104	2021-08-05		018	Nemigo	1315401	2018-03-07
019	Horai 551	1303942	2023-09-17		020	John Broughton	1295335	2024-01-05
021	Asterixtintin	1293766	2023-09-06		022	Wilbur2012	1281794	2023-12-10
023	R1xhard	1265094	2013-11-20		024	BoyBoom	1241640	2016-04-09
025	Woodstop45	1222475	2016-11-14		026	Masao	1202609	2020-12-07
027	Unician	1166216	2018-11-12		028	Xain36	1164029	2020-02-16
029	JohnChrysostom	1159761	2020-05-17		030	Nightstallion	1149524	2024-01-12
031	Pelagic	1141710	2024-01-08		032	Windroff	1133146	2014-10-18
033	Dr. Sroy	1127666	2020-07-13		034	Vivekprakash92	1123533	2014-07-19
035	Alberto79	1122615	2023-11-17		036	JeremyA	1121412	2018-04-24
037	Antihistoriaster	1107586	2023-09-27		038	ClemRutter	1106093	2023-07-27
039	Compfreak7	1099644	2023-07-12		040	65.30.134.209	1098700	2022-02-05
041	MLKLewis	1094649	2023-12-14		042	EdwardLane	1092472	2023-11-20
043	MrRadioGuy	1083936	2024-01-12		044	Kaly99	1081545	2013-03-10
045	SAgbley	1072255	2023-02-04		046	Cabazap	1061757	2018-10-18
047	DGButterworth	1050974	2015-01-08		048	UncleBubba	1038457	2023-02-06
049	Vivekchidura	1037975	2015-05-20		050	Scottjbroughton	1033690	2013-03-09
051	Daleb1995	1030611	2013-04-22		052	Harkey Lodger	1027718	2013-05-17
053	Bddmagic	1024043	2023-07-26		054	GDibyendu	1008027	2021-01-01
055	HarryAdney	1001130	2023-05-19		056	NostalgiaBuff97501	980093	2019-05-30
057	Susan118	976876	2019-09-01		058	SvenShaw	976515	2014-02-15
059	Arianit	964903	2023-09-29		060	Ettfh	960973	2021-04-25
061	Xyphoid	960925	2023-12-10		062	Frank*Biz	956628	2015-07-02
063	The Illusive Man	951956	2017-04-09		064	WP.NICKNAME.22	950677	2016-04-27
065	Fiddlersmouth	943490	2024-01-01		066	Joefromrandb	935654	2024-01-12
067	Flarpster	934309	2017-03-18		068	Tomdaone	932469	2020-10-01
069	The boss 1998	927097	2023-09-22		070	Xoder	916454	2023-06-30
071	Owula kpakpo	913794	2024-01-09		072	Millelacs	909587	2015-06-16
073	FkpCascais	906309	2024-01-12		074	Tryptofish	906030	2024-01-12
075	Leggomygreggo8	905765	2024-01-02		076	Darrenmarshall	903641	2014-05-14
077	Genius101	903316	2011-10-30		078	Islahaddow	886184	2023-09-01
079	Sue Gardner	883746	2021-03-27		080	Psantora	876876	2019-06-16
081	Cavie78	876176	2023-10-15		082	Stuffed cat	873179	2023-12-28
083	EEng	868147	2024-01-13		084	WWEFreak666	865382	2012-02-07
085	123.176.113.237	865237	2023-09-05		086	M.Hassan-uz-Zaman	864266	2006-12-06
087	Thedeadmanandphenom	863297	2021-01-15		088	Raderick	862978	2010-06-07
089	Wetitpig0	862792	2023-10-31		090	Cosmic Larva	862534	2008-06-25
091	Xbox6	862123	2016-09-16		092	Dingv03	861883	2007-07-20
093	SilverskyRO	861505	2008-04-24		094	Sweet Diva	861040	2007-10-20
095	Black6989	860467	2008-12-04		096	B streiffert	860055	2006-12-07
097	JAB5	859853	2009-06-04		098	David57437	859291	2010-06-02
099	Hair e. pot err	859136	2006-06-30		100	Gamer928	858709	2008-10-27

I opened a thread on WP:AN about this, and I added archive templates to a couple of the pages where the users hadn't edited in over a decade to see how the archive bots handled such a thing. I think that 800 kilobytes is probably a good point to draw a line and say this talk page is too damn long. jp×g🗯️ 23:53, 13 January 2024 (UTC)

I think inactive editors should also get {{not around}}, which opts them out of message delivery.
Huh, Tryptofish is also on that list. COI? Aaron Liu (talk) 00:58, 14 January 2024 (UTC)

I'm not sure what that table is intended to demonstrate. If an editor is not around, then presumably no one will need to contact them at their talk page. That means it doesn't matter how big it is. Riposte97 (talk) 01:36, 14 January 2024 (UTC)

Good point, though I guess it wastes server resources through MassMessaging. Still, there are quite a bit of active editors on there. Aaron Liu (talk) 01:44, 14 January 2024 (UTC)

It's meant to demonstrate the thing that I said in my post: there are a bunch of user talk pages that are too long to be reasonably viewed or edited -- some of them larger than the MediaWiki software even permits a page to be -- and I think they should have archiving set up on them. I made a thread at WP:AN about this last night. Of course it would be possible to go through these and exempt the pages from inactive users, but it will make the list extremely difficult to work through (not to mention that whatever reasons we have for wanting active users to have loadable talk pages don't stop applying if the user is inactive). Since this only has to be done, what, once every fifteen years?, I think it should just be gotten over with. jp×g🗯️ 04:07, 14 January 2024 (UTC)

Be that as it may, it's pretty clear from the above that this proposal is not going to get consensus.

I also note that the experiments you conducted on User talk:Hair e. pot err and User talk:JAB5 do not seem to have been entirely successful - the bots have archived everything to one archive page. Those pages are now enormous. Riposte97 (talk) 09:31, 14 January 2024 (UTC)

Yeah, I note with dismay et cetera. I think the way it works is that the bot archives to one page per run, which is normally fine but becomes problematic if it's run on 14 years of shit at the same time. Oh well. If this is done I suppose it will have to be done with a different bot, or with one-click archiver or sth. jp×g🗯️ 10:05, 14 January 2024 (UTC)

I find it really strange that you thought that this was something to report at WP:AN, and I'm apparently not the only one, because the AN thread was closed pretty quickly. Is anyone seriously thinking that 100 editors should come under administrator scrutiny because of this? Why is this a "Dirty Hundred", as opposed to simply a hundred? (Which I am going to change in this edit.)

In any case, I am in favor of "some perspective". For all the shouting that EEng was the worst of the worst, over the past few days of drama, it turns out here that there are 82 talk pages that, at the time of this analysis, were longer than his. --Tryptofish (talk) 22:06, 14 January 2024 (UTC)

It was apparently an important enough to have been brought up at the admin noticeboard and discussed at length for the one individual person, so I had the creeping suspicion that people might have actually cared about the accessibility issue of many users' talk pages being so long they were literally impossible to render or comment on with many computers. I hope I can be forgiven for this conjecture. jp×g🗯️ 22:45, 14 January 2024 (UTC)

If you think that what I and others have said to you here means that people don't care about accessibility, then you are missing the point. The way to address the accessibility issue is to relate the list you made to whether or not each entry on that list is actually difficult to access. That's useful to discuss. You began your post here by proposing 800 kb as a cutoff. Does the data actually support that? But when you call 100 editors the "Dirty Hundred", some of us are going to push back. --Tryptofish (talk) 22:53, 14 January 2024 (UTC)

I agree. User talk pages that consist mainly of newsletters don't cause bothersome delays for me. Aaron Liu (talk) 23:06, 14 January 2024 (UTC)

EEng's talk page, at the time of his block, was 950k+ bytes long, if I recall correctly. Most of these talk pages are inactive. Aaron Liu (talk) 23:02, 14 January 2024 (UTC)

OK, then, if I take your number of approx. 950 kb, that would put him in the vicinity of 65th on the list, give or take. --Tryptofish (talk) 23:11, 14 January 2024 (UTC)

Yeah, and there are only 6 with a longer talk page who have edited in 2024, assuming nobody else on the list archived their talk pages. Aaron Liu (talk) 00:25, 15 January 2024 (UTC)

We're only two weeks into 2024, so there could be other editors who are still reasonably active. I think you and I agree that talk pages of people who have really been inactive for a long time are not that big a problem, since there will not be much reason for anyone else to communicate with them. --Tryptofish (talk) 00:54, 15 January 2024 (UTC)

Worth noting also that compared to all 6 with a longer talk page, EEng has the highest number of edits, both overall and per annum (given that he has been editing since 2008). This means that he has the largest relative footprint, so users are going to be more likely to cross paths with him as opposed to editors who might not be as prolific. This is likely why the concerns about talk page length are so acute when it comes to him in particular. _{Duly signed,} ⛵ WaltClipper -(talk) 14:49, 15 January 2024 (UTC)

A proposal for handling of long threads on talk pages and noticeboards

One recurring problem is that certain pages (ANI is probably the most frequent offender here, but there are others) tend to get big discussions, making it difficult to use them. I propose the following solution:

1. Create a bot to move any big threads from the page to suboages. The bot will leave behind the thread header with a notice "this thread was moved" along with a link, and some template to prevent the archive bots from archiving this.
2. When a discussion subpage no nlonger has any activity, this bot will archive the section on the main page. Consider some official closure on the subpage itself.
3. Worth considering: make this bot an admin bot, and copy over any protection from the main discussion page to the subpage. Perhaps also put move protection on any subpage, regardless of main discussion page protection.

Animal lover |666| 14:22, 19 January 2024 (UTC)

People (including me) have little problem with accessing ANI. Aaron Liu (talk) 14:34, 19 January 2024 (UTC)

Animal lover says the problem is "use," not "access." I'm not exactly sure what they mean. But count me among those who see long threads and go into tl;dnr mode. I'm not sure that Animal lover's proposal would solve that problem. - Butwhatdoiknow (talk) 15:23, 19 January 2024 (UTC)

I feel like they simply mean replying and reading, which I also meant to include in “access”. Aaron Liu (talk) 16:17, 19 January 2024 (UTC)

I'm really not sure what the proposal is and how it will fix things. _{Duly signed,} ⛵ WaltClipper -(talk) 18:22, 24 January 2024 (UTC)

This seems to propose a bot to move large threads to their own subpages of ANI. I don’t think the problem exists either. Aaron Liu (talk) 18:42, 24 January 2024 (UTC)

Why would we need a bot to do this?

The only example I can think of of discussions having their own pages is WP:RFCTP. (See [5] for a recent example of someone moving an existing discussion to its own talk page due to length). The manual system works just fine for RfCs.

I'm not convinced there's a need to move ANI threads automatically (or at all), but I think the first step would be to gain consensus for the process of creating new subpages and then, and only then, file a bot request for approval. Sincerely, Novo Tape^{My Talk Page} 18:58, 24 January 2024 (UTC)

How about responding to my proposal, as opposed to complaining about my wording? Animal lover |666| 21:50, 22 January 2024 (UTC)

I don't see the point of this and I haven't seen much people having trouble with using ANI. Aaron Liu (talk) 23:16, 22 January 2024 (UTC)

Standardize indentation of threads?

EEng brings up another issue, he/she/they refuse to abide by what to me is the canonical indentation used as WP:THREAD and possibly also break for some purposes the "lists" used to store threads.

The standard format is this:

Comment, December 31

Reply, January 1

Reply to reply, January 1

Reply to reply, January 3

Reply, January 2

EEng's User's reply, January 3

EEng does Some people do this:

Comment, December 31

EEng's User's reply, January 3

Reply, January 1

Reply to reply, January 1

Reply to reply, January 3

Reply, January 2

Does this affect any screen readers or such which are relying on the format of the list? To me, I don't see why EEng any user's comments are so import they should be inserted out of time order and before all prior responses. It's confusing, and not only that, EEng does this double indentation which is apparently his/her/their own concoction.

Should we enforce a standardized indentation for replies per the examples at WP:THREAD? I.e. if someone wants to reformat the page to adhere to that, should they be allowed to without being considered to have modified someone else's comments? This would codify the way the [ reply ] link works and to my mind support further automation of talk pages. —DIYeditor (talk) 15:44, 11 January 2024 (UTC)

• support, per "there's a button for that, it takes one click to do the thing right, use it" cogsan _{(nag me) (stalk me)} 16:26, 11 January 2024 (UTC)
• Oppose In the example given, it appears that EEng positioned their reply to be adjacent to the comment to which it was a direct response. If their reply had been positioned further down, as the OP suggests, then the context would have been lost and so the comment would have been more difficult to follow and make sense of. I've done the same thing myself more than once for much the same reason and used the same double indent to indicate that it was a tangent. My own usage is an independent invention and this indicates that it's a commonsense way of handling such threading when there are multiple lines of conversation. The Reply tool is a more recent innovation which is still shaking down and we are not required to use it or follow its logic slavishly. Andrew🐉(talk) 16:52, 11 January 2024 (UTC)
• There are a few editors who do this; it's not a scalable approach (if more than one person decided their response was a more direct response that the current subsequent response, there would be an escalating race of nesting levels), so it relies on the goodwill of editors to not dispute which comment is most fitting for the immediately following spot. It causes screen readers to make extra list start/end announcements, but since the point of the extra nesting level is to give the comment more prominence, this might be considered an aural equivalent. isaacl (talk) 17:09, 11 January 2024 (UTC)

  Discussions on Wikipedia are generally not scalable and usually collapse into incoherence once the coefficient of inefficiency is reached. That's not so much due to the technical issues as it is a consequence of everyone trying to talk at once. Serious committees usually have a chair and rules of order to ensure that the business gets done. Here's an example:

  Then Compton, for example, would explain a different point of view. ... So everyone is disagreeing, all around the table. I am surprised and disturbed that Compton doesn't repeat and emphasize his point. Finally, at the end, Tolman, who's the chairman, would say, "Well, having heard all these arguments, I guess it's true that Compton's argument is the best of all, and now we have to go ahead." It was such a shock to me to see that a committee of men could present a whole lot of ideas, each one thinking of a new facet, while remembering what the other fella said, so that, at the end, the decision is made as to which idea was the best—summing it all up—without having to say it three times. These were very great men indeed.

  — R. P. Feynman, Surely You're Joking, Mr. Feynman (1985)

  Andrew🐉(talk) 18:41, 11 January 2024 (UTC)

  Yes, I've written previously about the problems with Wikipedia's unmoderated, multi-threaded discussions. Editors deciding on their own that their comment is best suited to be the first to follow a given comment is a different problem, though. It doesn't help foster consensus-building when there is a disagreement on the placement. isaacl (talk) 22:02, 11 January 2024 (UTC)

• Oppose. Talk page formats are for the benefit of the people communicating to each other, not a cage we must keep rigid to prevent them from communicating to each other. —David Eppstein (talk) 17:47, 11 January 2024 (UTC)
  • Comment: I worry about rule creep. Doing anything on Wikipedia for the first time is intimidating. There are already a million rules and guidelines and essays spread across hundreds of pages, and it's hard to know which are important. Wikipedia:Talk_page_guidelines is already 6500 words, and might take 20 minutes or so to read. Every additional guideline is another thing for a newbie to trip over, and another reason to worry "Will I get in trouble for screwing this up" instead of feeling encouraged to jump in and contribute. As I'm typing this right now, part of my mental energy is worrying I'm replying wrong :) . This isn't a reason for total anarchy, of course, but I think we should have a stronger rationale than "One guy does this and it's slightly annoying" or "This might cause problems for a hypothetical screen reader".
    Ghosts of Europa (talk) 17:51, 11 January 2024 (UTC)

    The "hypothetical screen readers" are actually real people like myself who are unable to edit, or even read, these talk pages. Thank you. ChaotıċEnby(t · c) 20:58, 11 January 2024 (UTC)

    Sorry if my comment sounded dismissive. The proposal framed the possibility of broken screen readers as an open question, like there were no clear examples of it happening. If you're actively hitting a severe accessibility problem, that's a much stronger case for a rule. Ghosts of Europa (talk) 21:58, 11 January 2024 (UTC)

  • And, of course, I did end up replying to this thread incorrectly. I meant to reply to the top-level comment :) . This kind of thing isn't always straightforward for newer editors. Ghosts of Europa (talk) 17:55, 11 January 2024 (UTC)

  It's not like you would be punished for the making the mistake. The question is whether someone else is allowed to go back and fix it. —DIYeditor (talk) 18:54, 11 January 2024 (UTC)

  Precisely. I'd love to see one solitary case where an editor has gotten in trouble for misplacement or misindentation of a reply (is this a reply to DIYeditor, or Ghosts of Europa?). Absent such an example, the concern is greatly overblown. ―Mandruss ☎ 19:17, 12 January 2024 (UTC)

• If someone wants to discuss talk page guidelines, of course that's fine. But starting the opening post with yet another "EEng refuses" to do something-or-other is highly inappropriate. This is not a talk page for editors to post about whatever in particular rubs them the wrong way about any particular editor. --Tryptofish (talk) 18:05, 11 January 2024 (UTC)

  Yeah, I realized that, and I had thought about going back and stripping the post of that context. Too late now. —DIYeditor (talk) 18:52, 11 January 2024 (UTC)

• Comment I've occasionally done the same thing as shown in the example. When the response thread under "reply to Jan 1" is really long, it makes it confusing to put another reply to Dec 31 a mile down the page and I thought it it would solve that issue. And I think that the extra indent meets the intent of the chronological rule? North8000 (talk) 18:29, 11 January 2024 (UTC)

  English Wikipedia has a talk page tradition of putting new comments at the end, though, so interjecting one's response ahead of earlier ones isn't what readers are generally expecting, particularly if they're reading the thread for the first time and so will be reading the first level of direct responses out of order. (It is true that with the relatively recent thread subscription feature, it's easier to find new comments wherever there are. But this still involves scrolling through the thread to find highlighted comments, or going back to your notification list and selecting each new comment one at a time. Alternatively, history diffs can be used (and I find the visual diff mode makes it more readable), but it only lets you see part of the surrounding context.) isaacl (talk) 22:15, 11 January 2024 (UTC)

  For as long as I remember being here, top-posting has been something that editors do. Personally, I don't feel like it's unexpected when I see it. If the post is something where there's a logic to putting it up there, I'm not that bothered by it. --Tryptofish (talk) 22:20, 11 January 2024 (UTC)

  And if (generic) you disagree with the logic of someone putting a post above your response, which you carefully crafted to respond directly to the initial comment? Usually it would be just a distraction to argue about it, so you grit your teeth and live with it, even as it adds a bit of friction to the discussion. isaacl (talk) 22:27, 11 January 2024 (UTC)

  (Note that I'm top posting above North!) Generic me agrees with you about that, and I've certainly experienced that from time to time. But there's friction, and there's friction, so to speak. Some kinds of friction really get in the way of what editors are here to do. This kind of friction strikes me as usually being something where the most sensible reaction is to shrug it off. --Tryptofish (talk) 23:56, 11 January 2024 (UTC)

  Yes, I agreed that not doing anything about it is the best approach, in interest of fostering a productive discussion. (Outdenting a comment makes it hard to continue the usual list nesting traditions in English Wikipedia discussion threads. Usually I will reset the conversation with no nested list levels.) isaacl (talk) 00:06, 12 January 2024 (UTC)

  For review: posting style. Viriditas (talk) 00:00, 12 January 2024 (UTC)

  I think that that is a good tradition, albeit it only applies for comments at the same indent. For example, in:

Jan 1 post

Jan 2 response to Jan 1 post

Jan 3 response to Jan 1 post

Jan 5 response to Jan 3 post

Jan 4 response to Jan 1 Post

The Jan 5 response is supposed to be higher up than the Jan 4 response. North8000 (talk) 22:31, 11 January 2024 (UTC)

• Oppose. No set of rules will be both sensible and simple. And who is going to police it? There are occasional newbies who need to be taught how to indent, but otherwise this is a solution in search of a problem. Zero^talk 01:52, 12 January 2024 (UTC)

  My question is am I allowed to reformat pages to adhere to the format the [ reply ] link uses, or is it ok to be subjected to "don't ever fuck with my comments again" in response to doing so? —DIYeditor (talk) 14:03, 12 January 2024 (UTC)

  I believe the spirit of TPG (can't put my finger on the letter) is that you can BOLDly do that, but should let the user have their way if they subsequently object. I don't think it's reasonable for any editor to ask you to maintain a list, mental or written, of editors who never want their comments fucked with. If they don't want that, they should have to object repeatedly, case by case. ―Mandruss ☎ 19:28, 12 January 2024 (UTC)

  One might be "allowed" to reformat in that way, but it's also prudent to evaluate ahead of time whether doing so is worth it. If one suspect that the response will be an angry one, it's not worth the drama to poke at it. --Tryptofish (talk) 20:04, 12 January 2024 (UTC)

  Agreed. Angry editors are a fact of life around here, and that's not going to change until we repeal human nature. ―Mandruss ☎ 20:13, 12 January 2024 (UTC)

  (I'm half-expecting that someone will propose that we repeal human nature.) But seriously, this is an important point. (In fact, it's one Talk Page Guideline that I could gladly get behind.) Part of what WP:IAR really means is that maintaining a collegial editing environment, with a focus on improving mainspace content, is more important than rules for rules sake. Just being "right" about talk page indenting, or talk page length, is something that should be balanced against how counterproductive it can be to have a multi-day drama-fest. --Tryptofish (talk) 21:51, 12 January 2024 (UTC)

• Vehemently oppose. We have better things to do that act as "posting cops" against other editors just to be anal/obsessive. Sometimes it makes sense to inject a reply higher up than one would normally do it, though the cases when this is useful are not all that common. But we have no reason to refactor list formatting other than to comply with MOS:LISTGAPS problems (blank lines between list items, or switching list formats mid-stream, like replying to *:: with ::: for no damn' reason). If you really care about misuse of list formatting, read MOS:DLIST, and then go around in articles (not talk pages) fixing abuse of : for non-list, purely visual indentation of material, replacing it with {{block indent}}. That would actually serve a real user-facing purpose, including for those with screen readers. While you're at it, replace abuse of ; for non-list, purely visual boldfacing, using '''...''' (or {{strong}} if it is semantic emphasis, though the majority of the latter can and should be replaced with {{em}} instead, per MOS:TEXT). NB: Sometimes an extra linebreak is needed, if the ; is being abused for a MOS:PSEUDOHEADING and is butted up against the content that immediately follows (the ; format injects a line-break, but '''...''' does not).  — SMcCandlish ☏ ¢ 😼  03:43, 13 January 2024 (UTC)
• Comment - I've lost count, the number of times editors failed (deliberately or not) to follow correct "indenting" & more so "outdenting", in discussions. GoodDay (talk) 22:32, 16 January 2024 (UTC)

Removing material from article talk pages

A dispute arose about an article talk page a little more than two weeks ago. One editor had made some long comments on the article talk page that another editor thought were using Wikipedia as a forum, how-to guide information, and original research. The other editor deleted the material to which they objected. The editor who had posted the material objected to the deletions, and wanted to discuss the deletions at DRN. I initially did not want to discuss the deletions at DRN, because it is for article conduct disputes, not for disputes about other types of pages. I reviewed the talk page guidelines, and concluded that they are unclear as to when material should be deleted from talk pages, as opposed either to collapsing or to archiving. A complaint was made to WP:ANI, but that was closed as a content dispute, outside the scope of WP:ANI. I agreed to conduct moderated discussion under a rule that I wrote for the purpose of discussing talk page edits. The moderated discussion failed, for reasons that I will not go into here. However, my takeaway from reading the talk page guidelines several times is that they are vague about removal of material from article talk pages. In my opinion, the collapsing or archival of material on article talk pages should normally be recommended as an alternative to deletion. If that is the intent, and I have inferred that some editors agree with me, the policy should say that.

Also, since the deletion of material from talk pages is likely to be controversial, it would be helpful if the guidelines said something about the resolution of disputes caused by any sort of removal of talk page material. Where can talk page removals be discussed? Controversial edits to article pages are discussed on article talk pages. Where are controversial edits to talk pages discussed? Is the lack of an obvious answer to that question a reason to minimize the editing of talk pages?

Should the guidelines on removal of material from article talk pages be clarified? If they are already to clear to other editors, but not to me, can someone explain what is missing in my reading of them (as opposed to being missing in the writing of them)? Robert McClenon (talk) 21:25, 1 February 2024 (UTC)

I would like to remove a talk discussion that has been labeled a non stater. With the others opinions included. Any help would be greatly appreciated. EnlightenedIllusions (talk) 21:46, 1 February 2024 (UTC)

User:EnlightenedIllusions - If the discussion has been a non-starter, it makes sense to archive it or collapse it. If you are saying that a discussion that is a non-starter should be deleted, I disagree. Robert McClenon (talk) 02:54, 2 February 2024 (UTC)

WP:TALKOFFTOPIC clearly states that it is appropriate to simply delete gibberish, test edits, harmful or prohibited material (as described above), and comments or discussion clearly about the article's subject itself.

Usually, when it's clear that the user made an honest mistake, I just let them know they shouldn't. Otherwise, I delete. I have encountered too many cranks disrupting talk pages to be shy about that.

Judging from the only time I have been taken to AN, I'd say I'm toeing the party line here. ;) Paradoctor (talk) 00:25, 2 February 2024 (UTC)

I’ve also seen rather too many people removing content with which they merely disagree. I’d say greater clarity is needed. The current situation is too open to disruptive removals. Riposte97 (talk) 01:41, 2 February 2024 (UTC)

The basic rule, with exceptions outlined below, is to not edit or delete others' posts without their permission.

Clarity is not the problem. People being ignorant of the rules is. That's not a problem we can solve here.

Question: Did you inform the people inappropriately removing content of their mistake? What happened? Paradoctor (talk) 01:57, 2 February 2024 (UTC)

I made the mistake. EnlightenedIllusions (talk) 02:10, 2 February 2024 (UTC)

In the original post case, the removal was not a mistake, because the editor who deleted the content had read the guideline, and thought that the post was inappropriate, and thought that they should have deleted it. That wasn't ignorance of the rules. They interpreted the situation as being one of the exceptions. I agree with User:Riposte97 that greater clarity is needed. Robert McClenon (talk) 02:54, 2 February 2024 (UTC)

I'd love more clarity on when talk page content removal is appropriate. Like Riposte97, I've also seen over-eager removal of comments with little policy/guideline basis, and it's often apparent that the reason for removal is just disagreement with the points being raised. On the flip side, I've seen wiki-lawyering over restoring removed comments that consisted of obvious policy violations, or which were so unaligned with any encyclopedic purpose that removal would improve or maintain the project. Comment removal is, in my experience, common. It seems to live in a grey area of our rules, and I think it would be beneficial to bring it more into black and white.

One small change that could help is changing "Delete. It is common to simply delete gibberish, test edits, harmful or prohibited material (as described above)" to "Delete. It is common to simply delete gibberish, test edits, harmful or unacceptable material (as described above)" with the changes in bold. Changing from "prohibited" to "unacceptable" matches the language used in the section WP:TPNO, and linking to it would aid editors in understanding what is being referenced. Firefangledfeathers (talk / contribs) 03:08, 2 February 2024 (UTC)

Definitely better to collapse or archive it, unless it's an attack against the subject, blatant spam, vandalism, nazi ranting, or something else we'd nuke on sight. Don't ever be the one who gets ANIed for deleting other people's discussions simply because you seem to disagree with them. It takes little more effort to just archive or hat it than to zap it completely.  — SMcCandlish ☏ ¢ 😼  10:37, 2 February 2024 (UTC)

It was five to one against my proposed question. My question drew away from the original issue at hand. It was deamed a nonstarter. I decided to remove the conversation. EnlightenedIllusions (talk) 16:05, 2 February 2024 (UTC)

Knowing that a proposal doesn't have consensus support can be important to understand for future editors. I appreciate that you might feel discouraged or other emotions about making a failed proposal. Assuming you made the proposal in good faith, though, then the discussion was at least in part constructive, and so deleting other people's comments versus just collapsing the content is counter to English Wikipedia's discussion traditions. isaacl (talk) 18:12, 2 February 2024 (UTC)

Most of the discussions I remove either contain no words recognisable by me or Google translate, or consist only of someone's name, phone number and/or social media account. It's important to retain anything vaguely relevant to the associated article or page, even if the ideas it contains would be unanimously opposed, with the usual defamatory or insulting exceptions. Certes (talk) 16:19, 2 February 2024 (UTC)

If one looks at the top of, for example, Talk:Ayurveda (among other examples), where there are active ArbCom remedies, there is a statement that "Please note that due to disruption of this page, if you have come here to object to the use of the words "quackery" or "pseudoscience" in this article, your comment will be removed without reply if it does not give a policy-based reason why these terms are incorrect." In my experience, such comments show up on such talk pages close to daily; it's a constant onslaught. Sometimes, they get replied to and the discussion eventually gets closed, and sometimes they just get removed. --Tryptofish (talk) 20:04, 2 February 2024 (UTC)

That's a difficult one. On the one hand, every editor should have a right to put their case for amending an article politely on a talk page without it being summarily deleted. Viewed in that light, the statement seems passively (and perhaps actively) aggressive. On the other, although consensus can change, we don't want to waste time revisiting every point which has already been decided every week. I would be inclined to reply with a standard response linking to the ArbCom decision and leave the (hopefully brief) discussion to be archived, rather than risk appearing to censor it. Certes (talk) 22:25, 2 February 2024 (UTC)

I share your ambivalence. If other editors haven't gotten there before I do, I usually give such a brief response, especially when the comment sounds sincere, but when the comment is outright obnoxious, I've sometimes reverted. --Tryptofish (talk) 00:08, 3 February 2024 (UTC)

Any time there is uncertainty about whether something should be deleted or not, it should instead be collapsed with {{collapse top}} along with a title bar indicating a justification (NOTFORUM, etc.). Outright removal should be by consensus, not by the act of a single editor, except for an admin acting in their capacity as admin. (I can see an argument for someone acting in their capacity as an experienced moderator neutrally applying moderated discussion rules as well, but that should be discussed further.) Even if a large amount of content is involved ( as in this 26kb removal) collapsing should be the first remedy. Once something is collapsed, it ceases to encumber the flow (and the scrolling) and can always be deleted later; and if the collapse was unwarranted, it can easily be undone, no matter how many intervening edits have happened, whereas undoing a removal after intervening edits could be so complex as to make it unlikely anyone would attempt it. This favors the unilateral remover, and simply cannot stand. Mathglot (talk) 04:57, 3 February 2024 (UTC)

Talk:January 6 United States Capitol attack/Archive 21. Is this the issue being discussed? I still have access to it. Can someone tell me if the Nonstart subject matter is available to the community. I will try to do anything I can, to do the proper order of operation. EnlightenedIllusions (talk) 05:20, 3 February 2024 (UTC)

WP:NOT is policy and it says quite clearly that article talk pages exist solely to discuss how to improve articles; they are not for general discussion about the subject of the article. Emphasis added. I routinely delete article talk page comments that contain no plausible discussion of how to improve the article, with an edit summary of WP:NOTAFORUM. In my view, "vaguely relevant" is far too low a threshold. Comments like " "I am the biggest fan of celebrity X" or "I think celebrity Y is overrated" or "Hey celebrity Z, I am going through hard times and I am hoping that you can help me pay my hospital bills" are all "vaguely relevant" but still should be deleted on sight. Collapsing this kind of stuff just encourages curious editors to uncollapse and waste their precious time. Cullen328 (talk) 05:45, 3 February 2024 (UTC)

Indeed. But I think the really relevant bit of WP:NOTFORUM is Material unsuitable for talk pages may be subject to removal per the talk page guidelines. (my emphasis) Paradoctor (talk) 07:25, 3 February 2024 (UTC)

I'm the party who is guilty of starting this issue, so my thoughts may be highly biased. Here are my two cents.

You have got no less than three separate problems at hand:

1. decide under what circumstances is a removal of article talk page content allowed
2. update the WP:TPG so that it reflects the decision (with more clarity than the current guideline)
3. figure out a "method" that enables an editor to contest an instance of talk page content removal; the "method", whatever it turns out to be, would be subject to abuse by frivolous objections, and that must be taken into account; the "method" must be obvious (perhaps: described in WP:TPG ), in order to prevent future inappropriate talk page content removals.

Z80Spectrum (talk) 05:47, 3 February 2024 (UTC)

It's not possible to write down rules for when inappropriate commentary is bad enough to warrant removal. Normal Wikipedia procedures will have to apply, namely someone will do a bold removal with a polite explanation in the edit summary, then others can decide if they feel like making a fuss. Johnuniq (talk) 06:48, 3 February 2024 (UTC)

"then others can decide if they feel like making a fuss" - I see a problem with this part. Who are the "others"? Uninvolved editors might interpret WP:TPG incorrectly, due to a lack of clarity in the guideline. In my case, the end result was highly towards "remove" action, while most opinions on this page seem to be gravitating towards "keep", "archive" or "hide under hat".

Perhaps a venue should exist for contending talk page deletions, where complaints would be examined by experienced editors. Z80Spectrum (talk) 07:33, 3 February 2024 (UTC)

@Robert McClenon: WP:TPO already says: Cautiously editing or removing another editor's comments is sometimes allowed, but normally you should stop if there is any objection. That is an incomplete answer to your OP, but does seem to cover at least a portion of it. If you "ran the zoo", what changes would you make to the guideline? I'm a little concerned that this is enough of an edge case that we can't write rules around it without an unacceptably high amount of instruction creep, but I believe I could be convinced of a change if others felt strongly otherwise. VQuakr (talk) 07:07, 3 February 2024 (UTC)

• Note that the Arbitration Committee has defined some cases where removal of talk page content is explicitly permitted, see WP:ARBECR. Zero^talk 10:57, 3 February 2024 (UTC)

  Don’t overthink it. If you think a talk page comment is inappropriate, feel free to remove it… BUT… if it is returned, don’t edit war by removing it again. Instead, either ignore it (usually the best option) or briefly respond but don’t engage further. Blueboar (talk) 15:59, 3 February 2024 (UTC)

  ^ That's the best advice that I have seen about this. --Tryptofish (talk) 23:44, 3 February 2024 (UTC)

  I agree if the material is innocuous, but if it is the type of thing that ArbCom made the rule in order to exclude, then it should be excluded and the unqualified editor should not be able to bludgeon it back in. Otherwise there is no point to having the rule. Zero^talk 12:36, 4 February 2024 (UTC)

  Again, my thinking … If another editor is insisting on returning the sort of material ArbCom has a rule about, I probably need to bring it to the attention of an admin (or at least other experienced editors), and let them deal with it. In the meantime… I should not make the situation worse by engaging with the disruptive editor. Blueboar (talk) 13:57, 4 February 2024 (UTC)

Some Follow-Up Comments Regarding Removing Material

I have a few comments. First, I will restate that I think that the editor who deleted a post because it was a non-starter was acting in good faith but was seriously mistaken. There was a consensus against the proposal, and a consensus should be recorded. A second editor might offer the same idea, and seeing that it was already considered and dismissed may avoid spending more time on a non-starter.

Second, the talk page guideline on removal of off-topic material is interpreted differently by different editors, some of whom do not think it is unclear, but have different ideas as to what it means. That is even worse than a guideline that is widely recognized as unclear.

Third, in my opinion, the guideline should state clearly that collapsing or moving off-topic material is usually preferred over deletion, unless the material is harmful, inappropriate, or nonsensical. The guideline doesn't say that at present. Some change to the guideline to state that collapsing or moving is normally preferred over deletion is the main change to the guidelines.

Fourth, the situation in which ArbCom authorized deletion of talk page posts appears to be when the topic area is subject to Extended-Confirmed Protection as a contentious topic, but where the page has not been protected to enforce the restriction. That was not the case in the original example.

Fifth, where should disputes over the deletion, moving, or collapsing of talk page posts be discussed? Disputes over the editing of the article are discussed on the talk page. Where can disputes over the editing of a talk page be discussed? Robert McClenon (talk) 05:38, 5 February 2024 (UTC)

This is very sensible. I’m in favour of you making the changes proposed in your third point.

Regarding your fifth point, an independent venue for this seems excessive. Perhaps this page can be updated to make clear that inappropriate removal of talk page content is disruptive and within the purview of ANI. Riposte97 (talk) 07:14, 5 February 2024 (UTC)

where should disputes over the deletion, moving, or collapsing of talk page posts be discussed?

What are we doing, right here, right now? Asking for a friend. Paradoctor (talk) 08:10, 5 February 2024 (UTC)

As I see it, point #3 is the one that is potentially actionable on this talk page, beyond simply exchanging thoughts, as it suggests a revision to the page. If I put it as a proposed addition, it might be: Collapsing or moving off-topic material is usually preferred over deletion, unless the material is harmful, inappropriate, or nonsensical. I don't disagree with it, but I'm also not convinced that it's really needed. Between saying only that it is "usually preferred", and by not defining "inappropriate", it becomes a pretty minimal guidance. I'm concerned that it would lead to more arguments over how to apply it, than to clarity over the right thing to do. --Tryptofish (talk) 00:12, 6 February 2024 (UTC)

Here is my suggestion for update of WP:TPG. Feel free to improve it.

Cautiously editing or removing another editor's comments is sometimes allowed, but normally you should stop if there is any objection. If an objection is raised, the removed comments should be restored, unless they obviously violate guidelines on this page. Removals of talk page contents are contestable at WP:ANI.

If you make anything more than minor changes, it is good practice to leave a short explanatory note such as "[potential libel removed by ~ ~ ~ ~]".''

- Z80Spectrum (talk) 01:05, 6 February 2024 (UTC)

The following is not yet an RFC, but in the near future, either this or something similar will be an RFC. Robert McClenon (talk) 14:33, 7 February 2024 (UTC)

Proposal 1: Off-topic posts

I suggest that we add after the three bullet points Collapse, Move, and Delete, three more bullet points:

• Note 1: When there is any doubt as to how to deal with off-topic posts, or posts that use the talk page as a forum or soapbox, the material should be collapsed or moved rather than deleted, because deletion is likely to prove controversial.
• Note 2: Talk page posts that are inappropriately collapsed, moved, or deleted may be restored, but restoration is likely to prove controversial.
• Note 3: Misuse of talk pages is considered disruptive editing, and disputes over the removal (collapsing, moving, or deletion) of talk page content may be taken to WP:ANI, but an editor should read the boomerang essay before any report to a conduct forum.

Robert McClenon (talk) 14:33, 7 February 2024 (UTC)

deletion is likely to prove controversial Not my experience. Sure, occasionally I get pushback, but in most cases where I delete stuff, it sticks the first time. Paradoctor (talk) 15:42, 7 February 2024 (UTC)

When reading the suggested additions, I see almost nothing that connects them specifically to "off-topic" posts. In my view, the suggested additions apply in general, so they should be added before the "Examples" bullet list.

Also, "Note 2" is vague again. The word "inappropriately" can be interpreted in many ways. It must somehow describe what should be restored, with more precision. For example: "Most cases of appropriate removals are described in the Examples bullet list below". Z80Spectrum (talk) 17:36, 7 February 2024 (UTC)

My impression is that, if this were proposed as an RfC, it would be unlikely to get consensus, as WP:CREEP. --Tryptofish (talk) 22:41, 7 February 2024 (UTC)

I agree. So, if there is a proposal, the text to be added must be kept short and concise and precise. However, we are currently just discussing what should be added, as a first approximation.

Also, when an RfC is proposed, it would be good if we can present evidence of confusion and misinterpretation by multiple editors. So, after we agree on the text, we should find examples of previous interpretations that are in obvious contradiction with the new clarified text. Z80Spectrum (talk) 23:46, 7 February 2024 (UTC)

I do not think Note 1 is helpful, it leans towards filling talkpage archives with junk. Further, when there is doubt, in my experience the usual practice is simply to leave it. Collapsing is used when a topic is disruptive in other ways than being off topic, such as duplicating another discussion or breaking a moratorium. Note 2 seems redundant, all reverts may be controversial. 3 is fine but also obvious, not sure it needs stating outside of perhaps the "Misuse of talk pages is considered disruptive editing" point. CMD (talk) 11:02, 8 February 2024 (UTC)

On the contrary, I think note 1, or something similar, is certainly needed. The present position is that posts that an editor unilaterally deems junk are removed entirely. That’s not helpful. I propose that the standard approach be to collapse, and then letting the archive bot deal with it. I’ll try my hand at drafting something based on Robert’s point.

In terms of examples, one that springs to mind can be found here. In that instance, a user offered the fact I had restored disputed content to a talk page as a point against me in a discussion about banning me. Riposte97 (talk) 21:44, 8 February 2024 (UTC)

Wikipedia:Talk page guidelines § Editing others' comments doesn't say that that editors can delete any comment they feel is junk. It cautions against editing or removing comments by others, discusses what types of posts may be considered harmful, and discusses different ways of handling off-topic comments. isaacl (talk) 22:58, 8 February 2024 (UTC)

WP:TALKOFFTOPIC says It is common to simply delete gibberish, test edits, harmful or prohibited material (as described above), and comments or discussion clearly about the article's subject itself (as opposed to ... the article). The last point is also covered by WP:NOTFORUM. Certes (talk) 23:09, 8 February 2024 (UTC)

Yes, this is part of the discussion to which I referred. It's within context of the overall discussion that advocates caution and discusses other ways of handling comments than deleting them. isaacl (talk) 23:19, 8 February 2024 (UTC)

Your example (this one, I guess) is too complex to immediately decide, in my view. It might be considered (or not) that the contested talk-page content was both harmfull (i.e. insulting) and untrue. But, I can't tell, because I'm not an expert in the field. Z80Spectrum (talk) 23:51, 8 February 2024 (UTC)

I don’t believe one need be a subject matter expert to observe the following:

• Nothing in the contested comment is harmful. It does not contain a directed personal attack. Generally being insulting is not a ground for removal.
• Being untrue is not a ground for removal.

Herein lies the nub of the problem. There is so much confusion surrounding the rules that you and I cannot agree even with the benefit of the preceding discussion. Riposte97 (talk) 01:12, 9 February 2024 (UTC)

I think that generally being insulting could be a ground for removal. But I can't tell whether your example is insulting or not, and neither can most people. I won't go look up what AGM is, because it would be like a sheep staring at the airplanes. Z80Spectrum (talk) 02:43, 9 February 2024 (UTC)

I won't go look up what AGM is That's the problem. Had you looked at the context the comment was made in, you'd have seen that that "AGP" is used there as shorthand for "autogynephilia". Or you could simply have looked it up at AGP.

You being confused here is on you. If you don't read the rules, which includes investigating anything unclear to you, then their clarity doesn't really matter, does it? Which brings us back to what I already said: This is not a problem that can be solved here. Paradoctor (talk) 08:10, 9 February 2024 (UTC)

Completely disagree. We are here trying to clarify the rules for talk pages, not trying to clarify what AGP is, and whether it insulting or not to make an implication that some group of people has AGP.

Also, nobody here is contesting that insulting material should be removed. So, the one being confused is you. Z80Spectrum (talk) 08:31, 9 February 2024 (UTC)

If the only objections to the contested comment are WP:NOTFORUM and WP:TALKOFFTOPIC, then the comment should not be removed. Z80Spectrum (talk) 10:36, 9 February 2024 (UTC)

Offtopic material is harmful: it frequently provokes editors into wasting time, and it frequently drowns out constructive material. I've seen quite a few talk consistingly almost entirely of offtopic stuff. Good luck searching for previous consensus on something in such a mess. Or simply navigating to what you need.

You may have noticed (or not) that the policy WP:NOTFORUM only mentions deletion explicitly. Moving/collapsing/arching are deletion lite, i. e. compromises useful only to avoid drama when participants may be expected to go ballistic, when behavioral issues can be expected to arise. Fighting to keep offtopic material on display borders on disruption, and often migrates there. Paradoctor (talk) 10:54, 9 February 2024 (UTC)

While off-topic material is harmful, I don't see the contested comment as being terribly WP:TALKOFFTOPIC. The only point you might have correct is that the discussion seems to be about creating a new article, and such discussion might not necessarily belong to the contested talk page. But, this is a very edgy issue. "Collapse" would have certainly been a better option in this case, IMO.

I don't see the contested material as violating WP:NOTFORUM, as it primarily applies to the article content, and not to the talk page content. Talk pages are there to discuss various concerns, and that is exactly what the contested comment is doing.

I repeat, unless an objection is made that the contested comment is harmful (i.e. insulting), the comment should (probably) not be deleted. The editors who originally objected to the contested comment and to the Riposte97's actions can clear up the question whether the comment is insulting or not. Z80Spectrum (talk) 11:28, 9 February 2024 (UTC)

Missed that you were talking about that particular contested comment. I thought you were talking in general: We are here trying to clarify the rules for talk pages, not trying to clarify what AGP is After all, this is what the present discussion is about, a proposal to change the guideline.

As regards the example you mentioned, that should not have been deleted, neither insulting nor off-topic. Could we move on now? Paradoctor (talk) 11:55, 9 February 2024 (UTC)

I don't see how that example is relevant here. This subsection is about off-topic posts, your example was not removed due to being off-topic. CMD (talk) 07:11, 9 February 2024 (UTC)

There's no harm in simply blanking any kind of FORUM or SOAPBOX post and if it is controversial then let it be restored. 99% of the time the violator will simply go away. —DIYeditor (talk) 13:03, 9 February 2024 (UTC)

Request for input regarding talk page use

There is a discussion and dispute regarding addressing a talk page post by an ip that may or may not be trolling or a legitimate request. Your input at User talk:Thinker78#Chemtrails is requested; cordial, objective input is welcome, to provide additional insights. Regards, Thinker78 (talk) 00:27, 10 February 2024 (UTC)