The following RfC concerns a set of proposals be implemented for all pages intended for user communications (e.g. (X) talk: pages and noticeboards in the Wikipedia: namespace) A short summary of the complete set of changes:Full changes, along with the reasoning, is presented in the collapsed table.

Do you support these changes as presented in the table below? If not, which specific parts of the changes do you not like?

A very similar set of ideas was previously discussed at the idea lab section of the Village Pump, where I got some encouraging feedback. Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)[reply]

Collapsed for clarity

Policy/guideline	Before	After	Reason
WP:TALKSIZE	Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page.	All pages intended for communication between users have to be reasonably accessible. Their size must not substantially impact device/browser performance while reading or editing.	The whole premise of the RfC.
		All pages intended for communication between users must have some sort of automated archiving deployed. This concerns all (X) Talk: pages, and noticeboards in Wikipedia: namespaces. There are two possibilities: A user can deploy an archiving bot A bot can generate pages for a given period that are assembled in a log (see example here). Discussions are started directly on these subpages. This is the procedure used at various venues to discuss potential page deletion. The period should be adjusted so that each individual subpage is unlikely to break the archive size guideline. Generally meant only for extremely busy pages. Do not archive pages manually, unless this is necessary because bot errors somehow prevent the pages from being archived. User talk: pages are exempt. Single discussions split into their own pages due to size considerations are exempt from internal archiving but have to be searchable through archives of the page they were split from.	We have well-tested archiving tools/subpage creation tools that automate the process. This wording will eliminate bickering over archiving preferences, which is pretty lame and a waste of editor resources. Set up an archive once and forget about it. There are pages that remove discussions instead of deleting them, e.g. WP:ERRORS, which could benefit from the log-based scheme. Pages that remove discussions are already in violation of the rule that discussions should be archived, not blanked; this rule will make sure that the transition must take place.
		All pages intended for user communication should not exceed 1200 KB HTML weight. Archives of these pages should not exceed 900 KB HTML weight. Existing archives are grandfathered. This rule should not be interpreted as discouraging new or existing discussions in any way.	A recent RfC about talk page guidelines scrapped the 75 KB wikitext size limit on non-user talk pages as it had no consensus and practically was not followed anyway. I do not read the discussion as finding consensus against any sort of talk page size limit and the closer specifically encouraged a user talk-dedicated discussion. I don't see the functional difference between the two, that's why this proposal concerns all such pages. The point is to make sure that pages are responsive upon reading and editing. HTML size is not a perfect proxy for measuring this but much better than wikitext. Page weight matters a lot, so some value needs to be set. A median desktop page weighs about 800-900 KB HTML+CSS+JS these days. We can't measure the impact of JavaScript directly on the CPU/browser, but there are Inspect tools integrated in the (desktop) browser. For example, ANI (2062 KB HTML as I write) has an OK value for Largest Contentful Paint (1.86 s) and good Interaction to Next Paint time (40 ms), but not very good values for Cumulative Layout Shift (0.1 s). When I try to edit it in source, however, the latter two values grow to pretty horrible 1,256 ms and 1.02 s; typing text sends INP value - which is basically lag - to an asinine 4,432 ms (syntax highlight on; Chromium 143). The page visibly struggles. Larger talk pages may freeze or crash browsers, or make them effectively uneditable, which is an absolutely unacceptable outcome. The point is to make sure that the value is set reasonably high to allow wide discretion to manage talk pages but not too high to make compliant pages struggle on devices that are not top-shelf. Compliant pages should give users at most mild inconvenience in reading and editing, given any reasonable device and Internet configuration. Any threshold value is arbitrary but the value appears to be a good compromise. (second and later paragraphs based off performance and the page weight chapters of the HTTP Archive Almanac. See the performance page for good reference values of Inspect parameters I mentioned) Lazy loading and render engine improvements depend on WMF/MediaWiki. While their performance improvements are welcome, there is absolutely no guarantee that they will do it, and there is no deadline for them. This proposal is something we as users can do right now. Some users claimed that we should not do it because other websites become heavier over time, which they do, so the value will become obsolete as old hardware is inevitably replaced with better hardware. For one thing, if other websites create pages that consume tons of resources, they are free to do so, but it doesn't mean we should do the same or force people with devices that have poorer performance to make them suffer through loading. For another, consensus can change and we can edit the value later. Almost 1000 user talk pages exceed 400 KB wikitext weight. There are a couple of pretty bad talk pages, too. See also WP:CHOKING and Wikipedia:Vandalism#Illegitimate_page_lengthening. Articles have guidance on size.
		Footnote: As a rough estimate, 1 KB of wikitext weight (the one you see in the page history) is about 5-6 KB HTML weight (source: my observations using PROSESIZE on a couple dozen pages). The more templates, formatting, and user JavaScript and CSS there is on the page, the more HTML weight there will be per 1 KB wikitext weight. Archiving bots assume that 1 KB of wikitext is 6 KB of HTML for the purpose of this guideline. Although the limit is in HTML size, not wikitext, this ratio will allow most discussion pages to stay well within the maximum allowed value. HTML size does not account for the weight of loaded images. If the page is image-heavy, consider lowering the maximum page size limit. To measure HTML weight of a given page, you can use tools such as WP:PROSESIZE. On desktop, there is also an option to open "View page source" and copy-paste the code into a text counter to see the number of bytes.
	None	The archive interval value must balance the need to keep the talk page within a reasonable length with giving adequate notice to all potential participants to engage in the discussion. Only finished discussions may be archived; if possible, the only discussions that go to archive should be clearly stale (=1 year since last comment). If in doubt, apply a longer archive interval. In particular, pages with very high traffic are allowed to exceed the limit to some degree if necessary to give adequate notice to potentially interested users, or to show a recent discussion of large impact. If the page intended for user communication is likely to routinely exceed the maximum size limit, and if the log system is not used, the archiving interval (=time since the last comment in the thread) of an archiving bot must be set at at most 10 days. This, or lower, value, should be only set for high-traffic pages.	The first part is pretty self-explanatory. The second part is designed to a) force high-traffic pages to adopt relatively aggressive archiving schedule and b) effectively exempt them from the requirement that the page be smaller than 1200 KB HTML. The only consideration for high-traffic pages is whether it's more desirable to keep the page small and friendly to edit/read or to keep threads for slightly longer to encourage more discussion. Generally more discussion is more desirable, but on pages like ANI, where threads are often closed in a matter of hours, this may actually be not necessary.
	Apart from the exception described in WP:TALK#User talk pages, discussions should be archived, not blanked.	Discussions on all pages, except for user talk pages, should be archived, not blanked. Any user may choose to blank most messages on their own talk pages, but archiving is recommended instead. There are messages that the user must not remove. If a user removes a message from the talk page, whether by themselves or assisted by automation, this will mean that the user has read and is aware of its contents. Insisting on keeping the message that the user may delete against the user's wishes is not appropriate.	As mentioned above, pages like WP:ERRORS violate this guideline by not keeping any archives.
WP:BLANKING	Policy does not prohibit users, whether registered or unregistered, from removing comments from their own talk pages, although archiving is preferred. If a user removes material from their talk page, it is normally taken to mean that the user has read and is aware of its contents; this is true whether the removal was manual or automatic. There is no need to keep them on display, and usually users should not be forced to do so. It is often best to simply let the matter rest if the issues stop.		Basically a slightly refactored restatement of these two rules, with emphasis on user autonomy on user talk pages.
WP:TALKSIZE	If a thread has been archived prematurely, such as when it is still relevant to current work or was not concluded, unarchive it by copying it back to the talk page from the archive, and deleting it from the archive.	Add this before the red passage: Archive bots must not archive threads on pages intended for user communication if: there are 10 threads or fewer on the main talk page the last comment in a given thread is 10 days old or younger, unless the archiving interval was set at a lower value	This is to address user complaints in the linked Talk page guideline thread above, as confirmed on VPI, that empty pages discourage discussion. I agree. Hence the first requirement. The second requirement is to prevent (potentially) active discussions from being archived. As mentioned above, manual archiving of talk pages is discouraged. But on the off-chance that the thread still is relevant even if archived by bot, the instruction is kept.
WP:USERSUBPAGE	While you do not "own" them, by custom you may manage [user space pages] as you wish, so long as you do so reasonably and within these guidelines.	While you do not "own" pages in User: namespace, by custom you may manage these pages as you wish. Your requests not to edit your User: namespace will be honoured. However, your style of userspace management must be within reason and not lead to breaking these guidelines.	This is to separate User: from User talk: namespaces. Nothing changes in the User: namespace, and generally editors will still have free rein in their user namespace.
WP:USERTALKSTOP	If an editor asks you not to edit their user pages, such requests should, within reason, be respected. However, editors should not make such requests lightly, especially concerning their talk pages, as doing so can impede the ordinary communication which is important for the improvement and smooth running of the project.
WP:OWNTALK	The length of user talk pages, and the need for archiving, is left up to each editor's own discretion.	A user can generally manage their User talk: namespace pages as they see fit, so long as they keep the management within the talk and user page guidelines, including those on maximum size limits.	All discussion pages have to be reasonably accessible, both for reading and for editing, under all reasonable configurations allowed by MediaWiki software. There is no legitimate reason for distinguishing non- User talk: discussion pages from those in this namespace. Users will still be able to manage User talk: pages as they like, but they will have to clear clutter from time to time. It doesn't matter how they do it so long as they do it.
	None	Any user or bot may notify you about your excessive user talk page size that violates the guidelines, and ask you to fix this issue. If you: refuse agree to do it but fail to bring the talk page within compliance within 10 days have a history of notifications that shows that you are unable to maintain compliance with the maximum size long-term an administrator may unilaterally impose an archive bot using the loosest limits necessary to maintain the minimum user talk page accessibility criteria long-term, or correct values to more aggressive archiving if the archive bot was deployed but the size of the talk page is still too large. For people who use archiving by periods of time rather than numbers, a period can be chosen that is likely to stay within these limits, but no longer than 365 days. The archive bot must not be removed without agreement from the administrator who imposed it. The administrator must notify the user of the intervention. Non-administrators may request this intervention at the incidents section of administrative noticeboard. Such requests must be granted if any of the above points apply.	This is the mechanism to enforce size restrictions on user talk pages if the clutter is not cleared. The mechanism respects user's autonomy to decide how to manage their talk page but steps in if it is clear that the user can't or doesn't want to comply. If a user doesn't know how to set up an archive, they can always ask for help. Again, it doesn't matter how they choose to clean up the page to a minimum standard so long as they actually do the clean up. I'm not saying "make it super tidy" but more like "make it not look a total mess". If users feel particular attachment to the collections of their discussions that they ABSOLUTELY NEED on one page, they can create a subpage in the User: space for themselves and advertise it with big-ass fonts. They can also have discussions they are fond of on their talk page so long as they keep the overall size in check. The requirement for administrators to intervene is to make sure the heightened accountability standards apply, even if such intervention does not involve administrative tools. Note that having a big talk page is NOT in itself misconduct. No blocks, no warnings intended, unless there's some real shenanigans going on or the refusal is so stubborn it has a real impact on the community.
Archive tool parameters	Upper archive size limit: 512 KB (wikitext)	Upper page size limit: 200 KB (wikitext) Upper archive size limit: 150 KB (wikitext) Minimum thread count: 10 (outside user talk pages) Maximum archiving interval: 365 days (1 year), but not until the minimal thread count is exceeded.	If the parameter is unspecified, or if any value outside the permitted range is put in the parameters, the values will default to the threshold values.

• Yes to all as proposer. Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)[reply]
• Oppose all, mega oppose c, turbo oppose d and g, turbo mega oppose f. Automatic archiving of talk pages, astonishingly frequently, preserves any vandalism or disruptive edits of talk pages in the archives. We should not make it mandatory and we definitely should not mandate giving people even less time to check for vandalism until the bot strikes (that window is already as short as one or two days, in some cases). We absolutely should not make it the job of users to enforce accessibility considerations, that is the job of the actual paid frontend employees. Gnomingstuff (talk) 15:25, 29 January 2026 (UTC)[reply]

  also, I assume a) is meant to be "maximum number of 10 topics" because otherwise that makes most talk pages non-compliant. But I still oppose it either way, because setting a topic maximum codifies the loophole of spamming a talk page with many new topics to force the archive bot to trigger and disrupt the discussion. Gnomingstuff (talk) 15:28, 29 January 2026 (UTC)[reply]

  No, it's actually minimum. Most threads are not that long. If that the threads are so huge as to spill over the maximum limit, which doesn't happen that often (average >20 KB wikitext or even more), then this setting will be overridden.

  re: spamming a talk page with many new topics to force the archive bot to trigger and disrupt the discussion. -> impossible under this proposal, because archiving will be disallowed if the last comment in a given thread is 10 days old or younger, unless the archiving interval was set at a lower value. And that's a hard one. Szmenderowiecki (talk · contribs) 16:03, 29 January 2026 (UTC)[reply]

• Support all except point a - there should be flexibility on this point. 10 would be innappropriate for infrequently accessed talk pages, and 3 or 5 is perfectly adequate for encouraging discussion. Danners430 _{tweaks made} 15:29, 29 January 2026 (UTC)[reply]
• Skeptical of hard rules - If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? Do they have to fiddle with archiving something (perhaps even an active conversation) before they can tell everyone that Willy on Wheels is deleting the main page again?
  I'm fine with a smarter archive bot that can dynamically change how aggressively it runs based on page size. That seems worthwhile to me. Is forced archiving of user talk something that affects more than a few dozen editors? Is there a systemic problem here? However, if we happen to have 2 big, active important discussions on a noticeboard at the same time, I think accessibility is the sacrifice we make for keeping those discussions intact and in the expected place.
  It also might be worth exploring a finer grained structure for some noticeboards - Wikipedia:Administrator's Noticeboard/Quick Requests for things that don't need huge input is one wild guess I had that might work. Tazerdadog (talk) 15:38, 29 January 2026 (UTC)[reply]

  If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? -> ABSOLUTELY NOT. The question is why the page hits the ceiling. If the reason is that the page has very high traffic, but the bot is set at 10 days archiving interval or shorter, then deviations will be tolerated for the sake of keeping discussions, although huge discussions probably should be spun out in their own pages (see table). If the page hits the ceiling because the parameters are too loose and there's suddenly high traffic, they have to be set at 10 days. The page should not generally hit the ceiling despite low traffic, unless it's a userpage, where archiving will not be obligatory, in which case the enforcement kicks in. These archiving enforcement restrictions are absolutely not supposed to discourage or ban discussion.

  I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding. Szmenderowiecki (talk · contribs) 16:13, 29 January 2026 (UTC)[reply]

  This is probably worth exploring after this discussion is closed. At the grave risk of saying this about anything technical, it doesn't look like it'd be that hard to implement a minimum viable product of dynamic archiving. Tazerdadog (talk) 01:57, 30 January 2026 (UTC)[reply]

• Skeptical of hard rules I can understand the premise, but I am not convinced that we want a one-sized fits all solution. Fundamentally, I think there should be ways to "sticky" some threads on a talk page and there is a smarter way to search archives. --Enos733 (talk) 16:32, 29 January 2026 (UTC)[reply]

  • I believe Template:Do not archive until might do what you want to do already. Tazerdadog (talk) 02:00, 30 January 2026 (UTC)[reply]

• Oppose: I think this is too inflexible to allow for the deviations mentioned. This (except a maximum page size which should be a requirement unless all sections are ongoing and not close-able) should be a set of recommendations, not enforced rules. That would be very unWikipedia.
  Turbo mega oppose a: I don't really see the purpose of a requirement that so deviates from our current practice. This would be a lot of enforcement for little benefit. I would think just one is enough, and I unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out. Aaron Liu (talk) 16:35, 29 January 2026 (UTC)[reply]

  unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out. This was discussed at the linked idea lab thread of the Village Pump. I got some feedback that the number is too high, and on the other hand, a temp account suggested a maximum of 15 threads/30 for high-traffic areas. This is not the essential part of this RfC, so if the number is 3 or 5, so be it. I don't care that much so long as it's not 0. 1 is probably not good enough. Szmenderowiecki (talk · contribs) 16:42, 29 January 2026 (UTC)[reply]

  Could you elaborate on why 1 is not good enough? Aaron Liu (talk) 17:26, 29 January 2026 (UTC)[reply]

  As I was reviewing discussions, I found some users' concerns that empty pages discourage discussion. One may be pretty empty, particularly if the suggestion is not answered, as it is on most article talk pages. Szmenderowiecki (talk · contribs) 17:30, 29 January 2026 (UTC)[reply]

  I guess I just disagree that one discussion is pretty empty. Aaron Liu (talk) 17:34, 29 January 2026 (UTC)[reply]

• Oppose all - I'm not really convinced there's an issue here that requires fixing, especially "fixing" via enforcement. If a talk page for an article is too large, please feel free to add automatic archiving as you see fit. If a user's talk page is too large, consider opening a discussion with that user, even if their page loads kinda slow when you start that discussion. Per Gnomingstuff's earlier point, if there's actually widespread accessbility issues related to how pages are rendered and presented to users, that would be a UI problem to be fixed by development and not a content problem to be fixed by limiting content. --tony 16:46, 29 January 2026 (UTC)[reply]
• Oppose all also BADRFC which goes against the consensus. RfC statement is not neutral nor brief. Pinging large groups of people wastes valuable volunteer time. Polygnotus (talk) 16:50, 29 January 2026 (UTC)[reply]
• I don't think such restrictive requirements are a good idea, and definitely strongly oppose a. Editors should keep in mind that very large talk pages could be a barrier to communication. For article talk pages simply setup archiving if you come across one with size issues. When it comes to the talk page of that one particular editor active editors maybe there could be an annual AN discussion to encourage them to tidy up their talk page. There are many inactive editors without talking page archiving who receive endless automated messages, leading to a lot of bloat, but that's of very little impact (noone needs to communicate with them, and there is little limit on storing text). -- LCU ActivelyDisinterested «@» °∆t° 16:56, 29 January 2026 (UTC)[reply]
• I firmly support introducing an enforceable talk page size limit. Having a talk page that will load across all editor devices is important for accessibility, and as we have documented elsewhere we have talk pages that are unusable (so contra several colleagues above, there is a concrete problem, albeit one of limited scale). I don't want to get too far into the weeds with respect to specifying limits; a byte-size should be sufficient, because we do not want the enforcement to become a bureaucratic mess. I suspect this RfC has too many specifics to gain consensus, but in the interest of making a closer's life easier I will note I support b & e, oppose a and am largely agnostic as to the rest. Vanamonde93 (talk) 16:58, 29 January 2026 (UTC)[reply]
• Oppose almost all, the one possible support is b (maximum byte size for pages, a reasonable technical limitation) but that should probably be done in a separate RFC on just that topic, and be a "soft" maximum anyway. Everything else is a bad idea that creates layers of bureaucracy and bad feeling over nothing important. SnowFire (talk) 16:59, 29 January 2026 (UTC)[reply]
• Oppose all, including B because you can have a single discussion going over that limit. Just check ANI for easy samples. --SarekOfVulcan (talk) 17:04, 29 January 2026 (UTC)[reply]
• Oppose The OP claims that We have well-tested archiving tools/subpage creation tools that automate the process. This is not my experience. I've been editing Wikipedia for nigh on 20 years and I've not gotten on with any of the assorted archive tools which I've tried. And the archive pages for subprojects like ITN are among the worst offenders in my experience -- bloated and broken due to the template limit. What's needed is for the WMF to address the technical issues as that's their job. Wild development and draconian diktats are unlikely to be helpful. Andrew🐉(talk) 17:05, 29 January 2026 (UTC) (edit conflict)[reply]
• Oppose. This is a disproportionate response to the basic issue of Eeng's ludicrous talk page.—S Marshall T/C 17:07, 29 January 2026 (UTC)[reply]

  Also, snow closes exist.—S Marshall T/C 17:09, 29 January 2026 (UTC)[reply]

• This is not well-thought-out at all. It contradicts existing practice for the majority of cases, and some of the provisions (particularly a and b) are mutually exclusive. —Cryptic 17:15, 29 January 2026 (UTC)[reply]
• Essay Make an essay. Create the case there, supported by common sense, guideline and policy. Create a CAPLETTER link. Start linking it. If it catches on, within a couple years, you or someone else will promote it to guideline. This is the way to do it. These all-or-nothing hail mary proposals on VPP are lazy and usually don't work. You got to build something if you want to make change. -- GreenC 18:02, 29 January 2026 (UTC)[reply]
• Oppose oppose oppose.
  Oppose RfC structure. The letters a-g don't match the rows in the table. My head hurts, and since this should be headed for SNOW close I won't renumber. Capital letters below talk to the table, not the lower-case list.
  Oppose A. Not mandating archiving of user talk (i.e. just deleting old stuff is fine) is valuable and should be kept. Archiving parameters (including "no archiving") is a personal preference. While the justification of the RfC is making user talk accessible, the proposal fails to explain why such harsh measures must be taken.
  Oppose B. No need for a specified number. Just force EEng to archive, and you've solved all problems :)
  Oppose C. Different talk pages require different archiving intervals. Archiving every 10 days is insane for regular user talk pages.
  Oppose D. Start a new separate discussion (without the infected atmosphere of this one). Opposing mostly because bundling this together with everything else is really ill-advised.
  Oppose E. The suggestions makes it clear the proposer don't know how people use archiving bots. The only sane minimum number of threads to keep is 4. 10 is way too many.
  Oppose F. For the same reason as D - start a separate discussion.
  Oppose G. Just hell no.
  Oppose H. For the same reason as D - start a discussion separate from everything else.
  In closing, the proposer really needs to study how to create constructive RfCs because this ain't how you do it. CapnZapp (talk) 18:22, 29 January 2026 (UTC)[reply]
• Yes to all I believe this is sorely needed for accessibility reasons, though I'm sure it will be opposed by people as too restrictive. ᴢxᴄᴠʙɴᴍ (ᴛ) 19:38, 29 January 2026 (UTC)[reply]
• Oppose as written This goes too far and is too strict (and "a" is just a bad idea). I'd support stronger recommendations around archiving than we have now after Wikipedia talk:Talk page guidelines#RFC: Recommended maximum talk page size, but strict limits aren't going to work well and mandating bots archive every talk page would probably work even less well. Good luck figuring out what those recommendations should be though, since it seems the people who really care are mostly the ones who like having ridiculously huge user talk pages and they're happy to derail straightforward heuristics into demanding any rule be based on "page weight" and so on. Anomie⚔ 19:56, 29 January 2026 (UTC)[reply]
• Oppose all. This entire proposal is a complete waste of time. There's no reason whatsoever why we should enforce a hard limit on talk page sizes. This has to be one of the most poorly thought out RFCs I've ever seen, let alone participated in. Sugar Tax (talk) 20:11, 29 January 2026 (UTC)[reply]
• Strong oppose all - A is a terrible idea. That will add to clutter, not reduce it. It will make pages less accessible, not more. B is also a terrible idea. This has been explained many times: how long it takes for a page to load is not based on how many kB the page is in size. Because A and B are bad ideas, the rest of the proposals, which seek to enforce A and B, are also bad ideas. And really, the last thing this website needs is more r00lz. There are like a million f'ing rules on this website because it's 25 years of people being like, "I don't like this, let's make a rule to prevent it!" Look, you want to make every page on Wikipedia load reasonably quickly, there is one way, and really only one way, to go about it: you pick your website performance tool, and you say "must load within 5 seconds (or whatever amount of time) on any browser less than 10 years old (or whatever amount of time), as measured by X tool (or the average of multiple tools, take your pick)." You don't regulate the damn kB or the number of minimum threads if you want a page to load quickly, because that doesn't solve the problem. Levivich (talk) 20:31, 29 January 2026 (UTC)[reply]
• Oppose all and suggest WP:SNOW close:
  I have a fair amount of experience with limited hardware and ancient software. As I look around my lab I see that my CP/M machine (actual Z80 hardware, none of this emulation rubbish) from 1983 is still working fine and used daily for text editing and my daily driver is a ThinkPad T580 from 2018. The limits proposed in this RfC are far too small. Anyone who has trouble reading a page twice the size of these limits is already used to having trouble reading half of the web.
  I would be inclined to support a policy against exceeding the limits found in https://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize and https://www.mediawiki.org/wiki/Manual:$wgAPIMaxResultSize --Guy Macon (talk) 20:47, 29 January 2026 (UTC)[reply]
• Oppose all. In particular:

  a) oppose minthreads=10. If you have sufficient experience with Talk pages you know that sometimes an individual thread can run long, including longer than 200kb on occasion, so this would contradict one of your other proposal terms.

  b) oppose max pagesize=200 and max archive=150. This has been very recently debated, and it is inadvisable to raise this again so soon, even if subsumed as part of a longer proposal.

  c) oppose mandated archiving: better clarify what you mean by mandated. We mandate very little at Wikipedia, other than WP:LIBEL, WP:COPYRIGHT, some trust & safety considerations, and a short list of other policies with legal implications.

  d) oppose required short archiving delay in some cases, per WP:CREEP and WP:BURO. You do not trust administrators at WP:ANI to know enough how to do the right thing? I can conceive of no case where having a rule about this will do anything other than provoke unnecessary strife.

  e) oppose limitation on user freedom to choose their own talk page size. Is this about EEng's talk page? If so, then it is none of your fucking business. Don't bring proposals to VPP aimed at particular users; solve it in discussion with them, or at WP:AN if you must. If not about their (or some individual's) talk page, then please ignore the previous statement with my apologies; in that case I oppose per WP:OWNTALK and WP:CREEP.

  f) oppose oppose oppose UTP max size enforcement. See e), and WP:OWNTALK, WP:CREEP, and WP:BURO. Personally, I would consider invoking WP:IAR to reverse enforcement at random other UTPs under this rule to see how strong the community support for this disastrous provision really was, assuming it were ever adopted, which I strongly doubt.

  g) oppose enforced bot maxsize validation. I see a lot of terms like mandate, enforcement, limit, require, comply, and force in your proposal. You see to be in battle dress here, getting ready for the mother of all archiving wars. Where are all the terms like generally, should, typically, suggested, consider, and other terms that are often used in Wikipedia policies and guidelines to indicate something less than a hanging offense? Your usage smacks of my way or the highway, and does not conform to general usage at Wikipedia, in my opinion.

• Thanks, Mathglot (talk) 21:06, 29 January 2026 (UTC)[reply]

In re "e)", if there's something about someone's User_talk: page that makes it difficult for other editors to communicate with them, then it is other editors' business. WhatamIdoing (talk) 22:07, 29 January 2026 (UTC)[reply]

Not necessarily. If you have trouble accessing a webpage, it's not necessarily the problem of the webmaster to fix it, it might just be that you're using obsolete technology. It's not tolerable or practical to expect us to have every single web page work great for every single user no matter how obsolete (or laden with plug-ins, scripts, etc.) their client is. We should require ourselves to meet industry-wide web standards, not the standards of every random person on the internet. Levivich (talk) 22:12, 29 January 2026 (UTC)[reply]

If you're required to post an ANI notice, and you can't because the editor has a million-byte-long User_talk: page, then we have a problem. "Hey, stop being a jerk and archive your talk page" is something we can do. "Dude, stop being poor and buy a new computer if you want to report someone to ANI" is not something we can do. WhatamIdoing (talk) 22:54, 29 January 2026 (UTC)[reply]

Not necessarily. If 1,000 people have no problem posting the ANI notice, but one person does have a problem because they have too many plug-ins or scripts installed, or they're simultaneously downloading many files, or they're just using a 30-year-old machine, then "we" do not have a problem, just that one person has a problem, and "fix or update your client" is something we can say. Again: we should comply with industry-wide web standards, not with the needs of every single person out there. Levivich (talk) 22:59, 29 January 2026 (UTC)[reply]

This is not the case I'm asking about. Nobody is saying that we accommodate Nokia 3310 users. Szmenderowiecki (talk · contribs) 23:04, 29 January 2026 (UTC)[reply]

Re: recommendations vs mandates, recommendations are basically unenforceable with enough determination from the user who does not want to follow recommendations. We already have a recommendation saying that Large talk pages are difficult to read and load slowly over slow connections and User talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier. - Hint: make pages accessible enough to make collaboration easier. Does this recommendation work? No.
There is a reason government pages require basic accessibility support, with reference to WCAG guidelines. There is no reason we cannot require this on our side. Szmenderowiecki (talk · contribs) 23:10, 29 January 2026 (UTC)[reply]

And how exactly is this the job or responsibility of unpaid volunteers, as opposed to the engineers who are actually paid to make websites accessible and improve rendering time? Gnomingstuff (talk) 23:47, 29 January 2026 (UTC)[reply]

And how exactly is this the job or responsibility of unpaid volunteers, as opposed to the engineers who are actually paid to make websites accessible and improve rendering time? Why as opposed to? Por qué no los dos? Also, volunteers don't have to do anything at all, and yet they do.
Your attitude just kicks the can down the road. And I don't have to remind you that WMF has had quite a few fumbles about their coding. In this thread, just look at the 03:31, 30 January 2026 (UTC) comment. Szmenderowiecki (talk · contribs) 11:31, 30 January 2026 (UTC)[reply]

if you're proposing sanctions then it does make it compulsory, at least if one wants to participate Gnomingstuff (talk) 18:25, 30 January 2026 (UTC)[reply]

Does this recommendation work? Yes.

The subject of archiving comes up nowhere in the W3C acessibility guidelines.

You just gave the reason yourself why this Rfc was unnecessary and a gigantic waste of time; quote:

We already have a recommendation [about] [l]arge talk pages...

Details in the discussion below. Mathglot (talk) 02:58, 30 January 2026 (UTC)[reply]

Bad performance impacts accessibility and user experience. State of California, University of St Andrews. I thought this was obvious.
The long pages talk report would at most have a few entries above let's say, a cutoff of 250 KB. It not the case. So no, the recommendation doesn't work. Szmenderowiecki (talk · contribs) 11:19, 30 January 2026 (UTC)[reply]

I have never seen anyone get any actual negative action against them if they fail to post on a user's talk page for an ANI report. Many editors are eager (perhaps overly so) to notice omissions and correct them. To avoid this argument (and I think it's actually generally a good change) perhaps we should amend the ANI rules to say that if you cannot reasonably, for any reason, post on a user's talk page, mention that in your initial report (or immediate reply). Skynxnex (talk) 00:54, 30 January 2026 (UTC)[reply]

More generally, even when specific forms of communication are not required, we expect editors to be able to communicate with each other. That includes making it reasonably possible for newbies to be able to leave a message on any page that is used for discussion.

ANI itself frequently breaks that limit; a handful of editors' User_talk: pages do as well. For example, I remember when DGG's talk page regularly ran >800K long (example) and sometimes exceeded a million bytes. That revision took about 10 seconds just now to load on a modern computer with a decent internet connection and all scripts/gadgets disabled via mw:safemode. @Levivich mentions industry-wide standards, which I believe are that pages should generally load within three to four seconds (because that's when users start giving up). Now imagine that it's not loading on my MacBook, but on a smartphone. Good luck loading the page. Extra good luck being able to edit it, or even to scroll to the end.

You and I could think up half a dozen ways to cope with this, but a newcomer can't, and nobody should have to. WhatamIdoing (talk) 05:22, 30 January 2026 (UTC)[reply]

That old revision took about 8 seconds to load load on my modern phone over 5G. Most of the time was spent, I am pretty sure, by the server itself having to freshly fetch and render the page since it was probably uncashed for me. I think one circle I'm trying to square is that none of this should be be any editor's job. It shouldn't be a bot's job. There shouldn't be rules and potential punishments if you do it wrong. The MediaWiki itself should just allow editors to pick how many sections they see per talk page. Abd the rest are the archives. But of course the long history of talk pages just being a page makes that hard. But that sort of change is less disruptive than more rules. Skynxnex (talk) 05:40, 30 January 2026 (UTC)[reply]

What do you think the loading time would be if you were using a low-end phone (e.g., a JioPhone) on a pay-per-use data plan? I think it's safe to assume that the answer is "worse", and yours was already twice the industry standard. Did you try to scroll to the end of the page?

The problem with changing talk pages (remember Wikipedia:Flow?) is that the change would have hurt one group of people and benefited a different group of people. So naturally the first group complains that it's all harm and no benefit (to them), and the beneficiaries are already have difficulty with joining conversations, so they have much less ability to make their view heard. I don't think that reality will change this decade. We will probably have to wait until the small minority of editors who primarily use mobile devices become a more vocal part of the Wikimedia communities. In the meantime, what's happening is that mobile-heavy communities are finding off-wiki places for discussion and coordination (e.g., Whatsapp or Discord). WhatamIdoing (talk) 18:50, 31 January 2026 (UTC)[reply]

• I support a limit on the size of user talk pages, but not on noticeboards, which are generally archived automatically and have not proved an issue in the past. However, I also think the horrendous formatting of this RfC has killed any chance of us getting a productive outcome here. Proposing seven different changes at once, some of which put the cart waaay before the horse (enforcement mechanism for a guideline that has yet to exist??) was a bad idea. Toadspike [Talk] 21:34, 29 January 2026 (UTC)[reply]
• Oppose all - I am yet to be convinced that there is a real problem with talk pages - annoyances yes, problem no. Nor do I think that any of the proposals would be an appropriate way to deal with the annoyances. When there is an issue with a talk page, our current rules (and lack thereof) give us FLEXIBILITY to deal with them as we think best fits the specific situation. This all seems to CREAPY to me… boxing us in unnecessarily. Blueboar (talk) 21:46, 29 January 2026 (UTC)[reply]
• Oppose as misguided and repetitious. As I already said in December, If archiving a thread is controversial, it very likely should not happen. If it's not controversial, there's no reason to wait until the page reaches some arbitrary size. The fact I am quoting myself from another RFC on this same topic barely a month ago suggests this RFC is problematic. —Rutebega (talk) 23:00, 29 January 2026 (UTC)[reply]
• Oppose all, as strongly as possible. Good grief, not this nonsense again! The idea of making this kind of stuff enforceable is downright offensive. --Tryptofish (talk) 00:14, 30 January 2026 (UTC)[reply]
• support b, good compromise between a maximum size and accessibility. ltbdl (love) 00:49, 30 January 2026 (UTC)[reply]
• Oppose as written This is a bit too much to do in one RfC. Would suggest rescoping this RfC to be targeted to user talk pages only (I'd assume that's why you wanted to make this RfC right?). In addition, outside of the user talk space, if the talk page is too big, no one is going to complain if you archive some stale topics so no hard guideline is needed. Workshop something that's basically "you have a problem if the average user can't discuss conduct issues on your user talk page" and I think that would be sufficient. Jumpytoo Talk 01:54, 30 January 2026 (UTC)[reply]
• Support a maximum size, absolutely. I have a reasonably good computer, and it still takes an absurd amount of time for some user talk pages to load. This is a collaborative project, where accepting communications is necessary, and should not be hobbled by an inordinate pride in an absurd talk page size. BD2412 T 04:52, 30 January 2026 (UTC)[reply]
• Oppose all: WP:OWNTALK, "Oppose the creation of this unnecessary and complicated rule for a very uncommon situation that could just as easily be solved by editors using their best judgment..., and WP:BURO -- Otr500 (talk) 05:14, 30 January 2026 (UTC)[reply]
• Strong support some kind of stronger enforcement for accessibility, including a maximum size for user talk pages. I don't know why editors think the layout of their talk pages is so important that they can impede accessibility for others. Wikipedia is not a forum and talk pages exist so editors can communicate with each other, not so they can be fancily decorated or have years old discussions visible at first glance. There is a good reason we have a WP:SIZERULE for articles, and there is even less of a reason to not impose a strict limit on the size of user talk pages than for articles. While WP:CREEP can be a valid concern, it does not apply here, at least without meaningful justification as to why a user talk page might need to be that large.
  I don't have strong opinions on many of these particular proposals other than I generally echo the sentiment from others (particularly Toadspike) that this is far too specific/narrow a proposal to work. For the closer, you might interpret this as support b, e and f, oppose a and no opinion on the rest. Katzrockso (talk) 13:45, 30 January 2026 (UTC)[reply]
• No. With all due respect, this feels like a case of wasting the community's time to resolve a petty issue of minimal consequence. I struggle to believe that even goofy talk pages like User talk:EEng present a real accessibility problem. How frequently does someone need to contact those specific editors so urgently that they can't wait a few seconds for the page to load, or wait until they are on a more reasonable browsing setup? Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds. -- LWG ^{talk (VOPOV)} 19:34, 30 January 2026 (UTC)[reply]
• Oppose - None of these seem worth doing. Too many edge cases, too much bureaucracy when it's only very rarely a problem. On-wiki page sizes are tricky measures to use, because the size of the wikitext is not the same as the size of a page in a browser, with all the images and templates and whatnot. And there are some talk pages that really do need to be longer than others. So this all seems like for circumstances when both of these are true: (a) multiple people have difficulty using a talk page and ask for something to be done about it (or tries to do something about it), and (b) someone ignores the complaints and/or reverses efforts to fix the issue. The latter is very rare, and only ever an issue in userspace, where we tend to frown on other users jumping in to archive. Really, I can only think of one case where both of the above have been true on a usertalk page. I do not know why that person digs their heels in, or why several people reliably show up to insist it's cool, but them's the breaks with norm-breaking and social capital on wikipedia (and, let's face it, most places). In other words, if anything it's a one-off for an administrators' noticeboard, no ta new policy; and I'd also recommend against that noticeboard trip as pointless. As I wrote below, a new entry in perennial proposals would be justified at this point. — Rhododendrites ^talk \\ 00:53, 1 February 2026 (UTC)[reply]
• UM WHAT? All pages with discussions limited to 10 topics? So how do you suggest Wikipedia:Administrators'_noticeboard/Incidents, Wikipedia:Village_pump_(technical), Wikipedia:In the news/Candidates, etc get handled @Szmenderowiecki:? — xaosflux ^Talk 00:58, 1 February 2026 (UTC)[reply]

  No, their proposal is to have all pages have a minimum of 10 topics. SuperPianoMan9167 (talk) 00:59, 1 February 2026 (UTC)[reply]

  @Xaosflux: You misread their proposal. They are proposing for all talk pages to have a minimum of ten topics at all times. (Which still doesn't make a whole lot of sense.) SuperPianoMan9167 (talk) 01:01, 1 February 2026 (UTC)[reply]

  I am flexible as to the minimum number, so long as it's not 0 Szmenderowiecki (talk · contribs) 01:11, 1 February 2026 (UTC)[reply]

  Why not zero? If all the discussions on my user talk page are a year old and refer to something long since resolved, who are you to tell me that I can't archive all of them? --Guy Macon (talk) 01:41, 1 February 2026 (UTC)[reply]

  Establish a minimum number of 10 threads on pages, except on user talk pages. So I think we are talking about article talkpages. But often article talkpages contain only stale stuff that has been dealt with years ago and is no longer relevant. Polygnotus (talk) 01:53, 1 February 2026 (UTC)[reply]

  I can see the value in the default being a non-zero value for article talk pages automatically archived by a bot, which cannot tell whether the stale stuff is still relevant. That also gives an approximate indication of how active the talk page is (if I ask a question there is it likely to be seen or should I hunt down a WikiProject?) but if editors at a particular talk page think a non-default value (including zero) is appropriate there then that should be allowed imo. Thryduulf (talk) 02:01, 1 February 2026 (UTC)[reply]

  OK thanks, I think this proposal is confusingly worded. Certainly we wouldn't require pages to have 10 discussions on them, it seem that that is supposed that 10 part is supposed to only be about a parameter for this mysterious archiving solution - and not actually a minimum number of topics required on a talk page (i.e. a talk page can't even be CREATED unless you start 10 or more discussions at once). — xaosflux ^Talk 01:32, 1 February 2026 (UTC)[reply]

  I think this is intended to relate to the number of threads left on a page by archiving bots. For example Wikipedia talk:WikiProject UK Railways archiving configuration has the parameter minthreadsleft = 5 so old threads (in this case defined as 30 days since the last activity) will not be archived if it would result in fewer than 5 threads being left on the page. I'm at a loss as to why this is something that needs to be a guideline, let alone anything stronger. Thryduulf (talk) 01:50, 1 February 2026 (UTC)[reply]

  Some people think a talk page with some discussions on it, even if they're really old, is more inviting for newbies. Possibly the proposer here is one of them. Or maybe the idea was just to avoid "unnecessary" archiving on very inactive pages since the proposal calls for automatic archiving of all talk pages. Anomie⚔ 02:01, 1 February 2026 (UTC)[reply]

  That's the impression I got from reading the TPG discussion, where two issues were raised: disputes over manual archiving and empty talk pages that may result out of that. It was a minor thread in the discussion, but the people who did address it were largely opposed to both. Hence the proposal. Szmenderowiecki (talk · contribs) 09:06, 1 February 2026 (UTC)[reply]

  Regarding 0 threads: there appear to be more than 1.9 million user talk pages with no discussions on them. No doubt many are inactive, but not all; what happens to them if this passes? Mathglot (talk) 06:44, 1 February 2026 (UTC)[reply]

  Nothing, because this proposal discourages manual interference with the archives unless it is due to bot error. Szmenderowiecki (talk · contribs) 09:04, 1 February 2026 (UTC)[reply]

• The easiest solution is an addition that anyone can archive any inactive threads on any talk page, and reverting these archivals is disruptive. sapphaline (talk) 10:10, 1 February 2026 (UTC)[reply]

  See "Proposal #2" section below. sapphaline (talk) 10:23, 1 February 2026 (UTC)[reply]

• Oppose absurd talk-page bureaucracy. —David Eppstein (talk) 18:34, 2 February 2026 (UTC)[reply]
• Strongly oppose preposterous proposal for draconian, misguided, additional rules. I'll admit it: you lost me at your very first point, Establish a minimum number of 10 threads on pages. You mean you demand that we add up to 9 (or even 10) threads to every talk page on enwiki? No, thanks. I went on, anyway, out of basic respect, but your suggestion that we let the bots from Minority Report crawl over every page and disrupt even appropriate and useful retention of discussion did not entice me. Your hidden table—kudos: you collapsed it!—was impossible for me to make any use of. I did see reasonably accessible but did not make it to the part where you defined "Reasonable". In summary, the specific parts of the proposed changes I do not like are a through g. Thanks for asking, but I can offer no support. — JohnFromPinckney (talk / edits) 23:04, 2 February 2026 (UTC)[reply]

1. EEng is asked to archive his talk page.
2. If, within 7 days, EEng doesn't archive his talk page so it works like a normal talk page, then EEng is topic banned from editing any other page except his talk page. This sanction expires when EEng's talk page works like a normal talk page.

The end.—S Marshall T/C 20:36, 31 January 2026 (UTC)[reply]

Quick question: how does this help us achieve our goal of a world in which every single human being can freely share in the sum of all knowledge? Polygnotus (talk) 21:01, 31 January 2026 (UTC)[reply]

We generate an encyclopaedia collaboratively, and this facilitates collaboration by making sure users can talk to each other.—S Marshall T/C 21:03, 31 January 2026 (UTC)[reply]

I have asked Quiddity to find a WMFer who can dive into the technical stuff; that way we have a solution for all long pages once and for all. Polygnotus (talk) 21:09, 31 January 2026 (UTC)[reply]

I don't want trouble for anyone, man. I don't have a beef against EEng, but his page is a problem and he's not the only one with this problem. It would be unfair to EEng to punish him but not the others in Wikipedia:Database reports/Long pages/User talk (no subpages).
The whole point of my proposal was to avoid any banhammer deployment. Szmenderowiecki (talk · contribs) 21:03, 31 January 2026 (UTC)[reply]

Being unwilling to archive your talk page is a user-level problem and the solution is at user level.—S Marshall T/C 21:20, 31 January 2026 (UTC)[reply]

Counter-Counterproposal:

1. S Marshall is asked to stay on topic, avoid personalizing discussions, and stick to general principles of Wikipedia.
2. If User:S Marshall continues to waste everybody's time by perverting this discussion and turning it into an attack on one editor (and in the wrong venue), then S Marshall shall be required to write one hundred times on a Village Pump subpage (which may be entitled, .../Blackboard, if desired) that "I shall stick to the point and avoid personalizing the issue and being a general dufus at Village Pump." (in cursive)

Corollary: Mathglot to be trouted for failing to take their own advice. Mathglot (talk) 21:14, 31 January 2026 (UTC)[reply]

Bargain-Countertenor Proposal: Everybody here should go and work on some content, and give this a rest. --Tryptofish (talk) 19:48, 1 February 2026 (UTC)[reply]

I think this talk section illustrates vividly how unhelpful the entire idea proposed at the top really is. And frankly, this section (not the whole discussion, just this section) should be closed and hatted as a personal attack. --Tryptofish (talk) 22:00, 31 January 2026 (UTC)[reply]

should have been hatted the moment someone brought donald trump into it, really

seriously guys (Polygnotus excepted for actually doing something productive), what the fuck Gnomingstuff (talk) 02:59, 1 February 2026 (UTC)[reply]

Let's agree that it should have been hatted, because it sure ain't making Wikipedia great again. --Tryptofish (talk) 19:31, 1 February 2026 (UTC)[reply]

But that snipe sure does have a big beautiful bill! --Tryptofish (talk) 19:45, 1 February 2026 (UTC)[reply]

• Has this been retained (not archived) for humor reasoning, a community consensus against one or more editors, or maybe the love of drama and large talk pages? Surely it is not because of a lack of archiving knowledge-- Otr500 (talk) 22:41, 31 January 2026 (UTC)[reply]
• Is it time to just add "force EEng to make his user talk page functional" to the list of perennial proposals? Or an extension of WP:UNBLOCKABLES called "WP:UNARCHIVABLES" or "WP:UNTALKABLES"? Raised by many people many times over many years, but just gets a bunch of "relax, it's no big deal" responses from third parties. After it crashed my browser a couple times some years ago, I'm certainly not going there (not that I've had a need to), and I light a candle for any newbie who tries to leave him a message on mobile. But yeah, I agree with the pile-on above that we're not going to institute hard rules for this. It's one of those fairly-low-stakes-in-the-grand-scheme-of-the-project norms that everybody just kind of does because we want this to be a place where collaboration is easy and we don't make life unnecessarily hard for each other, and which we're realistically only going to enforce if someone lacks social capital. Adding: EEng is not usually the person with the longest page -- we should enforce this evenly or not at all -- but EEng is certainly the page that comes up most frequently. — Rhododendrites ^talk \\ 23:12, 31 January 2026 (UTC)[reply]

  Hard cases make bad law. Polygnotus (talk) 23:37, 31 January 2026 (UTC)[reply]

• I tried to WP:BOLDLY hat this discussion, but of course I'm involved, and S Marshall reverted it. I still think this section is counterproductive. --Tryptofish (talk) 23:32, 31 January 2026 (UTC)[reply]
• It occurs to me that a counterproposal that involves the idea of sanctioning EEng is something that EEng ought to be notified of. (Oh, but his talk page was too long to notify him, I get it! rolls eyes) So I did it: [1]. --Tryptofish (talk) 23:39, 31 January 2026 (UTC)[reply]

  I've been trying to talk to you for about half an hour Tryptofish and got edit conflicted every single time so you get the short version.

  Your claim that this reduces to a personal attack on EEng is wildly mistaken. It's about EEng personally. It's about a problem with EEng's talk page behaviour. But it's not an attack to propose a solution.—S Marshall T/C 23:45, 31 January 2026 (UTC)[reply]

  And, the solution for EEng is not the solution for every editor in the long talk pages category. Some of those talk pages load easily. Some of the editors are indeffed and it's not realistic to expect them to fix it.—S Marshall T/C 23:47, 31 January 2026 (UTC)[reply]

  But, EEng is a user in good standing who's bright enough to see that his talk page is a problem. He's well aware that it needs to be fixed. We've established at the DRV that preceded this mess that other people don't get to archive EEng's talk page for him.—S Marshall T/C 23:49, 31 January 2026 (UTC)[reply]

  Therefore there's only one person who can fix the problem and it's EEng. He knows he needs to do it. He hasn't. So I suggest ways of making him.—S Marshall T/C 23:51, 31 January 2026 (UTC)[reply]

  In a collaborative project you must have a talk page people can work with. If people can't work with your talk page then you're being uncollaborative. It's the Wikipedia equivalent of antisocial behaviour.—S Marshall T/C 23:53, 31 January 2026 (UTC)[reply]

  There isn't only one way to look at this. There's several different ways. One way I like to see it, is that outside of article space, I don't care how long a user talk page is, but it presents technical problems that have yet to be solved. When I comment on a long talk page on my desktop and on my mobile (using desktop view), there is a bit of lag that makes using the reply function impossible. Using the edit section isn't as bad, and adding a new comment entirely tends to work. This shows that there is a problem with MediaWiki, not EEng. How about we fix that first? Viriditas (talk) 00:10, 1 February 2026 (UTC)[reply]

  In a perfect world, MediaWiki would be less ghastly. But we don't control that. We have to work with the software we have, not the software we want. So we need volunteers to have the behaviours that make the software work. EEng doesn't. It's got a lot in common with hoarding: begins with a disinclination to get rid of old rubbish, but over time it evolves into a situation where the neighbours are complaining about the smell and the postman can't force any more mail into the overstuffed letterbox.—S Marshall T/C 09:52, 1 February 2026 (UTC)[reply]

  @S Marshall I think you mean It's not about EEng personally. Polygnotus (talk) 00:11, 1 February 2026 (UTC)[reply]

  I did mean that my proposals are about EEng personally. I didn't misspeak in that respect.—S Marshall T/C 00:13, 1 February 2026 (UTC)[reply]

  Oh, then I misunderstood, sorry. Polygnotus (talk) 01:03, 1 February 2026 (UTC)[reply]

  S Marshall, you and I have both been around this project for a very long time. (Indeed, I remember the verifiability-not-truth debates of a bygone era.) You, like EEng, are a user in good standing who is bright enough to realize that this discussion you have started is only inflaming the issue, and not accomplishing anything productive. If you have accomplished anything at all, it's that you just might have caused more editors to come over to the opinion that is opposite to your own. --Tryptofish (talk) 19:31, 1 February 2026 (UTC)[reply]

Pinging all participants of the deletion review that precipitated the discussion, the idea lab thread and the talk page guideline thread. I have reason to believe that these participants will be likely interested in this discussion. Pings: @Voorts, OwenX, GreenLipstickLesbian, SuperPianoMan9167, Katzrockso, Tryptofish, SmokeyJoe, Bradv, XtraJovial, Jumpytoo, EEng, SportingFlyer, ~2025-43151-08, Sugar Tax, Cryptic, Jclemens, S Marshall, Spartaz, LakesideMiners, Alalch E., Skynxnex, Schazjmd, WhatamIdoing, ActivelyDisinterested, Aaron Liu, Gnomingstuff, Anomie, ~2025-31733-18, Ritchie333, Mathglot, CapnZapp, Rolluik, Zxcvbnm, Locke Cole, Guy Macon, Vanamonde93, Cremastra, Rchard2scout, Polygnotus, JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, and ~2025-35132-06: @JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, ~2025-35132-06Swordman97, Rutebega, SunDawn, Stifle, Toadspike, Andrew Davidson, Alpha3031, Chipmunkdavis, Coining, Otr500, Andrybak, Andrew Gray, and Wbm1058: Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)[reply]

@Szmenderowiecki I didn't receive a ping from this that I can tell. I believe it is because you included more than 50 and possibly since the edit that had these had multiple sections (WP:MENTION). Skynxnex (talk) 16:06, 29 January 2026 (UTC)[reply]

Well then I don't know if it's the case that no one got the ping or it's just random users in the list didn't get it, or maybe those that were at the bottom of the alphabet? I knew that {{ping}} only fits 50 usernames but I didn't know that one comment couldn't have more than 50. Szmenderowiecki (talk · contribs) 16:17, 29 January 2026 (UTC)[reply]

They can contain more than one, but if they do, nobody will receive the ping. FaviFake (talk) 16:27, 29 January 2026 (UTC)[reply]

Please stop pinging large groups of people. Thanks. Polygnotus (talk) 16:29, 29 January 2026 (UTC)[reply]

Why? I appreaciated the ping FaviFake (talk) 16:32, 29 January 2026 (UTC)[reply]

@FaviFake Because pinging large amount of people to bad RfCs is a waste of valuable volunteer time. Polygnotus (talk) 16:34, 29 January 2026 (UTC)[reply]

I agree. However, that's not what Szmenderowiecki has done. This RfC looks fine. FaviFake (talk) 16:36, 29 January 2026 (UTC)[reply]

Resending first batch @Voorts, OwenX, GreenLipstickLesbian, SuperPianoMan9167, Katzrockso, Tryptofish, SmokeyJoe, Bradv, XtraJovial, Jumpytoo, EEng, SportingFlyer, ~2025-43151-08, Sugar Tax, Cryptic, Jclemens, S Marshall, Spartaz, LakesideMiners, Alalch E., Skynxnex, Schazjmd, WhatamIdoing, ActivelyDisinterested, Aaron Liu, Gnomingstuff, Anomie, ~2025-31733-18, Ritchie333, Mathglot, CapnZapp, Rolluik, Zxcvbnm, Locke Cole, Guy Macon, Vanamonde93, Cremastra, Rchard2scout, and Polygnotus: Szmenderowiecki (talk · contribs) 16:20, 29 January 2026 (UTC)[reply]

And second batch @JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, ~2025-35132-06, Swordman97, Rutebega, SunDawn, Stifle, Toadspike, Andrew Davidson, Alpha3031, Chipmunkdavis, Coining, Otr500, Andrybak, Andrew Gray, and Wbm1058: Szmenderowiecki (talk · contribs) 16:20, 29 January 2026 (UTC)[reply]

@Szmenderowiecki This is just a bad RfC which is probably why people don't respond to it. And I don't really see the point. What are you hoping to achieve? We already had this discussion a short while ago. Polygnotus (talk) 16:25, 29 January 2026 (UTC)[reply]

This is just a bad RfC - in what way? I'm looking at WP:RFC and I don't see your point. You can disagree with the premise (which I guess you will based on your prior comments) but it doesn't make it a bad RfC.

We already had this discussion a short while ago. - addressed in the table.

which is probably why people don't respond to it - We are just two hours into the discussion, so how do you know?

What are you hoping to achieve? - minimum accessibility standards that will cause at most moderate performance issues for all users wanting to engage in Wikipedia discussions; also stopping quarrels about archiving preference. Szmenderowiecki (talk · contribs) 16:34, 29 January 2026 (UTC)[reply]

@Szmenderowiecki

This is just a bad RfC in what way? you don't have a clear understanding of the situation so any proposal you make is hindered by that.

We already had this discussion a short while ago addressed in the table. Maybe, but this is still a problem.

which is probably why people don't respond to it We are just two hours into the discussion You are, that is my point, but" we" as an alleged community are not "just two hours into the discussion"

minimum accessibility standards that will cause at most moderate performance issues that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. But starting an RfC and pinging a bunch of people when you haven't really understood the problem, the various factions in the debate and the upsides and downsides of the various options is unlikely to lead to a good result.

I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding. But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help. Polygnotus (talk) 16:41, 29 January 2026 (UTC)[reply]

This might sound a bit too aggressive. Aaron Liu (talk) 17:32, 29 January 2026 (UTC)[reply]

I may or may not have resting bitch face in English. In 2003 Brooke Vibber wrote: There's no theoretical maximum, but our server only has 2 gigs of memory, so don't push it please. ;) In all seriousness though, I very strongly recommend against letting articles grow beyond 32 kilobytes.[2] Server. Singular.

We may need to write a userspace essay explaining how long this topic has been debated for and how complicated it is so that we can stop new users who aren't nerds wasting a bunch of everyone's time. Note also [3] and [4] and [5], this is not the first time. Polygnotus (talk) 19:55, 29 January 2026 (UTC)[reply]

Wow, I missed that before. This whole, huge, indigestible discussion no longer looks like a good-faith effort to improve editor collaboration by making talk pages more generally accessible (a totally defensible goal per se). It now looks to me more like a way to harass an editor in a fit of pique after previous attempts to directly interfere with their chosen archiving one-on-one were rejected and undone by admins, lightly concealed as a broad, improve-accessibility discussion. Only, this time, their fit of pique is not only harassing one user, it is wasting the time of many users. This is completely unacceptable. This isn't ANI, but by raising this discussion, Szmenderowiecki's behavior should be open to scrutiny as well. If there were a proposal on the table to ban Szmenderowiecki from starting a discussion on archiving or pagesize for eighteen months, I would vote to support. Mathglot (talk) 07:16, 1 February 2026 (UTC)[reply]

The first link is irrelevant to this discussion, the second link is the DRV, the third is literally a companion discussion to DRV. I am using all forums for their intended purpose.
Mathglot I started this discussion because it became apparent to me at DRV that there are no good procedures to enforce talk page accessibility, which I believe are needed. This is the only reason I was starting this discussion. I am amazed that some editors dismiss my concerns as fake.
I urge you to strike your accusation of me trying to harass editors. If you insist or want to go the route of banning discussion, go ahead, but that accusation, and that of any other editors suggesting I'm trolling or creating the concern out of thin air, will also be brought to light in appropriate forums if need be. Szmenderowiecki (talk · contribs) 08:57, 1 February 2026 (UTC)[reply]

I am sorry, but that is my honest impression, right or wrong. If I were in your shoes, I would comment anywhere but here, as it will only draw more attention to your actions. In my opinion, you are skating on thin ice, and the more attention paid to this, the more likely it is that it will cause trouble for you now, or at some later date. You are of course always welcome to raise accusations you view as inappropriate at the appropriate forum, which would be my Talk page, followed by WP:AN/I if you don't get satisfaction there. If you just want to vent, I invite you to my Talk page. I can be very conciliatory, and will listen to what you have to say. Maybe it will make you feel better. Good luck, Mathglot (talk) 09:40, 1 February 2026 (UTC)[reply]

I'm not going to be the one to escalate, so the ball is in your court. I don't think any disciplinary intervention is necessary for any party here, for now, at least if you strike that accusation. I'm not going to be the one who shouts WP:UNCIVIL at the slightest hint somebody makes a faux pas and the one who drags you to ANI. I've worked jobs where people assaulted me every once a while and where I learned a lot of very interesting things about who I am and where I need return to (as a naturalised immigrant). I managed to still maintain a poker face most of the time and grow somewhat immune to these attacks. Bickering strangers on the internet are several pay grades below that.
But I will mount a defence if necessary. Or remain silent where I believe it will be best for my case. Szmenderowiecki (talk · contribs) 09:53, 1 February 2026 (UTC)[reply]

I have no wish (nor time) to escalate, so we agree on one thing at least. Sorry to disappoint, but I will not strike, as it represents my honest opinion. I agree that remaining silent is best for your case. I should add that I did not realize you were an immigrant and I am very impressed (and envious) of your command of English, which to me, appears to be of native-speaker level. I wish my abilities in foreign languages were as good as yours. Kudos! Mathglot (talk) 10:38, 1 February 2026 (UTC)[reply]

Szmenderowiecki, Actually, I will strike under one condition: I strike my comment, and immediately following that, you withdraw and {{hat}} this proposal as "|status=withdrawn". That would be to the general benefit of everyone. Do you accept? Mathglot (talk) 10:50, 1 February 2026 (UTC)[reply]

If there is a viable alternative proposal, I will withdraw this one. I am in works of discussing another one proposed by Sapphaline. This is independent of my request to strike/remove.
PS. For the future, I have a thing to say: editors are always responsible for their edits. It's only your decision because you made the claim. I don't want it to be on you, and I'm not going to complain myself. But if you stand by your claim, I reserve the right to consider it if necessary for any appropriate defence against any allegations. This is because if you have that honest opinion which you stand by even upon request to retract, this should imply that you have good evidence to back it up, which will stand upon independent scrutiny and presentation of all exculpatory evidence. And I want that possibility to rebut any point of that potential complaint, hence the "reserve the right".
I still appreciate honesty, even if it occasionally breaks rules of what discussion should look like. Szmenderowiecki (talk · contribs) 14:02, 1 February 2026 (UTC)[reply]

also WP:RFC specifically states "neutral and brief", this is neither. Polygnotus (talk) 16:46, 29 January 2026 (UTC)[reply]

you don't have a clear understanding of the situation so any proposal you make is hindered by that - sorry?

that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. Read all these discussions, understood them well, and I disagree with your premise. You can disagree with mine. You can think of it as a terrible idea but it doesn't mean it becomes a bad RfC question.

But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help. And no one came up with that idea at the idea lab, where you could have participated and told me this was a terrible idea and maybe we should do something else instead... That discussion was up for almost a month in a high-traffic forum. You could have proposed that idea yourself, the idea I didn't have before that comment. Why nobody thought of that before? Why do you blame me? For what?

neutral and brief - you just seem to be opposed to holding the RfC because you are satisfied with the status quo rather than having problems with neutrality and brevity. Because you don't say how it's not neutral. It's not the shortest statement but it's definitely not out of place for RfCs I witnessed in terms of size. Szmenderowiecki (talk · contribs) 16:54, 29 January 2026 (UTC)[reply]

@Szmenderowiecki you just seem to be opposed to holding the RfC because you are satisfied with the status quo To me it seems to be the other way around. It looks like you disagree with consensus formed in the recent preceding discussions (which is allowed of course) and then started an RfC that ignores the opinions expressed in them. Combine that with a very long and non-neutral RfC statement and you got a bad RfC. Polygnotus (talk) 17:02, 29 January 2026 (UTC)[reply]

I mention that the way I read that discussion was that the 75 KB wikitext limit was removed, and that's it. Nothing more, nothing less. The question was not specific enough to say if that means no limits or maybe some higher limit or something else. That was a bad RfC, because the result's interpretation is ambiguous. And you know it because you engaged in that discussion extensively. Szmenderowiecki (talk · contribs) 17:12, 29 January 2026 (UTC)[reply]

RfC asks for the question to be neutral and brief. This is easy to fix; we would move the neutral and brief "Do you support these changes as presented in the table below? If not, which specific parts of the changes do you not like?" to the top. From time to time, RfCs include background information. See for example Wikipedia talk:Please do not bite the newcomers#RfC: Rewriting specific sections. Aaron Liu (talk) 17:31, 29 January 2026 (UTC)[reply]

What the hell is this, your idea of a "big beautiful bill"? I presume I was pinged to here because of my close of this thread. It seems you've disregarded my advice to start separate RfCs for article-talk and user-talk. I do not care to spend hours getting up to speed on what you're asking for – your ping was an annoying distraction when I'm trying to stay focused on tasks in my to-do list which require focused concentration. Pick the one change that you most want to make, and which you believe has a strong chance of obtaining a consensus, and start with that, please. I'm not a member of a political party who will just vote up or down on your big bill, based on how my party leadership tells me to vote, without even bothering to read the details of the bill. – wbm1058 (talk) 17:14, 29 January 2026 (UTC)[reply]

What the hell is this, your idea of a "big beautiful bill"? Trump aside, the proposal was up for a month on a high-traffic page. Why didn't you engage? I gave a list of ideas and anyone could have said the thing you say now. But no, I have to be pummeled at the start of the RfC because people don't bother to look at the very place intended for workshopping proposals. Why workshop them at all then?

I presume I was pinged to here because of my close of this thread. - no, that's because you posted in the Discussion : Recommended maximum talk page size part.

It seems you've disregarded my advice to start separate RfCs for article-talk and user-talk. As I said, I see no functional difference between these two. I am free to disregard your advice if I believe it's bad advice.

your ping was an annoying distraction when I'm trying to stay focused on tasks in my to-do list which require focused concentration - Jesus Christ, I didn't know that pings can make people so cross. You don't have to engage with it, you can come to it later if your task list is what you need. There's no need to be so worked up. Szmenderowiecki (talk · contribs) 17:28, 29 January 2026 (UTC)[reply]

This proposal has not been up for a month, you just started it today, hours ago. I have no idea what proposal was up for a month on a high-traffic page, but it's not this proposal. – wbm1058 (talk) 17:43, 29 January 2026 (UTC)[reply]

I agree that one ping is a non-issue. But wbm and Polygno are right to recommend reducing the number of options/changes an RfC proposes (see also Wikipedia:Writing requests for comment#Best practices). You definitely can do that if you think it's best, but if so, you should expect the possibility that most of the parts would be met with chaos, confusion, messy discussion, and disgrunt, especially if you didn't hash them out first: Half of your proposals were not put forward at your Idea Lab thread, especially the change from recommendation to enforced rule. Aaron Liu (talk) 17:44, 29 January 2026 (UTC)[reply]

I have no idea what proposal was up for a month on a high-traffic page, but it's not this proposal. The idea lab thread? At almost 1,500 watchers, 9K pageviews per month, you bet it's a pretty high-traffic area. Or at least one that people supposedly watch.

Ad Aaron Liu: A recommendation is unenforceable. I meant it to be specifically a rule. If I wanted to make it a recommendation, I would have said so, but IMHO there's no point to discuss a recommendation if there's no enforcement of the recommendation.

Who cares if something is recommended if I disagree with the recommendation and there's nothing against disobeying the recommendation? Same for essays: who cares about essays if anyone can say "essay is not policy/guideline, so leave me alone"? Anyone's understanding of terms like "reasonable", "substantial", "large", "slow", if not backed by specific numbers, is different. What is "slow enough"? Is this "reasonable"? Is this inconvenience "substantial"?

Some people say "this is against current practice". OK. Just because it's current practice doesn't mean it's good practice. Substitute "current practice" with "industry standard", and you'll see what I mean.

Unfortunately, untangling a single piece of it is going to be very hard. Presumably, for the sake of simplifying discussion, it's going to be the size limit. So let's look at it:

- People are still gonna edit war over archiving and that's a concern, expressed incidentally at the TPG.

- I read opinions from certain users that manual archiving is busywork, and I agree. Also expressed incidentally at TPG.

- Doesn't address lack of archiving on pages like ERRORS.

- Enforcing anything on user talk pages without an impartial and specific mechanism is going to be hell.

- People are gonna ask: why only enforcement on user talk and not any talk? Well, that enforcement was supposed to be archive bots/logs (mostly) but you insist this be one proposal at a time, so I can't propose this. Unfortunately certain proposals only work in tandem.

- Empty talk pages are a concern for some users, and I agree with their concern - and it was discussed at the maximum talk page size discussion of all places, not minimum. So I felt it was necessary to address. I again get pummeled for that.

(Contrary to some suggestions, I don't mean this proposal as a snide against EEng. EEng's page was not the first time I had this problem, I just didn't speak up. This is a general applicability rule. Any talk page about 500 KB is absolutely terrible for my browser just reading it, pages of the size of ANI are terrible editing them). Szmenderowiecki (talk · contribs) 18:24, 29 January 2026 (UTC)[reply]

You'll notice there are very few guidelines as rigid as what you propose.

Ease of implementation is always something policywriters need to consider. Min threads and max archive size are going to be hard to implement.

It is great that you've identified and analyzed issues and are willing to put in the work or fix them. But often, if you put them forward in an RfC—the process for attracting as many participants as humanly possible—without consulting through non-RfC discussions, you are going to attract as many participants as humanly possible that have a lot of questions. Aaron Liu (talk) 22:32, 29 January 2026 (UTC)[reply]

This proposal does not say anything about min size. minthreadsleft or similar exist in both of the used bots. Max size is easily implementable by something like this: If pagesize exceeds, say, 200KB, archive the oldest discussions whose last comment was at least a year ago; if still exceeds, decrease by 30 days until you get within 200KB, but not below 10 days. Or something like that.
But often, if you put them forward in an RfC—the process for attracting as many participants as humanly possible—without consulting through non-RfC discussions the problem is that I have consulted my proposal. The gist was always there: mandatory automated archiving and limits on all pages intended for user communication. There may be an detail that I have not, but I consulted most of it. And people are shouting me down for this. Szmenderowiecki (talk · contribs) 23:00, 29 January 2026 (UTC)[reply]

Yes, I'm talking about min threads. You're not going to stop the extremely-popular manual archiving by just forcing changes to the most popular bots. It will also be hard to set up automatic archiving everywhere.

I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits. I did not see where you mentioned mandatory automated archiving at all. Aaron Liu (talk) 03:36, 30 January 2026 (UTC)[reply]

It will also be hard to set up automatic archiving everywhere. Nope, all it takes is a bot function that automatically introduces e.g. {{subst:setup auto archiving}}, when the first talk page thread is created. It is going to default to the loosest parameters, but you can change them manually later.
For existing pages, check for existing archive, if there is none but there are talk page threads, automatically deploy. I'm not a coder but pasting a text if a certain piece of text exists isn't a complicated piece of code we are speaking of.

I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits

• a was originally expressed as the minimum size limit (it was 500 KB HTML, but it could be 200 or 300 or even 100, so long as it's not 0. The pseudocode part at the bottom included the minkeepthreads parameter. I got feedback that the code was "too complicated", so I simplified it. I was never that part was a bad idea.
• c (mandated archiving) is literally the second bullet point in the VPI.
• f is the seventh bullet point
• g was discussed along the way.
• the change from "should" to "force" Equivalent in meaning for purposes of guiding user behaviour. If "should" had been supposed to be a non-binding recommendation, the discussion would have made no sense.
• the 50%/90% reduction in the page size limits. I don't know what you are talking about.

Szmenderowiecki (talk · contribs) 10:36, 30 January 2026 (UTC)[reply]

Szmenderowiecki, is it then your position that mandatory automated archiving would apply to all user talk pages, including those currently archived manually? As an example, my user talk page, now nineteen years old, is manually archived and always has been. If your proposal achieves consensus would I have to give up manual archiving and submit to obligatory bot archiving? What about users who manually archive by theme (or other algorithm of their choice) instead of last comment age? Oblige them to switch as well? Mathglot (talk) 03:49, 30 January 2026 (UTC)[reply]

Read the proposal carefully and you will get the answer. Short answer: no, do whatever you want so long as you keep within the size guidelines out of your own accord. If you refuse upon request, or you have trouble keeping the maximum size long-term, only then it becomes a yes.
Archiving by theme will not be possible because we don't have bots that guess the discussion's context and sort discussions into buckets according to what you are talking about. If an admin wants to manually sort their discussions, fine, but I don't expect admins to do that because they likely won't hve the time and their job is not to micromanage others' talk pages.
If you don't want this to happen, keep within your 1200 KB HTML and you'll be golden. I'm upfront that this is a restriction on user autonomy, but user autonomy, just like generally being allowed to edit, is not a right, it's a convention. If your user autonomy makes others suffer, you are abusing it. Szmenderowiecki (talk · contribs) 10:46, 30 January 2026 (UTC)[reply]

Any talk page about 500 KB is absolutely terrible for my browser just reading it @Szmenderowiecki: Three quick questions. What browser are you using, how much RAM do you have, and how fast is your download speed? This is because I think the problem here may be your device, whatever it may be.

This is not to say that people should intentionally keep talk pages large just for the fun of it; I'm just saying that there may be technical limitations on your end that are affecting your ability to read really large pages. I can still open EEng's 972k talk page in Safari on my iPhone 11 with 140 other tabs and 24 other apps open, probably because iOS is really good at memory management and frees up memory from inactive apps and Safari tabs. Trying to edit EEng's talk page, however, is a different matter... SuperPianoMan9167 (talk) 23:19, 29 January 2026 (UTC)[reply]

Sure: Chromium 143, 8 GB RAM, 25 Mbps download on WiFi. RAM is 100% not an issue because I have tons of spare RAM without forced cleaning, neither is download speed because the whole source code should be downloaded within at most a second, shorter than the rendering itself. Everything works pretty fine with these parameters on any web site until I get to gargantuan talk pages on Wikipedia. Or try to edit big talk pages.
It's not a "me" problem. Szmenderowiecki (talk · contribs) 23:31, 29 January 2026 (UTC)[reply]

Okay. I figured as much but I still wanted to ask.

I admit that I have sometimes experienced issues on very large pages; I've gotten the "This webpage was reloaded because a problem occurred" message (which is Safari's way of telling you that the page crashed because it ran out of memory) on large talk pages before. When I scroll down a very large page, it usually takes a couple of seconds for the page content to appear. And of course, the sheer size of these pages makes them difficult to navigate on mobile (Minerva skin helps to make this less tedious). SuperPianoMan9167 (talk) 23:41, 29 January 2026 (UTC)[reply]

Minerva skin looks shit on desktop, and besides readers are very likely not aware that they can change the skin using the "Mobile version" link, and quite a few may not be even aware of the possibility.. So long as we allow IP editing, any reader may become an editor with no warning. Any IP who wants to post on any noticeboard or talk page and the noticeboard is 500K+ is likely to abandon the effort due to the lags. This is unacceptable Szmenderowiecki (talk · contribs) 10:50, 30 January 2026 (UTC)[reply]

• My understanding is that there's no standard way of archiving pages and so there's a mish-mosh of bots and tools. I've evolved my own way of filing my talk page but it's too manual for my taste. Anyway, I have a question. What I'd really like is a simple method of moving a section from one page to another. This is the way that email and other documents are usually filed -- you move them to folders. Is there such a thing in Wikipedia? Andrew🐉(talk) 17:30, 29 January 2026 (UTC) (edit conflict)[reply]

  I believe the closest we have is one click archiver, but in theory it should be possible to develop something that can do a similar action but to a manually defined page. CMD (talk) 03:34, 30 January 2026 (UTC)[reply]

• BTW, every time I've tried to say something in this discussion, I've gotten an edit conflict. Wiki software is really poor at doing user communication when compared to just about everything else. Andrew🐉(talk) 17:34, 29 January 2026 (UTC)[reply]

  Try c:User:Jack who built the house/Convenient Discussions.
  Both moving topics and automatic retrying after edit conflict sure included. Aaron Liu (talk) 17:47, 29 January 2026 (UTC)[reply]

  I've heard of that tool before but it seems too complex for my needs and I gather that it is resource-hungry. Looking at its talk page, it seems that there's an incompatibility which is going to break it. I've seen many useful tools broken as a result of change and that's why I think all such infrastructure and interface should be managed centrally by the WMF. Andrew🐉(talk) 23:19, 29 January 2026 (UTC)[reply]

  I daily-drove the parser migration tool (which allows you to set your default parser to parsoid) in late 2024 and had no issues with CD (in fact, little issues at all other than the reduced server caching increasing page load times). I just checked again and everything works. @ChildrenWillListen probably had a configuration issue.

  There's been many calls for WMF to maintain promising infrastructure. WMF couldn't even install it. (slightly clickbait, but I couldn't figure out a better way to summarize this, sorry) Aaron Liu (talk) 03:31, 30 January 2026 (UTC)[reply]

  sounds like they should hire some engineers then, I hear there are a lot of people looking for work Gnomingstuff (talk) 20:04, 30 January 2026 (UTC)[reply]

  You mean the same engineers who built out the internet to give us a postliterate society where everyone is addicted to screens, where people no longer read books, where society is more susceptible to disinformation and propaganda, and who are solidly against the humanities and democratic values? Those guys? Viriditas (talk) 22:47, 31 January 2026 (UTC)[reply]

• Please keep in mind about mobile users, who because of such small screen size have to contend with extremely difficult scrolling of pages with long discussions or too many threads (especially as the font size for thread headings can be relatively large ~2026-63332-0 (talk) 17:54, 29 January 2026 (UTC)[reply]

  ~2026-63332-0 consider going to WP:VPI and proposing that the WikiMedia software automatically provide page nav links 'skip to top' and 'skip to bottom' for moibile users, when the page size or number of threads is greater than X (user preferences-configurable). Then, after you get some feedback and some kind of working consensus there on what might be useful and have some support, take it to the meta:Community Wishlist and register your wish. Mathglot (talk) 19:34, 29 January 2026 (UTC)[reply]

  Minerva skin already provides a "Latest comment" link at the very top of the page and in the header of each section, which is very helpful. In fact, it is so helpful that I sometimes find it easier to comment on talk pages on my phone than on my computer in Vector 2022.

  (Yes, I use Vector 2022. Experienced editors may now publicly shame me. I've been reading articles here for long enough to remember a time when it didn't exist yet. I also (gasp!) used VisualEditor when I started editing, but I eventually quit using it because I find that writing wikitext directly is much faster, especially on mobile where I don't have access to keyboard shortcuts.) SuperPianoMan9167 (talk) 23:52, 29 January 2026 (UTC)[reply]

  That's good to know; that means that the code to do this already exists, and porting it to other skins should not be that difficult. I would say in response to temp user 63332, that either in addition to, or instead of the Community Wishlist idea, you could file a Phabricator ticket requesting it as an enhancement. (I think you have to be registered, but make a request at WP:Help desk and I am sure someone could help you with that.) Mathglot (talk) 02:32, 30 January 2026 (UTC)[reply]

  There's no need for a Phab ticket. Go to Special:Preferences#mw-prefsection-betafeatures and turn on "DiscussionTools". Go to Special:Preferences#mw-prefsection-editing-discussion and make sure that "Show discussion activity" is enabled.

  If we want this enabled by default, then an RFC and a config change request would be enough. WhatamIdoing (talk) 20:02, 31 January 2026 (UTC)[reply]

• CapnZapp I'm confused about your order of opposes in justifications.
  • The A part refers to what, the introductory statement or the mandatory archiving? Mandatory archiving does not speak about user talk exemptions or even user talk at all in the justification. User talk is specifically exempted, end of story. What are you talking about?
  • The B part presumably refers to specific limits. I don't have a problem with EEng, I do have a problem with his talk page, as with hundreds of others I cannot easily read, interact with, let alone edit. Also, good luck.
  • C (max archive interval) misunderstands the proposal. The 10 day limit is only meant to cover high-traffic pages ("likely to routinely exceed the maximum size limit"), and that's additionally explicit in the last sentence.
  • D is not substantial to this discussion, I could have edited this myself.
  • E: Why 4 minimum threads specifically? I had opinions that 1 is the number. Some prefer 2. Some prefer 5. We can discuss it.
  • F: Impossible to discuss in separation of B because there are no maximum user talk page size regulations right now, so such change would be meaningless. I'm not sure what I'm poisoning by opening this discussion.
  • H: Possible to discuss at the archive bot pages, but will likely discourage people from using bots. So pretty much impossible to discuss without A because it's pointless. It is meant to be the automated enforcing mechanism. Szmenderowiecki (talk · contribs) 18:48, 29 January 2026 (UTC)[reply]

    I explained at the start. Basically, I went through the table, creating a point for each row. Only once I was done did I realize you failed to match your a-g to your table. CapnZapp (talk) 18:54, 29 January 2026 (UTC)[reply]

My comment before was that Endorse This is the single stupidest thing Iv ever seen be discussed on here. I'm legit laughing my tired ass off, and despite having zero memory of writing that(it was 3AM, and I was coughing up a storm). I still stand by it and it's even more funny that this was made seemingly solely because of EEng.

Has anyone ever considered that if we weren't such assholes about it, he might be willing to archive more often? Or ask him to add skip to top or bottom buttons like iv seen on a few other user talkpages?

We have had this discussion so many times, it always ends the same.

If the page starts crashing browsers, bring it up to him, otherwise, just wait the extra two seconds for it to load. And use the edit section function.

I'm against all the points. LakesideMiners^{Come Talk To Me!} 21:18, 29 January 2026 (UTC)[reply]

@Szmenderowiecki, what's your plan for handling individual discussions that exceed 200K? For example, Wikipedia:Requests for comment/Rollback of Vector 2022 is 910K. Wikipedia:Requests for comment/Merging merge discussions with AfD is a currently active RFC that is over 230K so far. WhatamIdoing (talk) 22:06, 29 January 2026 (UTC)[reply]

From the table: Single discussions split into their own pages due to size considerations are exempt from internal archiving but have to be searchable through archives of the page they were split from.

There might be creation of subpages due to size considerations, but I understand that there may be discussions with huge turnout wbhich cannot be split, or pages with several questions that are interconnected ando so would be inadvisable to split. So there's no dedicated solution for this problem. Accessibility is an issue due to poor performance, but any other solution would be worse. Szmenderowiecki (talk · contribs) 22:13, 29 January 2026 (UTC)[reply]

So firm rules, except for exceptions. WhatamIdoing (talk) 22:47, 29 January 2026 (UTC)[reply]

IMHO better than no rules at all. Making a carveout where necessary is a sacrifice I'm willing to make. Szmenderowiecki (talk · contribs) 22:49, 29 January 2026 (UTC)[reply]

I'm here because of the ping. I don't like anything about this proposal, but I do like the comparison made in this discussion to the so-called Big Beautiful Bill. --Tryptofish (talk) 00:17, 30 January 2026 (UTC)[reply]

You gave the reason yourself above (@23:10, 29 Jan) why this Rfc was unnecessary and a gigantic waste of time; quote:

We already have a recommendation [about] [l]arge talk pages...

Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is, which is why adding copyrighted material to a Wikipedia article or libeling someone is going to get you in hot water faster than conflict of interest violations, which in turn will get you in trouble faster than WP:Manual of style violations.

As you say, we already have a recommendation about this, but apparently, your opinion is that the existing recommendation doesn't have enough teeth in it on the enforcement side, hence all the draconian language trying to sharpen the teeth. But this violates the sense of proportion. There is a reason that libel and copyright get more attention and stricter enforcement. No doubt in the thicket of Wikipedia regulations, improvements can be made, but we do not want very large talk pages to have the kind of enforcement wording or response that libel does; it is way out of proportion to the seriousness of the violation (if it is even deemed a violation at all). Nothing in your Rfc proposal is an improvement over current guidelines imho, imperfect as they my be; rather, they would make page and archiving guidelines worse, and cause additional strife among editors, perhaps resulting in enforcement discussions against users with long talk pages. Is that really the hill you want to die on?Mathglot (talk) 02:58, 30 January 2026 (UTC)[reply]

Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is
You may disagree with me on this point, but overbearing talk pages that barely load and are all but impossible to edit are pretty much a serious violation on a website whose core tenet is enabling editing and good-faith discussion by anyone interested in the topic or in a contributor at any time. If the "anyone can edit" (=have technical tools to edit) part in "Wikipedia is a free online encyclopedia that anyone can edit" can be rendered effectively moot, then it should not advertise itself as such. If Wikipedia effectively forces users to switch from not-clearly-outdated devices to view/edit content, it is no longer anyone who can edit.

Also, the enforcement for libel and copyright violations is potential blocks as well. This rule is not meant to create another means to block someone because this can be resolved without blocking anyone. And I wrote just that in the reasons. So despite the seriousness of obstruction of talkspaces, it does not escalate to revocation of editing privileges. Szmenderowiecki (talk · contribs) 11:13, 30 January 2026 (UTC)[reply]

"Overbearing talk pages that barely load and are all but impossible to edit" would be a problem if they existed, but they don't. As another user said, "Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds."

And even if they did exist, the rational approach would be to go to ANI, document the problem, see what happens when others try to replicate it on similar hardware, and if the problem is real deal with that one page. (If anyone does this, ping me. I have a number of ancient computers running ancient browsers available to me) --Guy Macon (talk) 03:16, 31 January 2026 (UTC)[reply]

Also, while it might be great if everyone could easily use any device to leave messages at all talk pages, forcing compliance with a uniformity rule would make Wikipedia a nastier place with the side effect of encouraging rule-pushers while discouraging a variety of editors. Johnuniq (talk) 03:50, 31 January 2026 (UTC)[reply]

Also, the difference is that libel can get you sued and long talk pages can't. Gnomingstuff (talk) 04:01, 31 January 2026 (UTC)[reply]

Guy Macon, is it that you insinuating that I am lying my ass off about the problems I have with loading the pages, do you pretend to know better than me how my device works, or are you saying "not a problem for me, so deal with it"? My device specs are public knowledge at this stage.
Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds
A lot to unpack here:

• We don't know what the specs of that device that loaded the page for 30 seconds were, and what software they use.
• We don't know if that device is one of the "ancient" devices that the user uses for browsing the web (what is "ancient"?). What they said does not exclude the possibility that they tested it on an iPhone 16 Pro or some modern PC for $2000+.
• We don't know what the "other pages" are.
• 30 seconds to be able to interact with a page element is absolutely unacceptable performance. Anything over 4 s of basic rendering (LCP) and 500 ms of response between click and action (INP) is poor performance on Chromium-based browsers. That user may put up with it but there's a reason Google says it's poor performance. If I were a random user I would have never tried to interact with that page again. This is a problem.

the rational approach would be to go to ANI, document the problem, see what happens when others try to replicate it on similar hardware, and if the problem is real deal with that one page
Or maybe, just maybe, avoid all this dragging to ANI unless absolutely necessary and document a procedure that everybody knows, and everybody is aware what happens if it is not followed? And not bog down in discussion on whether your device sucks, on whether you should change your device, lifecycles, operating systems, differences in browsers, popular userscripts you choose to run and so on? I thankfully see, hear and read well, but there are folks who have to read Wikipedia with a page reader. Folks who need high contrast because they don't see that well. On Chrome, this is done via extensions. But these extensions will struggle even worse on huge pages. Which is a reason you don't do huge pages unless absolutely necessary.
(OK, you'll say, this concerns like 1% of readers/users, so whatever, suffer. Well, modern public transport has Braille and wheelchair ramps not because there are a lot of blind/physically disabled people but because they also deserve the service. It generally features low-floor vehicles not only for these people but for anyone - whether you are a normal passenger or you carry a big bag of groceries home or maybe a bicycle or a stroller. You could have the bare minimum of seats for the frail to cram as many people as possible within a given budget for new vehicles - after all, most people can stand up for 15 minutes just fine - but that doesn't normally happen because passenger comfort is also a valid consideration.) Same logic applies here.
forcing compliance with a uniformity rule would make Wikipedia a nastier place with the side effect of encouraging rule-pushers while discouraging a variety of editors.
One by one:

• nastier place: in which way?
• side effect of encouraging rule-pushers: where possible, make rules that are clear, unambiguous and tight so that they do not leave the possibility for wikilawyering. Simple as that.
• discouraging a variety of editors - well, the inaccessibility discourages me from engaging on Wikipedia because I have that info in the back of my head that I will not be able to edit certain pages without some non-standard hacks. And I'm pretty sure I'm not alone, but I'm also pretty sure not everyone would want to search for said hacks.
• Also, the difference is that libel can get you sued and long talk pages can't. POV pushing is a serious violation of Wikipedia's rules, but will not generally get you sued. Same for obstruction of discussion process. I don't see your point.

Szmenderowiecki (talk · contribs) 07:56, 31 January 2026 (UTC)[reply]

@Szmenderowiecki

Plain text rendering is extremely fast. Even large amounts of text render quickly. The bottleneck on Wikipedia is almost always JavaScript, especially scripts that process the entire page. So limiting the amount of plain text makes no sense.

Loading large external resources (images) can slow things down, but usually those get cached so they would only be slow once. So in your case the reason is JavaScript.

1. Find a page on which the problem is reproducible (ANI?)
2. Visit that page in an incognito (sic) window, without logging in. Does the problem still occur?
3. In a non-incognito window: disable your scripts and DiscussionTools in preferences, then try again. Does the problem still occur?
4. Enable your scripts and DiscussionTools again and capture a performance profile (not the HAR file) and post a link.

Polygnotus (talk) 11:41, 31 January 2026 (UTC)[reply]

I will tell you the results:
Point 2: Loading pages like EEng's make browser visibly struggle upon rendering even when logged out. Just slightly less time than in my JS configuration. Impossible to say if editing is impacted because my editing environment in source is the 2017 wikitext editor and it's a small box when logged out. Also, I do feel the need for syntax highlighting to better see the, you know, syntax. My eyes get lost in the sea of monotone black text.
Point 4: The files have like 50 MB each, so I'd need to make sure you will have to be able to download these. I tested this on just reading User talk:Tryptofish (870 KB wikitext at the moment). The summary results I got were these:

Painting 10,280 ms
Scripting 4,300 ms
Rendering 4,116 ms
System 2,050 ms
Loading 285 ms

with all scripts but Convenient Discussions enabled; and I have a separate batch for Convenient Discussions enabled - which did eat a lot of resources but is also clearly superior to current talk design IMHO. The browser could not load the right-click menu without significant delay while all of this was happening.
On Convenient Discussions disabled, LCP 2.56 s (needs improvement, <2.5 s for good), Cumulative Layout Shift (CLS) 0.91 (poor, <0.25 for needs improvement, <0.1 for good), Interaction to Next Paint (INP) 600 ms (poor, <500 ms for needs improvement, <200 ms for good)

But all of that is besides the point. An editor does not have to disable the JavaScript tools they feel they need for editing just to accommodate for excessively long talk pages. You have it backwards. If WMF says the software option is good enough for choosing directly in my preferences without any caveats, I trust that the software is ready to be used out of the box. That's the default expectation of any new user, and it's how it always should be. The JS may be buggy, but that's not the issue of buggy JS, at least not on my side, because I can replicate all the same issues while logged out. And even then users are not expected to be debuggers or know how a certain piece of code may impact performance. Maybe if you get the template editor or the interface administrator bit. But that's not for the vast majority of users.
I am used to the environment I edit in and it doesn't cause me much problems for 99.9% of my use cases. I don't have to change it because of the 0.1% of the times when I need, or hell, choose to land on long talk pages, that's ridiculous. Also, there's a brilliant public service announcement by the government of Wales on disability that illustrates my way of thinking - why don't you just raise the roof if you can? Or, in this case, why don't you make the pages uncluttered enough so that any user can answer? The roof job may be expensive but the uncluttering isn't asking for much. Szmenderowiecki (talk · contribs) 14:00, 31 January 2026 (UTC)[reply]

@Szmenderowiecki Interesting, thank you. I can download files up to ~20tb in size.

It looks to me that the problem is not the amount of plain text (as I predicted). The problem is the amount of Document Object Model elements.

Every piece of a webpage, each paragraph, link, button, image, or heading, is a DOM element.

The issue is that talk pages contain many DOM elements: signatures, timestamps, indents, etc.

So if you want to limit something it should be the amount of DOM elements on a page, not the amount of text.

And the situation wouldn't be so bad if DiscussionTools didn't add so many DOM elements per comment. Even when you aren't logged in.

Would you be willing to share some data with a WMF nerd? I may be able to find someone who can further diagnose this problem, and work towards a fix.

It won't be automated archiving of all pages, but maybe drastically reducing the amount of DOM elements added by DiscussionTools.

@Quiddity (WMF): probably knows who to ask. @Quiddity we need someone who can check why long usertalkpages render very slowly for Szmenderowiecki. It is probably/possibly DiscussionTools related. Do you know someone who can look at a performance profile and diagnose the problem? Thanks, Polygnotus (talk) 15:24, 31 January 2026 (UTC)[reply]

DOMs are in large part generated by text you and other editors type. Too much DOMs is usually a problem of the page and not the user who tries to load the page. If the page is user-generated, then it becomes the responsibility of the user(s) who contribute to that page, and to maintainers of the engine rendering that page, to make sure the amount of DOMs does not impact user experience.
The meaning of DOM is not also something we typically expect from a regular user to know about. They just expect the website to work.
DiscussionTools were disabled because I use Convenient Discussions, which is incompatible.
WMF can contact me directly for inquiries at any time. Szmenderowiecki (talk · contribs) 15:55, 31 January 2026 (UTC)[reply]

@Szmenderowiecki DOMs are in large part generated by text you and other editors type. DiscussionTools adds a whole bunch of DOM elements per comment. About ~8. If you want to we can make a test page that contains the same DOM elements but no text and you'll see it load slowly on your computer.

It is the responsibility of the WMF to deal with performance problems. Quiddity has over 2 decades experience on Wikipedia and started working at the WMF in 2013. They'll know who to ask.

DiscussionTools were disabled because I use Convenient Discussions, which is incompatible. Unfortunately DiscussionTools still adds those DOM elements to the page, even if you have it disabled and even if you are not logged in. Polygnotus (talk) 16:02, 31 January 2026 (UTC)[reply]

Irony above: "This page is too big. Excessive page size can cause accessibility problems for some editors. Please temporarily speed up the page archiving rate or split large discussions to separate subpages" ~2026-68406-1 (talk) 15:19, 31 January 2026 (UTC)[reply]

I have a 4Mhz (That's megahertz, not gigahertz) Z80 running CP/M and Fusix that communicates at 9600 baud. It can display and edit text-based discussions of any length on USENET or BBSs lightning fast -- no need to limit discussion size. If computers that are thousands of times faster than that are struggling, the obvious answer is to talk to the WMF and ask them to look at what they are adding to the text. --Guy Macon (talk) 17:38, 31 January 2026 (UTC)[reply]

I mean, any website would load well, whatever its volume, if it looked like The Motherfucking Website. It could probably run on a potato - but that's not really the point. In 2026 I'd expect at least this or this or this or this.
I'm not saying there isn't a room for code improvement (although I don't know if it's true) but if the suggestion is that I have to disable certain in-built features just to be able to view/edit large pages, that person also has it backwards. Szmenderowiecki (talk · contribs) 21:24, 31 January 2026 (UTC)[reply]

If you want a fun view into the alternatives, the debug page for EEng's talk -- which reformats it into a far more "modern" experience -- is worth viewing: https://en.wikipedia.org/wiki/Special:DiscussionToolsDebug/User_talk:EEng

I'm actually sort of curious whether you feel it performs better for you once you get to the point of actually scrolling around. Not really the initial load (it's not a useful comparison because it's less cached by the parser which slows it down, and it doesn't actually initialize DT reply widgets which speeds it up), but we were able to massively reformat the HTML used there in ways the talk pages community consultation didn't let us consider. DLynch (WMF) (talk) 15:37, 3 February 2026 (UTC)[reply]

Since talk page size and number of DOM elements is strongly correlated, then reducing talk page size would actually solve these problems. WhatamIdoing (talk) 20:11, 31 January 2026 (UTC)[reply]

I played around with document.querySelectorAll('*').length and that first assumption is incorrect. Reducing all talk pages to 10 bytes max does fix the problem so the second one is hard to disprove. Polygnotus (talk) 20:21, 31 January 2026 (UTC)[reply]

Polygnotus what's your plan if WMF says that everything is all right with the software or if they do not answer back your ping (presumably because they don't think that your suggestion of simplifying MediaWiki output is not worth the effort))? Szmenderowiecki (talk · contribs) 10:08, 1 February 2026 (UTC)[reply]

@Szmenderowiecki There are people who work at the WMF whose entire job it is to ensure that Wikipedia works properly on as many devices and in as many situations as possible. Quiddity works or has worked in the relevant team.

Help them help you, this is your best shot. There are people who have been tracking such stats for years and are interested in situations where the user experience is bad, so they know what to do and not do.

Quiddity is usually quite busy so we can leave a message on their talkpage in a week or so , if necessary. If you are polite and constructive they will help you. They may ask you some follow-up questions or do some tests so they can understand your experience better. Polygnotus (talk) 12:48, 1 February 2026 (UTC)[reply]

This doesn't really answer my question. Sorry if I'm not clear, so I'll rephrase it. While I disagree with their opinion, some users say that WMF alone is responsible for this, not users (my opinion is that it's a joint responsibility). Suppose that WMF/MediaWiki says any of the following:

• Our software works just fine, no bugs impacting performance detected, anything else?
• We fixed bugs that give a boost of 1.3% in loading time, but that's about all you will get.
• This is core functionality that we are not ready/willing to disable.
• We are introducing something new that will increase JS load, so no scaling back (given that webpages get more bulky over time and old devices, including, hopefully, mine as well someday, get changed - not a stupid thing to expect). We are not introducing any "lite" version of MediaWiki with just the bare minimum of DOM elements necessary for MediaWiki functioning and images linked instead of actually loaded. There will be no toggles.
• I agree with Szmenderowiecki that just because there's a technical limit to a page that our servers can handle doesn't mean that any individual page ought to push towards it because of UX issues. (They may even issue a recommendation in their user guides to the effect that a page is not supposed to be over X KB wikitext unless necessary)

In other words, suppose WMF/MediaWiki says it's actually not their problem, it's the problem of the community, because there's nothing/not much to fix on the software side (regardless of whether they tell the truth, because you are not going to get anything (more)). What happens next?

I will reiterate that if @Quiddity (WMF): or any other person who they believe will be competent to look into this issue wants to get feedback from me, they can ask all relevant questions and get relevant test results. Here, by email or otherwise. Szmenderowiecki (talk · contribs) 13:16, 1 February 2026 (UTC)[reply]

@Szmenderowiecki That is a very hypothetical hypothetical. They own the servers and they sign the contracts and they have the money.

So in theory they could decide to stop this whole Wikipedia thing and start a VIP dog walking business in Lithuania instead. There is nothing you or I could do to stop them.

Of course its a joint responsibility; I could easily install some Javascript shitcoin miner that will tank performance.

In reality at least some of the people who work at the WMF are nice, hardworking people who share our goal. That doesn't mean I agree with every decision ever. Quiddity was a Wikipedian for years before he started working at the WMF.

Since they share our goal they want Wikipedia to work well for everyone, on any device. That means they will at least try to investigate the situation.

Will you be happy/agree with the result of the investigation? Will there be a quick fix that solves the problem in a week? I do not know, but if we don't give them the information they need we can't complain about performance.

If they say "WONTFIX" then at least we know where we stand. I can look at your pc (if you let me), but not their servers. The WMF can see exactly what is happening on both ends if you let them. So they are in the position to fix this.

I am pretty certain they will at least look at the problem. I can't promise you'll be happy with what they do with that information because they don't work for me. They are independent beings with free will. And they are your best bet to fix this problem once and for all. Polygnotus (talk) 14:04, 1 February 2026 (UTC)[reply]

Listen, if MediaWiki suddenly runs 3x faster and the load time is no longer a nightmare, I think anyone will be ecstatic. I would still argue the switch is necessary on other grounds - for example, because large pages, even if they load OK, are hard to navigate. But at least the barrier to discussion will be not as severe.
So yeah, I wait for instructions from MediaWiki/WMF team. Szmenderowiecki (talk · contribs) 14:11, 1 February 2026 (UTC)[reply]

Just confirming that I have seen these pings and am passing along the request for technical investigation - [EDIT: Done at phab:T416247.] Quiddity (WMF) (talk) 20:04, 2 February 2026 (UTC)[reply]

(reply-to @07:56, 31 Jan) The performance report (parser profiling data linked at T416247) on loading the long user talk page you most complained about, shows a CPU time of 5.977 and real time of 6.714 seconds. This is only half again over the limit of 4 s you list as acceptable performance. If that is the actual load time for the worst Talk page at Wikipedia, then I'd say we were doing pretty darn well! I believe you wen you say that it is taking much longer than that for you to load the page on your hardware/software configuration, even if it takes much less time for others who have tried it on various setups, including ancient ones. Various conjectures have been raised about why that is, and the phab ticket will hopefully shed some light on that and lead to improvements for everyone. But making a proposal to limit Talk page size based on a misdiagnosis of a problem you are seeing and others do not, and then adding a draconian archiving proposal on top of it to be imposed on everyone based on the original misdiagnosis seems to be compounding error upon error, and not a valid proposal. I suggest we wait until we understand why you are getting the delay you are. And thanks for agreeing to provide input to the investigation tracked at the Phab ticket. Mathglot (talk) 03:55, 3 February 2026 (UTC)[reply]

There is irony and confusion. Why do we need more "rules"? Maybe this is putting the proverbial cart before the horse in some or most cases. Read #7- "Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval. Who has encountered pushback for achieving long talk pages? It seems any editor who finds a long discussion page (article talk) can archive older discussions.

At best, this is a terrible idea. At worst, it might be insane. It is too broad. Editors should not run out and buy a cart, then walk around looking for a horse. I would think suggestions or a number by consensus on page size limits would be found at Wikipedia talk: User pages. Help:Talk pages#Archiving states, On talk pages that generate significant amounts of discussion, old discussions are often archived to keep the size of the talk page at a manageable level. It states this can be done manually or with the help of a bot, but no suggested size. Although there is no link to the specific bot for "help", there is the "Main page: Help:Archiving a talk page". (TALKSIZE) gives some rationale, and Wikipedia:Talk page guidelines#User talk pages (maybe in the "Personal talk page cleanup" section) might be a good place to have some information on page size? It seems this may be important for new users or editors who would like some teeth and a place to point to. It is sort of a sad idea to attempt to teach someone to swim by just tossing them into the water. I think we should steer clear of user talk pages. -- Otr500 (talk) 01:10, 1 February 2026 (UTC)[reply]

A lot to unpack here: We don't know what the specs of that device that loaded the page for 30 seconds were, and what software they use. We don't know if that device is one of the "ancient" devices that the user uses for browsing the web (what is "ancient"?). What they said does not exclude the possibility that they tested it on an iPhone 16 Pro or some modern PC for $2000+. We don't know what the "other pages" are. I'm the user in question: that particular test was with an obsolete Android phone from circa 10 years ago. I tried it today with a 2015-model Raspberry PI 2 that I bought in 2016 for about $30 (now past end-of-life, has been sitting in a non-climate controlled junk drawer for years) and was also able to successfully load the page and open the editor (first load on that machine took about 10 minutes, but subsequent loads took ~30 seconds, indicating that the slow first load was due to media loading/caching, not byte size as targeted by this proposal). I don't claim to understand your computer setup better than you do, but I'm just saying that you seem to have far more powerful hardware than I do, on a better internet connection, yet you seem to be getting worse results. -- LWG ^{talk (VOPOV)} 02:22, 1 February 2026 (UTC)[reply]

OK, so that makes sense now. I mean, yes, obviously a Raspberry Pi will be less powerful than my computer. But contrary to what you say, my computer is not so bad as to be loading User talk:EEng for 10 minutes. It takes about 30-35 seconds on the first load (so no cache yet available) with browser freezing in the meantime or extreme difficulty to navigate any other part of the browser or the already rendered part of the page. With cache, this decreases to something like 15 seconds.
It still is unacceptable behaviour. Say what you will about Google but they know how to code shit and know about reasonable expectations of performance, and also know a bit about UX/UI as well. Szmenderowiecki (talk · contribs) 09:18, 1 February 2026 (UTC)[reply]

It still is unacceptable behaviour. Ok, so it sounds like your experience is pretty similar to what I get on my primary devices. It seems like the core point of contention here is: should Wikipedia users be obligated to maintain their talk pages to provide a Google-level industry standard UI/UX experience to all conceivable hardware/browser configurations? to which the answer of the community appears to be matching recent North American weather with a resounding no. -- LWG ^{talk (VOPOV)} 16:37, 1 February 2026 (UTC)[reply]

You are asking the question no one was actually asking.
The good/needs improvement/poor score is a score that any website can get and these score are relevant for any website. It is not guidance for Google-owned sites only, it is guidance for all web sites.
So no, Google-level UI/UX experience is something we probably should strive towards but this was NOT proposed as a requirement. Szmenderowiecki (talk · contribs) 16:48, 1 February 2026 (UTC)[reply]

Sorry for being unclear, by "Google-level" I didn't mean to imply only Google owned sites, just the best practices they advocate. Which is a fine question to ask, but the community seems to be comfortable with falling a few seconds short of that ideal. -- LWG ^{talk (VOPOV)} 18:57, 1 February 2026 (UTC)[reply]

LONG PAGES

At Wikipedia:Database reports/Long pages/User talk (no_subpages) I see a bunch of users who were indefed long ago and are obviously never coming back. Would anyone object if I or someone else set up archiving on those pages? --Guy Macon (talk) 02:17, 1 February 2026 (UTC)[reply]

Yup, because that is a database report, not a backlog. Anyway that stuff is always outdated; if you run Quarry 100159 you get fresh data. Polygnotus (talk) 02:21, 1 February 2026 (UTC)[reply]

Also the top 99 contains only 19 users that are active (defined as having edited in the past 12 months) and not blocked, 2 indeffed users and 78 users who have not edited in the past 12 months. There is no reason to edit the talkpages of inactive and indeffed users. Polygnotus (talk) 02:35, 1 February 2026 (UTC)[reply]

This discussion was opened two days ago (14:29, 29 January) so why does it already feel like a month? The section sizes template (which I don't trust for word count) tallies the discussion at 129,627 bytes and 606 prose words. My text editor (which I do trust, but which counts hidden text and sigs as words) tallies it as 130,065 bytes and 21,662 words. There is a do-not-archive-until template at the top configured for 5 March. If the discussion keeps going at this rate until 5 March, it will be approximately 1.8 million bytes and over 300,000 words.^[b]

What shall we do?

A – request closure

B – let it run

C – something else (specify)

Your choice? Mathglot (talk) 03:49, 1 February 2026 (UTC)[reply]

• B. I don't see any reason to shut off discussion so soon, on what is clearly a very active discussion. Mathglot (talk) 03:49, 1 February 2026 (UTC)[reply]
• Mathglot just invented the meta-RfC! I choose option E. Something productive. Polygnotus (talk) 03:53, 1 February 2026 (UTC)[reply]
• C: Keep this discussion going until it reaches one million bytes of discussion.^[FBDB] But in reality, B, as there is still legitimate discussion happening. SuperPianoMan9167 (talk) 03:54, 1 February 2026 (UTC)[reply]

  Perhaps a special price for whoever adds the millionth byte? Polygnotus (talk) 03:57, 1 February 2026 (UTC)[reply]

  That kinda reminds me of discussions like this one. Mathglot (talk) 07:56, 1 February 2026 (UTC)[reply]

• Looks like it's WP:SNOWing to me. The proposal seems too flawed to get much support, and the discussion seems to be mostly people sniping at each other or re-arguing whether slow old devices are actually slow and old rather than trying to work out something better. We can leave it a while longer if people want to see if it turns around, but I'd be surprised if it runs all the way until March. Anomie⚔ 03:59, 1 February 2026 (UTC)[reply]
• I really don't like closing down discussions after two days. I don't want to feel like I have to check Wikipedia every day just so I don't miss some discussion that gets opened and closed while I am spending a weekend away from my computer. --Guy Macon (talk) 05:07, 1 February 2026 (UTC)[reply]
• B per Mathglot. sapphaline (talk) 10:11, 1 February 2026 (UTC)[reply]
• Well, lemme see. I like the close-it-yesterday aspect of A, but I hardly see the point of requesting that someone waste their time divining a consensus. I think nothing good can come of B, and I find the claims that productive discussion is still happening downright ridiculous, although I enjoy the humor of SuperPianoMan's idea. Perhaps we should just leave it open forever. --Tryptofish (talk) 19:42, 1 February 2026 (UTC)[reply]
• I note that this discussion was quite properly closed by Polygnotus yesterday. Unfortunately, it was reverted by PackMecEng ([6]). That strikes me as bureaucracy for bureaucracy's sake, without any benefit to anyone. --Tryptofish (talk) 20:53, 2 February 2026 (UTC)[reply]

  I completely agree with this. Could the closing summary have been better? Yes. Did reverting the closure benefit the project in any way? No. Thryduulf (talk) 21:19, 2 February 2026 (UTC)[reply]

  Now 171,836 bytes (28,523 words), a 32% increase since 03:49, 1 Feb. Mathglot (talk) 21:35, 2 February 2026 (UTC)[reply]

  And no further insights to show for it, other than a growing consensus that this has been a waste of time. --Tryptofish (talk) 21:39, 2 February 2026 (UTC)[reply]

C Take it behind the barn, close it out right, this has been a drain. LakesideMiners^{Come Talk To Me!} 00:46, 3 February 2026 (UTC)[reply]

I propose the following change to Wikipedia:Talk_page_guidelines#Archiving:

Current text

New text

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked.

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked. Any person can archive any inactive (2+ weeks without new messages) threads on any talk page; reverting these archivals is disruptive unless there's a valid reason to do so.

sapphaline (talk) 10:22, 1 February 2026 (UTC)[reply]

Interesting idea. Among concerns:

• 2 weeks may be a rather tight cutoff for a lot of folks here. I mean, I don't care if my page gets a drive-by archiving, and I'd be even grateful to some extent, but it seems that others will be pissed off big time. I think it's a month at a minimum, and probably preferably 3.
• does this concern user talk pages? If so:
  • what to do with users who insist that their talk page, or specific (list of) thread(s), are not be touched, even if such threads heavily tax your browser?
  • if the user has autoarchiving deployed, the archiving presumably must conform to the preferred choice of archiving by the user, correct? So numbered archives are continued, new monthly/yearly archives may be created, OK. What to do with theoretical topic-based archives?
  • what if the user says: I only want discussions to be blanked, I don't want no archive box or any fancy bots? Because after all the clause at Wikipedia:Talk page guidelines#Personal talk page cleanup that The length of user talk pages, and the need for archiving, is left up to each editor's own discretion. is unchanged by this proposal. They insist that they need no archiving and that any old thread be removed. But this proposal does not allow drive-by removal of threads from user talk pages, only archiving. Welcome to ANI I guess?
• how do you address some editors' complaints that empty talk pages are uninviting. It's not a hill I'm willing to die on, but I have a mild preference for non-empty pages if possible. And there are folks who seem to care about this a lot, at least if judged by the linked TPG discussion.

Szmenderowiecki (talk · contribs) 10:36, 1 February 2026 (UTC)[reply]

"does this concern user talk pages?" - "any talk page" = "any page intended for communication between editors" so yes. "what to do with users who insist that their talk page, or specific (list of) thread(s), are not be touched, even if such threads heavily tax your browser?" - such behavior is covered by "reverting these archivals is disruptive unless there's a valid reason to do so" and wp:own. "if the user has autoarchiving deployed, the archiving presumably must conform to the preferred choice of archiving by the user, correct?" - I think pages with auto-archiving can be excluded. "what if the user says: I only want discussions to be blanked, I don't want no archive box or any fancy bots?" - they should be blanked, then, not archived. "how do you address some editors' complaints that empty talk pages are uninviting" - can they explain why they are uninviting? sapphaline (talk) 10:45, 1 February 2026 (UTC)[reply]

So something like this:

Current text

New text

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked.

Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – see Help:Archiving a talk page. Apart from the exception described in § User talk pages, discussions should be archived, not blanked. Any person can archive or blank any inactive (3+ months without new messages) threads on any talk page, unless there's auto-archiving with a reasonable archiving period set up; reverting these archivals is disruptive unless there's a valid reason to do so.

sapphaline (talk) 10:54, 1 February 2026 (UTC)[reply]

This goes in a much better direction and makes sense. I applaud your effort.
The other two things that may be litigated are:

• what is a "reasonable" archiving period? "Reasonable" is a very vague word, and if we take real life, Americans with Disabilities Act lawsuits about "reasonable accommodations" is something of a cottage industry, judging by number of Supreme Court cases listed in the article. Because there are a couple of ways to define it:
  • "It keeps the page below a certain limit" (define the limit)
  • There is a maximum thread count so that users don't get lost in the ton of old threads nobody cares about (again, define the limit)
  • It keeps the page from substantially impacting user experience on their browser (on Chrome-based browsers, this could be the Inspect tool performance indicators). Judging by how the discussion is going, the next question is likely going to be "what device are you using? specs please", "what scripts you are running?" and the addition that "it works fine for me" or "it's not that big an inconvenience to complain about, I can load the page in X seconds".
  • some other criterion I can't think of right now?
• Any person can archive or blank conflicts with discussions should be archived, not blanked. I get the point. My proposal would be:
  Discussions should be archived, not blanked. Any person can archive any inactive (3+ months without new messages) threads on any talk page, unless there's auto-archiving with a reasonable (?) archiving period set up. On user talk pages, users may request that discussions be blanked instead of archiving - respect their wish. Reverting these actions is disruptive unless there's a valid reason to do so.

The reason I'm asking all these questions is to test the proposal against wikilawyering. Szmenderowiecki (talk · contribs) 11:27, 1 February 2026 (UTC)[reply]

• Oppose Editors should please mind their own business. Here's a fresh example. I get several regular newsletters posted to my talk page and I usually blank older ones so that only the latest appears. It would be better if the newsletters did this automatically but so it goes. Anyway, after recently clearing a batch of these, another editor restored them. An admin then turned up to revert their action because it appears that this user has a developing tendency to disrupt.
  The problem is that Wikipedia is the encyclopedia that anyone can edit and so our editors have a wide range of (in)competence. As they cannot be relied on to agree on such matters or have the necessary skills and understanding, they should not be encouraged to mess with other users' personal workspace. The Wikimedia software ought to have a foolproof interface maintained by its professional staff and, if there are technical problems with it, there ought to be a properly professional system for reporting and resolving them.
  Andrew🐉(talk) 13:50, 1 February 2026 (UTC)[reply]

  with other users' personal workspace
  The problem with arguments like these is that I don't think such thing exists on Wikipedia, at least if we consider WP:OWN (No one "owns" content (including articles or any page at Wikipedia and Wikipedia offers wide latitude to users to manage their user space as they see fit. Nevertheless, they are not personal homepages, and are not owned by the user. They are still part of Wikipedia and must serve its primary purposes; in particular, user talk pages make communication and collaboration among editors easier. These functions must not be hampered by ownership behavior.)
  A better descriptor would be "a communal workspace assigned to a user for issues relating to a user, with customarily large latitude at self-management" Szmenderowiecki (talk · contribs) 14:21, 1 February 2026 (UTC)[reply]

Oppose - There is no god-given right to talk to each and every other user on this website. Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user. Can't post an ANI notice on their page? Fine, then they don't get an ANI notice on their page. That's their problem. The notion of limiting all 250,000+ editors to some stupidly arbitrary and onerous rules, or letting busy-bodies mess with other people's talk pages, just because some editors don't want to wait for some talk pages to load, is ridiculous. Editors should not try to be so controlling of other editors. Levivich (talk) 14:28, 1 February 2026 (UTC)[reply]

"Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user" - Wikipedia isn't a social media website; you can't opt out of communication in a collaborative project. sapphaline (talk) 14:39, 1 February 2026 (UTC)[reply]

You don't need user talk pages to collaborate. We have article talk pages for collaboration. Levivich (talk) 14:41, 1 February 2026 (UTC)[reply]

Article talk pages are here solely for content dicussions. sapphaline (talk) 14:43, 1 February 2026 (UTC)[reply]

Yes. And template collaboration happens on template talk pages. And project wide collaboration happens on Wikipedia space talk pages. You don't need to talk to people on their user talk pages in order to collaborate with them. Levivich (talk) 14:46, 1 February 2026 (UTC)[reply]

"You don't need to talk to people on their user talk pages in order to collaborate with them" - yes, you need. Conduct issues exist. sapphaline (talk) 14:51, 1 February 2026 (UTC)[reply]

Yes conduct issues exist. You don't need user talk pages to resolve them. We have conduct noticeboards. If you didn't get a chance to discuss conduct issues with a user because their talk page was too long, that's too bad for them. It doesn't mean everybody else needs to follow new rules. Levivich (talk) 16:13, 1 February 2026 (UTC)[reply]

The conduct boards have a giant notice saying that you must leave a message on the person’s talk page and that a ping is not sufficient, so I don’t think that would be acceptable. ExtantRotations (talk) 23:35, 2 February 2026 (UTC)[reply]

From WP:USER: User pages are for communication and collaboration. ... However, pages in user space belong to the wider community. They are not a personal homepage, and do not belong to the user. They are part of Wikipedia, and exist to make collaboration among editors easier.
From WP:OWNTALK: User talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier. Szmenderowiecki (talk · contribs) 14:45, 1 February 2026 (UTC)[reply]

1) you're bludgeoning. You've posted these quotes already in this discussion. 2) you're not making any point here with these quotes. Levivich (talk) 14:46, 1 February 2026 (UTC)[reply]

No, I'm rebutting a point which is obviously wrong according to current policy. Policy says this is the literal purpose of these pages. You may want to use pages not according to their intended purpose but that's your personal preference. I'm going to use these pages according to what they are for and which use policy explicitly endorses. And I should not be punished for asking that these pages be used for the purpose specifically outlined in the policy.
I also don't believe that any argument to the effect of "let's allow users to force discussions in non-obvious forums because they don't want to do the housekeeping in the places where such discussion is intended to take place" complies within the general intent of Wikipedia policies and guidelines to promote discussion. Szmenderowiecki (talk · contribs) 14:53, 1 February 2026 (UTC)[reply]

None of our policies and guidelines say Every user talk page must load within a time frame acceptable to User:Szmenderowiecki. I checked EEng's user talk page (the longest on the website) on pingdom and it said 11 seconds load time. If that's too slow for you, too bad. It doesn't mean we need to have everybody else in the website limit their page sizes. Levivich (talk) 16:11, 1 February 2026 (UTC)[reply]

Another problem with this proposal is that sometimes threads "2+ weeks without new messages" should still remain on a talk page. Sometimes returning old threads from the archives is exactly the right thing to do. To require those to be archived, or to prevent them from being un-archived, mass collaboration harder, not easier. Rarely have I seen "solution in search of a problem" as clear as this. Levivich (talk) 14:44, 1 February 2026 (UTC)[reply]

There is no god-given right for any editors to have their user talk page be organized or contain any content that they wish it does. User talk pages exist for a purpose - to facilitate communication. Katzrockso (talk) 20:00, 2 February 2026 (UTC)[reply]

Oppose all per most people above. There should be (and indeed are) already guidelines about talk page size, but they should remain no more than guidelines because there are far too many variables for a hard and fast one-size-fits-all rule to be useful, even if one were desirable (per most people above). If you need to post on someone's talk page to notify them about something then state that, with a ping, in whichever discussion you want to notify them about. Either they will respond to the ping or someone who can post on their talk page will leave a message on your behalf. Thryduulf (talk) 14:38, 1 February 2026 (UTC)[reply]

Oppose all, with no small amount of annoyance. Seriously, if someone comes to my talk page and wants to blank it, that's OK, but if I revert even part of that, I'm violating policy? Now, I'm quite tempted to blank this VPP discussion, and would love it if I were empowered to do whatever pops into my mind, with nobody allowed to object (woo-hoo, I wanna be an autocrat!), but no, just no. --Tryptofish (talk) 19:37, 1 February 2026 (UTC)[reply]

Oppose this and all future attempts to give random trolls power over what I can post on my talk pages:

(I have no problem with anyone bringing up any problems they have with my talk page at ANI and asking an admin to deal with them. That's why they get paid the big bucks.)^{[Citation Needed]}

If your 386SX running Internet Explorer on Windows 3.0 doesn't allow you to post a required ANI notice just say that in your ANI post -- someone will notify me.

Nobody forced you to read my talk page. Unless, of course, you are strapped to a chair with your eyelids taped open in front of a monitor with a Wikipedia feed and with The Wikipedia Song blasting in the background.

If you are strapped to a chair, etc., then let me address this message to your captors: First of all, keep up the good work. Secondly, please take away their keyboard. --Guy Macon (talk) 19:44, 1 February 2026 (UTC)[reply]

• Oppose giving carte blanche to meddlers to meddle in other peoples' talk pages. —David Eppstein (talk) 18:36, 2 February 2026 (UTC)[reply]
• Oppose all. Phil Bridger (talk) 21:24, 2 February 2026 (UTC)[reply]
• Oppose meddling in other users' Talk pages per WP:OWNTALK: "The length of user talk pages, and the need for archiving, is left up to each editor's own discretion." Mathglot (talk) 21:29, 2 February 2026 (UTC)[reply]

Per WP:RFC#Reasons and ways to end RfCs, there are five ways an Rfc may end. One way, is a consensus among participants to end it (#2 in the list). However, that requires discussion and time, and given the size of this discussion already and the number of participants, that may be a significant effort in itself. However, there is a much quicker and easier path. The originator may decide to withdraw the Rfc unilaterally (per #1) if the outcome seems clear early. Normally, this would be carried out by the OP removing the {{Rfc}} tag at the top, however, this Rfc has no such tag.

So that we don't become bogged down in bureaucracy, I think I can speak for most participants here that a clear statement from the OP, such as, "I withdraw this Rfc because reason" would be sufficient to meet the requirements of method #1. Szmenderowiecki, you are in a unique position to be able to end the Rfc now. Would you be willing to do so? You are, of course, under no obligation whatever, and you don't even need to respond to this if you don't wish to. Cheers, Mathglot (talk) 23:00, 2 February 2026 (UTC)[reply]