Wikipedia:Village pump (policy)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.

• If you wish to propose something new that is not a policy or guideline, use Village pump (proposals). Alternatively, for drafting with a more focused group, consider starting the discussion on the talk page of a relevant WikiProject, the Manual of Style, or another relevant project page.
• For questions about how to apply existing policies or guidelines, refer to one of the many Wikipedia:Noticeboards.
• If you want to inquire about what the policy is on a specific topic, visit the Help desk or the Teahouse.
• This is not the place to resolve disputes regarding the implementation of policies. For such cases, consult Wikipedia:Dispute resolution.
• For proposals for new or amended speedy deletion criteria, use Wikipedia talk:Speedy deletion.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after 6 days of inactivity. To keep this page's size accessible, discussions with more than about 100 comments should be split to a separate page.

« Archives, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209

Upgrade MOS:ALBUM to an official guideline

I floated this at Village pump (proposals) here awhile back, and there was wide support for doing this (some editors said they felt it unofficially already was a guideline). But, it was noted that the essay, Wikipedia:WikiProject Albums/Album article style advice, needed some clean up and to be fleshed out in places. After multiple discussions, including some disputes and RfCs, I think the essay is finally in a place where there is an updated consensus and enough detail that it can be an official MOS style guideline. This is a formal presentation of the updated and discussed essay to see if there is support for making it formally part of Wikipedia's Manual of Style.--3family6 (Talk to me|See what I have done) 12:35, 26 January 2026 (UTC)

• I do support this. Camilasdandelions (✉️) 17:03, 26 January 2026 (UTC)
• Note the MOS:ALBUM shortcut has been nominated for deletion at Wikipedia:Redirects for discussion/Log/2026 January 21#MOS:ALBUM. I have linked this discussion there and suggested it should be procedurally closed pending the outcome of this discussion, but I don't know how that will be received (I'm not neutral with regards the redirect, but have no strong opinions regarding the essay/guideline). Thryduulf (talk) 17:18, 26 January 2026 (UTC)

  Link to RfD corrected. Thryduulf (talk) 21:53, 26 January 2026 (UTC)

  The WP:RFD discussion was procedurally closed pending the outcome of this RFC. —Myceteae‍🍄‍🟫 (talk) 21:39, 20 February 2026 (UTC)

• Oppose not really strong enough to carry the same weight as guidelines, and it lazily tries to give credits a free pass on being unsourced. SNUGGUMS (talk / edits) 17:58, 26 January 2026 (UTC)

  Where does it give a pass to credits being unsourced?--3family6 (Talk to me|See what I have done) 21:49, 26 January 2026 (UTC)

  Look under "Track listing", where someone added "This is generally assumed and does not need explicit citation in most cases". Even when albums are already released, we frankly shouldn't be so quick to presume that an unsourced track list lines up with actual credits. Adding liner notes or an iTunes/Amazon link would be better than nothing. You might be surprised how often others have dubiously tried to use the essay as an excuse to ignore the non-negotiable requirements of WP:Verifiability and WP:No original research. SNUGGUMS (talk / edits) 23:30, 26 January 2026 (UTC)

  WP:V doesn't require citations, and the essay reflects consensus. Are there cases of people inserting false information? I'm not opposed to modifying that text a bit, I just fail to see how it doesn't reflect consensus.--3family6 (Talk to me|See what I have done) 00:03, 27 January 2026 (UTC)

  On the contrary, WP:V opens its second paragraph with "Each fact or claim in an article must be verifiable." That doesn't give essays the right to make selective exceptions. I also haven't seen any consensus suggesting citations wouldn't be needed for facts. As for fabrications, I wouldn't be surprised if there have been, though cannot think of specific instances at the moment unless one counts vandalism. SNUGGUMS (talk / edits) 00:23, 27 January 2026 (UTC)

  The spirit of WP:V is that anybody should be able to check that the claimed facts are true. Picking up a record sleeve or CD inlay should be OK for that. That said, there are occasional discrepancies between the reality and what's actually written. Two examples: (i) Masque where the actual playing order matches a sticker on the sleeve but not the record labels; and (ii) Platinum, where the track "Sally", present on original copies, was replaced by "Into Wonderland" but without the sleeve being amended. --Redrose64 🌹 (talk) 14:07, 27 January 2026 (UTC)

  Even the most reliable of reliable sources only attains 99.973% reliability. Phil Bridger (talk) 14:32, 27 January 2026 (UTC)

  As long as articles make it clear that credit listings are taken from sleeves, inlays, or anything similar, I don't see an issue with using print sources for credits. If there are discrepancies, then it shouldn't be too difficult to find additional sources backing them up, perhaps even with some commenting on omissions. My qualm is enabling lazy-at-best mentalities of "just trust that I got these accurate" or "I don't need anything to back up my insertions of credits/personnel" when adding credits without any citation at all, even print ones. One or more refs (whether online or printed) helps show the listings aren't being pulled out of nowhere. SNUGGUMS (talk / edits) 17:46, 27 January 2026 (UTC)

  "Verifiable" is not the exact same thing as "has a citation". If something does seem questionable and is challenged, then it should have a citation. Regardless of what an essay or an MOS guideline says.--3family6 (Talk to me|See what I have done) 19:57, 27 January 2026 (UTC)

  "just trust that I got these accurate" or "I don't need anything to back up my insertions of credits/personnel" - is anyone doing this? Refusing to provide a source when asked?--3family6 (Talk to me|See what I have done) 19:59, 27 January 2026 (UTC)

  For a few samples showcasing the latter attitude by trying to use the essay as a cheap cop-out for not sourcing credits at all, have a look at these diffs. The choice to deliberately leave such sections with no sources is careless. SNUGGUMS (talk / edits) 23:03, 27 January 2026 (UTC)

  Thank you for those. Yes, those are WP:V violations and misusing the essay as well. I'm fine with changing the wording of the essay, if there's consensus for it.--3family6 (Talk to me|See what I have done) 13:38, 28 January 2026 (UTC)

  You're welcome, and for starters, I would recommend fully scrapping the sentence quoted above within the "Track listing" section even if this essay never becomes a guideline or a policy. We also shouldn't endorse any similar phrasing that people would attempt to use as an excuse for not implementing citations. It baffles me how anybody thought an essay could plausibly be used to overrule policies/guidelines. SNUGGUMS (talk / edits) 19:11, 28 January 2026 (UTC)

  As mentioned elsewhere, it is not overruling policy. Read WP:V. Content needs to be cited if the content is likely to be challenged, is BLP relevant or is a quotation. If there is consensus that primary sourcing (i.e. the album itself) is sufficient for verifying the track listings and that this is generally not likely to be challenged then no citations are required. This is the current consensus for plot summaries (which are sourced to the primary work and not cited because it's the subject of the article). You can make an argument that that citations should always be provided either because it's regularly wrong and therefore likely to be challenged but providing a citation isn't mandatory in all cases. Scribolt (talk) 10:26, 29 January 2026 (UTC)

  Personnell sections should have a citation if any of the people are living, then.--3family6 (Talk to me|See what I have done) 15:45, 29 January 2026 (UTC)

  That would be up for discussion, but wouldn't be a requirement imo. An article about an album isn't a BLP, and material about who did what during the production isn't necessarily contentious or controversial. There's certainly a higher possibility of getting the content wrong here compared to simply checking the track listing, so there might be added value in recommending in a guideline to make the extra effort and cite the content as a default, but if there isn't consensus to do this I wouldn't regard this it as being against any higher level policy. Scribolt (talk) 08:08, 2 February 2026 (UTC)

• Weak support I like the idea of this proposal and the page seems fleshed out enough to be a part of the MOS. 3family6, do you have a link to the discussion at VPR? TIA mdm.bla 23:01, 26 January 2026 (UTC)

  It actually was here at the policy page, I misremembered. That then was moved to WT:ALBUM. Here is the discussion. If you want me to link to the RfCs, I can do that.--3family6 (Talk to me|See what I have done) 23:59, 26 January 2026 (UTC)

  Thanks. The concerns brought up in that discussion seem to have been taken care of, and I don't share Snuggums' concerns w.r.t. WP:V issues. Increasing to a regular level of support. mdm.bla 04:52, 28 January 2026 (UTC)

• Support It may need further improvement, but making it formally a part of the MOS rather than a wikiproject sub-page will make that more rather less likely. Scribolt (talk) 14:33, 27 January 2026 (UTC)
• Support – I don't think its necessary to have to cite the release for information from the release, as anyone with access to the media can verify it themselves (à la MOS:PLOTSOURCE). That said, I wouldn't oppose making {{Cite AV media notes}} (or w/e source) a requirement for WP:PERSONNEL, as that's often not as easily as accessible with digital releases, but I would argue it's unnecessary for the track listings (as anyone with access to both the physical release and streaming services can easily verify for themselves). Nil🥝 04:18, 28 January 2026 (UTC)
• Comment – I'd like to hear more about the intended benefit of promoting WP:ALBUMSTYLE to a guideline. What problem would that solve? What isn't the page able to do as a WikiProject advice page that it could do as a guideline? If it were promoted to a guideline, where would it be moved to? Wikipedia:Manual of Style/Albums? There are already a few MOS subpages dealing with music, most of which, in my opinion, are better fits for explanatory essays or WikiProject advice pages. As a procedural note, there area few steps outlined at WP:PROPOSAL that should be followed for this discussion, including adding a formal RFC tag and posting a notice at Wikipedia talk:Manual of Style.--Trystan (talk) 13:50, 28 January 2026 (UTC)

  I've WP:BOLDly added an RFC tag and posted a message at WT:MOS. I would support the proposed page title that you've included, per the current shortcuts for the page MOS:ALBUM and MOS:ALBUMS. mdm.bla 16:31, 28 January 2026 (UTC)

  Thank you for that.--3family6 (Talk to me|See what I have done) 01:33, 29 January 2026 (UTC)

  isn't the page able to do as a WikiProject advice page that it could do as a guideline? In practice, I'm not sure, as it's de facto treated as an MOS already (for example, the short name link WP:MOS). This would formalize what is effectively the status quo. It would give more weight, though of course it's still a guideline to which IAR applies.--3family6 (Talk to me|See what I have done) 01:35, 29 January 2026 (UTC)

• Oppose per SNUGGUMS. Clearly the advice not to source credits doesn't fit with wider policies and guidelines. And more broadly, per WP:CREEP, having too many guidelines of this nature which are crafted by niche WikiProjects and may not be widely watched, is not beneficial. The overall MOS has almost all the guidance you need, and any further details should be worked out by consensus at individual articles, not by a wide-ranging set of arbitrary guidelines that aren't being widely vetted.  — Amakuru (talk) 14:58, 28 January 2026 (UTC)

  It seems that SNUGGUMS' understanding of policies and guidelines on this specific point is in the minority. As to WP:CREEP, that's fair, but should we then rescind/downgrade other MOS?--3family6 (Talk to me|See what I have done) 00:02, 4 February 2026 (UTC)

• Comment. Generally, the MOS applies to all topics. Are there any other examples of subject-specific guides within MOS, or would this be a scope expansion? pburka (talk) 16:54, 28 January 2026 (UTC)

  Template:Manual of Style lists a number of subject-specific MOS subpages by topic area; this page is especially comparable to MOS:TV and MOS:VG. mdm.bla 17:52, 28 January 2026 (UTC)

  Amakuru, see this--3family6 (Talk to me|See what I have done) 00:03, 4 February 2026 (UTC)

  My opinion would be that those things shouldn't be designated as guidelines either. Without assuming any bad faith - editors are of course writing down that they think is best practice - but these often reflect a WP:LOCALCONSENSUS, being usually formulated by small groups of editors rather than the community a a whole, and the things asked for may not be required by the wider MOS or necessarily appropriate for every article in the space. An example was a road article I wrote where I was told it couldn't become an FA due to not complying with MOS:RJL, something which is only really sensible for certain types of road. Having general guidance in essay form is fine, but it is much better for such questions to be handled by consensus and applying the sitewide MOS than by a one-size-fits-all guidelines written without a lot of the community being involved. Let's not make this situation worse by adding another one into the mix. Cheers  — Amakuru (talk) 11:19, 4 February 2026 (UTC)

  There's a reason I'm proposing this here, as opposed to just the Albums WikiProject, and it's advertised at the main MOS page. This shouldn't be simply local consensus. Regarding your example, I personally would've opened an RfC about that particular guideline.--3family6 (Talk to me|See what I have done) 13:49, 4 February 2026 (UTC)

• Support. This discussion has stagnated a little, but as a participant in the original RfD I am now inclined towards promoting this to the MOS having seen how valuable it is for its area of focus. — An anonymous username, not my real name 22:45, 11 February 2026 (UTC)
• Oppose. I appreciate the effort, and I weighed in a couple of times during previous discussions, but there are still too many issues for me to support. The project, unlike any other WP one, continues to fetishize primary source information, with editors often trying to reproduce every piece of album packaging credit, rather than worrying about what secondary sources have to say. The alternate track listings are still out of control, as are long personnel lists of non-notable musicians, producers, songwriters, etc. The vast majority of the project uses one track listing style, but a vocal (extremely tiny) minority of editors want to keep choices, which leads to needless edit warring. Genres are still an issue---if "hair metal" or "classic rock" showed up, despite being the subjects of thousands of reliable articles, books, and magazines, some editors may start having embolisms. Cheers. Caro7200 (talk) 12:20, 19 February 2026 (UTC)

Caro7200 I'm trying to understand your concern here. Is your concern that there isn't consensus on some issues because the ongoing disputes demonstrate it so?--3family6 (Talk to me|See what I have done) 10:30, 27 February 2026 (UTC)

Yeah, in part. One purpose of a formal standard is to avoid shifting so much to the "take it to the talk page" route. We should be more precise and clear with our language, rather than, for example, something like "Whether or not to include bonus tracks and alternative track listings should be evaluated on a case-by-case basis." I do agree with you that credits found on packaging don't require citations; a New York Times reporter isn't contacting Parkwood/Columbia to verify the information found on the copy of Cowboy Carter that they're holding in their hand. Additionally, we could use tougher language in regard to chronology and exact release dates, which continue to be hugely unsourced; this is too often wrongly regarded as a Wikipedia:You don't need to cite that the sky is blue thing. And our consistent enforcement is part of adopting a formal standard. Too many IP and "new" editors are switching out track listing styles to our most popular one, for example, with the reasoning that the others are "outdated". Caro7200 (talk) 15:26, 1 March 2026 (UTC)

Wouldn't these issues be all the more reason to have a more formal standard? The track listing issue finally reached a consensus, and the personnel issue I believe reached one last year. Genres have always been an issue, despite there being long-standing consensus, because some editors ignore consensus.--3family6 (Talk to me|See what I have done) 13:45, 27 February 2026 (UTC)

• Oppose, largely in agreement with Caro7200 and SNUGGUMS. I'm also sympathetic to Amakuru's WP:CREEP and related concerns. I'm on the fence as to whether we should have a dedicated albums MOS at all. At a minimum, the concerns regarding citations and genres need to be addressed. If the current wording reflects the consensus of the WikiProject then we're at an impasse, but from the discussion here it appears some editors are open to further rewording. It remains unclear what the benefit is of promoting this—What problem will this solve? What's not working now that would be improved? It sounds like some (many?) editors active in this space treat this as more or less a guideline currently. That there are ongoing disputes and edit wars indicates either a lack of consensus or a minority of editors ignoring consensus. —Myceteae‍🍄‍🟫 (talk) 22:14, 20 February 2026 (UTC)

  On the track listing issue, the RFC for that finally closed recently so there is actually a community consensus that can be pointed to.--3family6 (Talk to me|See what I have done) 10:34, 27 February 2026 (UTC)

  Generally, apart from some issues that have been hammered out over the past year, it's editors ignoring consensus.--3family6 (Talk to me|See what I have done) 13:43, 27 February 2026 (UTC)

• Support. Having read this discussion, I'm not of the opinion that having this as a formal guideline would be of benefit. Thryduulf (talk) 14:19, 27 February 2026 (UTC)

  @Thryduulf: Unless I'm reading this wrong (entirely possible), your reasoning seems to contradict your !vote. Did you intend to Oppose, or did you intend to say "I'm of the opinion"? DrOrinScrivello (talk) 14:49, 27 February 2026 (UTC)

  Thanks for the headsup, the "not" is erroneous (probably left over when I was going to word my comment differently). Thryduulf (talk) 18:34, 27 February 2026 (UTC)

• Oppose. Just caught wind of this after doing an album page edit and referring to guidelines which apparently no longer exist. I'm mostly with Caro7200 and Snuggums. IMHO there is still too much wiggle room in certain areas, particularly WP:ALTTRACKLISTING, which is now so vague that it is basically meaningless.—The Keymaster (talk) 12:25, 2 March 2026 (UTC)

Introduce maximum page size and mandatory archiving for pages intended for user communication (accessibility)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

(non-admin closure) WP:BOLDly closing this RFC early per snowball clause

Polling is not a substitute for discussion, but examining the !votes is a good place to start divining consensus.Currently, there are 38 bullet points in the survey, of which 27 are !votes opposing any one of the seven proposals in this RFC. There are an additional 9 bullet points (some of which are unbulleted) in the proposal by Sapphaline, of which eight are in total opposition to either their proposal or the original proposal. Of the 11 remaining bullet points, two are discounted for not being !votes. The 9 remaining bullet points are in various levels of support for the original proposal, from supporting all of the points (2), to supporting them all except for one or two (3), or only supporting a couple (4).

Some opposes believe that there may be a discussion worth having on the topic of archiving talk pages, but many do not believe a one-sized fits all solution will work. On the other hand, supporters of the proposal have accessibility concerns about large talk pages. Editors on both sides believe that the structure of this RFC has prevented any productive outcome for this discussion. I would encourage continued discussion on this topic, as the accessibility concerns are a problem worth solving, but the issues will not be solved in this discussion. There is consensus against this proposal, but not against the existence of an underlying issue. Mdm.Bla (talk) 15:46, 3 February 2026 (UTC)

I have opened a discussion at Wikipedia:Village pump (idea lab)#Automated talk-page archiving, page splitting, and accessibility to continue talking about the accessibility issues of large talk pages. Please do not relitigate this RFC there. Mdm.Bla (talk) 17:06, 3 February 2026 (UTC)

---

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:

1. Establish a minimum number of 10 threads on pages, except on user talk pages
2. Establish a maximum size of pages (about 200 KB) and page archives (about 150 KB).
3. Mandate some sort of automatic archiving mechanism for all pages, except for user talk pages; that archiving mechanism will by default do all the enforcement of the maximum size rules on non-user talk pages.
4. Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval
5. Limit discretion of users to manage their assigned talk page to comply with maximum size guidelines, but leave the choice of the preferred way to comply with the guideline to the users; no other part of user discretion is disturbed
6. Introduce an enforcement mechanism for users failing to abide by the accessibility guideline (max size)
7. Force changes to the codes of archive bots in such a way that any input value above the maximum permitted/below the minimum permitted thresholds will default to the threshold values.

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)

Changes (talk pages)

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.

Survey (talk pages)

• Yes to all as proposer. Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)
• 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)

  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)

  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)

• 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)
• 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)

  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)

  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)

• 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)

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

• 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)

  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)

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

  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)

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

• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

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

• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• 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)
• 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)
• 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)
• 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)
• support b, good compromise between a maximum size and accessibility. ltbdl (love) 00:49, 30 January 2026 (UTC)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

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

  @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)

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

  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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

• 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)

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

• Oppose absurd talk-page bureaucracy. —David Eppstein (talk) 18:34, 2 February 2026 (UTC)
• 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)

Counterproposal

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)

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)

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)

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)

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)

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)

Counter-Counterproposal:

Common snipe ^[a]

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)

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)

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)

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)

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)

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

• 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)
• 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)

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

• 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)
• 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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

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

  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)

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

  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)

Discussion (talk pages)

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)

@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)

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)

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

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

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

@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)

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

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)

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)

@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)

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)

@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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

@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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• 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)

  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)

• 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)

  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)

  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)

  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)

  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)

  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)

• 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)

  ~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)

  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)

  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)

  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)

• 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)

    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)

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)

@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)

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)

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

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)

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)

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)

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)

"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)

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)

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

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)

@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)

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)

@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)

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)

@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)

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)

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)

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)

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)

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)

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)

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)

@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)

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)

@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)

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)

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-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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

Continue, close, or what

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)

• 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)
• Mathglot just invented the meta-RfC! I choose option E. Something productive. Polygnotus (talk) 03:53, 1 February 2026 (UTC)
• C: Keep this discussion going until it reaches one million bytes of discussion. But in reality, B, as there is still legitimate discussion happening. SuperPianoMan9167 (talk) 03:54, 1 February 2026 (UTC)

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

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

• 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)
• 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)
• B per Mathglot. sapphaline (talk) 10:11, 1 February 2026 (UTC)
• 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)
• 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)

  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)

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

  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)

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)

Proposal #2

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)

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)

"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)

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)

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)

• 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)

  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)

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)

"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)

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

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

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)

"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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• Oppose giving carte blanche to meddlers to meddle in other peoples' talk pages. —David Eppstein (talk) 18:36, 2 February 2026 (UTC)
• Oppose all. Phil Bridger (talk) 21:24, 2 February 2026 (UTC)
• 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)

Reasons and ways to end RfCs

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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Notability" really is a terrible name.

I've heard it discussed around a fair amount, and I'm sure it's one of those 'perennial proposals' that the veterans here are going to roll their eyes and say "ugh, somebody's bringing THIS up again," but I do think it bears saying. Notability is an awful descriptor for what we're actually looking for, which is presence in sources. That's 'notedness' if anything, not 'notability', and the inevitable result is that every time you tell someone you can't accept their autobiography/company's article/article about their favourite media thing because it's 'not notable,' they get their haunches up and go on a tirade about how many awards they/the thing have won and how many cool things they/the thing have done, etc. Pretty much every mention of something being notable or not notable has to be accompanied by a mandatory disclaimer of what notability means here and how it doesn't mean what they think it does. It's a thought particularly spurred on by my deletion nomination of the article Deaglán de Bréadún, which led the man himself to post a response essentially calling me a nasty person for daring to imply that him and his career aren't notable... which, of course, is not actually what we mean, despite literally saying the words "you aren't notable enough for a Wikipedia article"

So, the obvious question is; what would we call it instead? I've heard the term "Criteria for inclusion" mentioned, which I think would be a graceful solution, since you can explain that the criteria for inclusion is presence in sources etc without ever having to use the scary word 'notability.' Whatever alternative option is presented, I do think it is seriously high time that Wikipedia take the big step of retiring the term 'notability' Athanelar (talk) 00:39, 20 February 2026 (UTC)

I agree with you. Notability is a dumb name. However, there's never going to be a consensus to change it. voorts (talk/contributions) 00:55, 20 February 2026 (UTC)

And then, what would we call all the lists of "notable" people/residents/alumni/etc.? "People/residents/alumni/etc. who meet the criteria for inclusion"? Donald Albury 01:11, 20 February 2026 (UTC)

I think you could probably still keep those; the definition there would logically run in the opposite direction, they are notable because they meet the criteria for inclusion. It's not an ideal solution, but obviously cuts down on some of the logistical challenge. Athanelar (talk) 01:41, 20 February 2026 (UTC)

Renaming notability has been an WP:PEREN issue, repeated discussed without finding any term that has a benefit over "notability" that would not be disruptive (how many P&G depend on it) but would be more descriptive. And no, "presence in sources" is an indicator of notability, but not how notability is defined. Masem (t) 01:16, 20 February 2026 (UTC)

It is undoubtedly true that it would be a lot of work changing the nomenclature all over the project if we got rid of 'notability,' but I don't think "It'd be a lot of work" is a compelling counterargument. There would no doubt be a long transitional period where lingering remains of 'notability' were still all over the place; but that doesn't have to be an issue, it's not like the change has to happen overnight. We could just say "from today on, the term 'notability' is deprecated and we prefer this new term instead" and people can change mentions of it as and when they catch it. Just today I heard about the NSPORTS 2022 RfC where the definition of notability for athletes was radically changed; that too would've had far-reaching implications on the project, but that didn't stop people from doing it just because it was a lot of work ahead of them to clean up the now non-notable athlete articles everywhere. Athanelar (talk) 01:42, 20 February 2026 (UTC)

The NSPORT change did not radically change what notability was, just eliminated a very poor presumption of notability (playing one professional game) that had led to thousands of permastubs on athletes that was a constant problem at ANI.

We've been through what the downstream impacts of changing the term notability to something else as part of past discussions (because this being PEREN) and its not as simple "from now on it will be known as..." "notability" is embedded in WP culture and in coverage of how WP works, so it would be a massive shift, so any new terms must carry a lot of massive benefit to make it worth the effort to make the change. And dozens of suggestions have been made and failed to show this. Masem (t) 04:47, 20 February 2026 (UTC)

• My 9-year-old essay's time has finally come! WP:Noted not notable. (Note: It's a very, very short essay, admittedly.) EEng 01:58, 20 February 2026 (UTC)

  We could put this in big letters on the notability page and all the spin-off pages like WP:42. Thebiguglyalien (talk) 🛸 04:24, 20 February 2026 (UTC)

  This is also a fairly elegant solution, hut unfortunately relies on people actually clicking the link and then actually reading the words on their screen. The 'headline effect' is real when it comes to WP links. Athanelar (talk) 09:23, 20 February 2026 (UTC)

  Nice essay, EEng. I especially like how the "nutshell" explanation is nearly twice as long as the essay itself  ;) —Fortuna, imperatrix 19:24, 20 February 2026 (UTC)

  [7] EEng 20:16, 21 February 2026 (UTC)

• For reference, the last big discussion on this topic that I know of is Wikipedia talk:Notability/Archive 84 § RfC on change of name, from April 2025. isaacl (talk) 02:07, 20 February 2026 (UTC)

  Much appreciated. Starting to read through some of that, I think 'eligibility' is quite a strong contender. It's an easily-understood English word already, which perfectly encapsulates the concept being described, and also would actually allow us to broaden our definition in some useful ways (because eligibility is a catch-all term that could include not only the presence of positive indicators like strong sources, but also the absence of negative indicators like WP:NOT or criteria for speedy deletion.) A subject which is 'eligible' is one that is both suitable for inclusion and unsuitable for deletion, which 'notability' does not currently encapsulate. Athanelar (talk) 02:15, 20 February 2026 (UTC)

  No, eligibility is a terrible idea, because it implies a brightline yes/no answer. Notability is a greyscale, its why notability is based on presumptions and not a hardline test.

  The only real issue with notability is for editors encountering the term for the first time, and coming to learn that real-world definition of notability is not exactly the same as WP's definition of notability, but reading the P&G should quickly resolve that. Masem (t) 04:53, 20 February 2026 (UTC)

The only way to get the name changed? would be to propose only one alternative. GoodDay (talk) 02:10, 20 February 2026 (UTC)

I disagree, the bugbear for a lot of people seems to be whether we'll get consensus that changing the name is worth the effort. I think people first have to be disgruntled about the old name to be resolved to change it before we worry what the new name ought to be. Athanelar (talk) 02:11, 20 February 2026 (UTC)

Do you have a proposed name? GoodDay (talk) 14:37, 20 February 2026 (UTC)

No! God please no! This is a perennial issue based primarily on WP:IDONTLIKEIT. It’s too late and too entrenched to change and someone is just going to bitch about how dumb “eligibility” is down the line. A better proposal would be outright banning perennial proposals and requiring consensus to unban them before allowing them to be discussed again, since that would require more extraordinary reasoning than “I know this has been talked to death, but just me out, I swear”. Dronebogus (talk) 02:43, 20 February 2026 (UTC)

While I agree that changing it has a less-than-ideal cost-reward, this post (and the others before it) explain legitimate downsides to the current name besides preference. Also, a discussion to unban a perennial proposal would look almost identical to the proposal itself. Thebiguglyalien (talk) 🛸 04:28, 20 February 2026 (UTC)

A discussion to unban a perennial proposal would look almost identical to the proposal itself. Maybe so, but it would force proposers to go through the process twice, which would discourage most proposers from doing it at all and save everyone a lot of time. Additionally, it wouldn’t necessarily always result in the aforementioned situation— if a proposal was banned because it was a hot-button issue now, it might be uncontroversially removed from the list 10 years later after things cool off, without actually endorsing it. It would be sort of like the MediaWiki:Bad image list or a gold lock for proposals. Dronebogus (talk) 09:51, 20 February 2026 (UTC)

I totally agree with you and I was disappointed that there wasn't consensus to change the name in the aforementioned April 2025 RfC. But given the outcome of said RfC, I struggle to see the point of rehashing the discussion so soon as it's very unlikely that there will be a different outcome. Perhaps give it a year or two.  novov talk edits 05:24, 20 February 2026 (UTC)

• Coverage perhaps? Or renown? Or just noted ... I doubt it'll ever actually change though. EvergreenFir (talk) 05:42, 20 February 2026 (UTC)

  Coverage is a distinction without a difference. Renown is far more pretentious than notability. Noted is barely even a change and couldn’t be used rationally in a sentence. Dronebogus (talk) 09:53, 20 February 2026 (UTC)

• WP:Eligibility was recently suggested by Wikipedia expert Bill Beutler. SmokeyJoe (talk) 06:00, 20 February 2026 (UTC)

  Eligibility is the rename option that sucks the least, since it most accurately reflects what “notability” actually means. But “notability” still at least puts a vague idea in people’s heads (namely, is this thing/person significant in some way?) whereas “eligibility” could mean pretty much anything and could actually put a worse idea in people’s heads (namely, eligibility is whatever somebody says it is, or is some arcane ruleset known only to insiders that isn’t easily summarized). Dronebogus (talk) 09:59, 20 February 2026 (UTC)

  I still think "notedness" would be better than "eligibility", as "eligibility" seems like it should include non-WP:N things such as WP:NOT and WP:BLP. Anomie⚔ 13:50, 20 February 2026 (UTC)

  I don't see that as a negative. We are, ultimately, looking for a term that describes "eligible to be included on Wikipedia." In fact, some of the AfC decline notices literally use "your references do not demonstrate that this subject qualifies for a Wikipedia article" as a piped link to 'notability' anyway. If anything, having a more comprehensive term would be an advantage, since then you don't run into the tricky situations of 'well, we TECHNICALLY have enough information to presume this person is notable, but there's still not enough coverage to substantiate an article about them' amd so on.

  Eligibility includes what we now define as notability, but way more succinctly communicates the point of whether or not something should have an article. Athanelar (talk) 14:02, 20 February 2026 (UTC)

  Having an all-encompassing term actually referring to just one facet seems like it would make it harder to discuss that facet versus other facets. "Ok, that meets WP:ELIGIBILITY, but it's still not eligible because it doesn't meet WP:BLP1E." "Wat?" Anomie⚔ 00:01, 21 February 2026 (UTC)

  Exactly. Dronebogus (talk) 14:33, 21 February 2026 (UTC)

  “notability” still at least puts a vague idea in people’s heads: but I think that’s the problem with the term. People don’t realize they are encountering a jargon term and substitute their own meaning. I’d argue that “eligibility” is better because there’s more precedent that contextual criteria will define eligibility for a particular thing; it might cue people that they need Wikipedia-specific information. (I’d almost want to try a complete neologism that people would know they don’t know the meaning of, something like “wikifiability” or “AAOEW” (Article Allowed On En-Wiki) that they’d know they don’t know.) ~ le 🌸 valyn (talk) 07:35, 21 February 2026 (UTC)

  Anomie said it best with the “wiki-eligibility is not dictionary definition eligibility” example. Notability still hits the general vicinity of the right idea; eligibility doesn’t and has the potential to be more confusing. As for a neologism, I don’t support that either because (on top of being a solution in search of a problem like all these replacement suggestions) it just adds MORE incomprehensible jargon to Wikipedia— which is what this proposal is supposedly trying to cut back on. Dronebogus (talk) 14:39, 21 February 2026 (UTC)

  I feel like you might have misunderstood my argument. When it comes to the one-word name for this concept, I contend that "trying to cut back on" jargon is counterproductive; any one-word name for this mess of concepts is inherently jargon. Accordingly, I think there's no point trying to change to something "clearer", but it could possibly be helpful to change to something less "clear", because it could make the term into a "known unknown" instead of "something you know that isn't so". Personally, when I want to avoid jargon with newbies, I write out a whole explanatory phrase instead (eg "our criteria for a book to have an article"); I think that's the only approach that can actually effectively cut down on jargon. ~ le 🌸 valyn (talk) 02:42, 23 February 2026 (UTC)

• Notability was never a good choice of name, but we've stuck with it because of the cost of changing; it's a QWERTY vs DVORAK problem. Personally I'd quite like to call it "Citability".—S Marshall T/C 09:45, 20 February 2026 (UTC)

  I think the 'cost of changing' would quickly be outweighed if you tallied up the editor-hours required and compared it to the editor-hours that have been spent and will continue to be spent in perpetuity explaining to disgruntled would-be article creators why appearing on a list of the Top 100 Best Things doesn't confer notability. Athanelar (talk) 13:11, 20 February 2026 (UTC)

  Don't misunderstand: I personally would support most reasonable alternative names because "notability" is still (after all these years) a misleading, dramagenic, and generally awful choice of words. But there's a non-zero cost of changing and a lot of neophobia to overcome here.—S Marshall T/C 14:40, 20 February 2026 (UTC)

  Is “dramagenic” a word? Dronebogus (talk) 14:40, 21 February 2026 (UTC)

  As I discussed last April, personally I encourage everyone to focus on providing more complete explanations on the standards for having an article rather than just linking to a jargon term. The key obstacle is that the community has to want to reduce its use of jargon. isaacl (talk) 16:51, 20 February 2026 (UTC)

• It is highly unlikely that the community is going to rename "Notability", this being as noted a perennial proposal that gets enmeshed in the long and complicated history and complicated current understanding of the concept of 'notability' on en.wiki. However, a creative smaller change probably worth exploring might be to create an alternative name for WP:GNG that somehow does not include the "N". GNG is the aspect of notability that best describes "presence in sources", it is the least likely aspect of notability to get enmeshed in notability politics. I don't have a perfect suggestion offhand, but creating an alternative name for GNG is a smaller task then renaming all of notability, and would capture much of the practical benefit of a full notability rename even if that full rename never happens. CMD (talk) 14:11, 20 February 2026 (UTC)
• The community's inertia is such that a proposal to change this isn't a good use of my time or anyone else's. But I agree, and if I had my way I would want the policy not to be a near-synonym of "significant". The practical consequence I see most often is the eliding of "should we as an ambitious global encyclopedia cover this in principle" and "can we as an encyclopedia that cares about verifiability write an article about this in practice". I could go on at length, but a more prosaic name may help us a good bit, perhaps something as plain as "standard for inclusion". Vanamonde93 (talk) 17:47, 20 February 2026 (UTC)

  “Standard(s) for inclusion” is by FAR the best proposed option so far; but there are multiple “standards for inclusion” beyond notability. Dronebogus (talk) 14:46, 21 February 2026 (UTC)

  @Dronebogus: This is precisely the distinction that I want to make. To my mind there's not multiple standards for inclusion, because in our most overarching policy language, "notability" is used as a synonym for standards of inclusion. We do have multiple was of showing notability beyond GNG/SIGCOV. And the frequent use of "notable" to mean "has SIGCOV" therefore causes considerable confusion as well. Vanamonde93 (talk) 20:18, 21 February 2026 (UTC)

  "Notability" is one commonly discussed standard, but there are others such as WP:NOT and WP:BLP. Anomie⚔ 20:52, 21 February 2026 (UTC)

  @Anomie: I see those as standards for exclusion, which may require the removal of notable topics, but will never compel the inclusion of non-notable topics. Vanamonde93 (talk) 01:49, 22 February 2026 (UTC)

  Two sides of the same coin. You could just as well say that WP:N will never compel the inclusion of topics that go against WP:BLP, and so on. It all goes together to determine what's included, i.e. multiple criteria. Anomie⚔ 03:20, 22 February 2026 (UTC)

• Wikipedia jargon. We use a word with a meaning that differs from its normal English meaning. Any other word would therefore have the same issue unless we created an entirely new word like "cituated". My personal favourite is "living persons", which includes dead persons. Hawkeye7 (discuss) 18:42, 20 February 2026 (UTC)

  I don't think that this is necessarily true; "eligibility" "suitability" and "criteria for inclusion" which have all been mentioned all transparently mean what we would want them to mean; the bar a subject has to pass to get an article. This isn't an unsolvable dilemma, it's just hard work. Athanelar (talk) 19:33, 20 February 2026 (UTC)

  "Criteria for inclusion" leads us straight to one of the most common points of confusion: inclusion of an article in the encyclopaedia versus inclusion of details within an article. The criteria applied to the creation or retention of an article are not the same as those applied to the content inside it. Hawkeye7 (discuss) 20:36, 20 February 2026 (UTC)

• "Notability" really is a terrible name. Yes, you are correct. Toadspike [Talk] 18:49, 20 February 2026 (UTC)
• Yes, it is really a terrible name. The fixation that it needs to be one word is also bizarre. Neutral Point of View is not one word, Original Research is not one word, Biography of Living Persons is not one word, Article Title is not one word, etc.: so, Article Criteria, or some such. 'On Wikipedia, Article Criteria is a test . . .'; It meets the AC; it does not meet WP:AC; and done. Alanscottwalker (talk) 01:44, 21 February 2026 (UTC)

• Comment: Unpopular opinion I guess but I like the word "notability," especially when paired with "Wikipedia:Verifiability." Notability gives a lot of wiggle room but suggests there is some minimum for inclusion, and we can adjust what that is.

GeogSage ^{(⚔Chat?⚔)} 02:23, 21 February 2026 (UTC)

It’s not an unpopular opinion. I’m pretty sure the silent majority either likes it or has no strong opinion on it. Otherwise we would have changed it by now. Dronebogus (talk) 14:50, 21 February 2026 (UTC)

• I think some people are confusing the aim and the criteria. We really do want to write articles on topics that are notable according to its everyday meaning (that's the aim), but to achieve that in practice we have to make guidelines for notability that editors are able to follow and agree with each other about (that's the criteria). So my opinion is that "notability" is actually the best of the options mentioned so far in this discussion. "Eligibility" is way too vague (neither an aim nor a criterion) and "citeability" is just wrong (that would refer to sources, not topics). The word that has annoyed me the most, for the past 20+ years, is "verifiability", which in wikispeak means something entirely different from its meaning in plain English. In plain English, something is verifiable if its truth can be confirmed, which is why the ancient slogan "verifiability, not truth" is my nomination for the worst own-goal in Wikipedia history. Zero^talk 10:35, 21 February 2026 (UTC)

  In defense of verifiability, it's purely a question of which frame of reference you're using. Sure, in everyday speech it usually means verifiable [against objective truth] but it's not a stretch or corruption of the meaning that on Wikipedia it means verifiable [against a source text]. The whole point of 'verifiability, not truth' is to clarify that the thing we're verifying against is not objective truth, merely source->text integrity. Athanelar (talk) 10:48, 21 February 2026 (UTC)

  No, that was not where "verifiability, not truth" came from (I was here when it was adopted). The "not truth" part refers to "no original research". The idea is that we use what reliable sources say is true and not what we personally believe is true. It isn't a reference to objective truth. The problem with the slogan is that it was commonly taken to mean that Wikipedia doesn't care about getting the facts right, and this misunderstanding got "out there" to our detriment. And we threw it at newcomers before they had a chance to grasp that "verifiability" didn't mean what they thought it meant. Zero^talk 11:40, 21 February 2026 (UTC)

  When it comes to "verifiability" I view it as "is the notability verifiable." Something can be true, but not notable. There is a lot of stuff about me floating on the internet, my existence is verifiable, however none of it meets the criteria for notability, my notability is not verifiable. GeogSage ^{(⚔Chat?⚔)} 20:01, 23 February 2026 (UTC)

I would probably call it "sourceability" which is somewhat more accurate. However, as said before it's one of these entrenched terms that are hard to change. Jo-Jo Eumerus (talk) 14:25, 21 February 2026 (UTC)

What name is being proposed, to change "Notability"? GoodDay (talk) 14:37, 21 February 2026 (UTC)

Nothing currently; I'm not trying to make a proposal, just to discuss the topic. There's no point in proposing a candidate if nobody thinks it should be changed to begin with. Athanelar (talk) 14:42, 21 February 2026 (UTC)

No-one can decide. And most likely no decision will be made. This is such an obvious waste of time I don’t really know why I, or any of the many high-profile editors here, dignifying it with a response beyond “WP:PERENNIAL” Dronebogus (talk) 14:43, 21 February 2026 (UTC)

I note WP:PERENNIAL doesn't actually have this topic listed (yet). Anomie⚔ 20:57, 21 February 2026 (UTC)

"Notability" is fine. It means what subject can be noted on Wikipedia. I don't see a glaring problem with it. Joe vom Titan (talk) 14:46, 21 February 2026 (UTC)

The glaring problem is that that's an extremely unintuitive and niche use of that word, which usually means "important" or "significant" Athanelar (talk) 16:34, 21 February 2026 (UTC)

That's what "notable" means, while "notability" reflects how much someone is likely to be notable, which matches the intent of what WP's notability does. Masem (t) 16:47, 21 February 2026 (UTC)

But "importance" is subjective (my wife is important to me, the road I take to work is important to me, the band my friend started when he was 15 is important to him; none of them are notable in the Wikipedia sense). "Notability" (or at least the GNG) aims to be an objective standard that is either met or not and has little to do with what most people think of as "importance". HJ Mitchell | Penny for your thoughts? 20:49, 21 February 2026 (UTC)

Also worth adding that we do "note" unnotable things on Wikipedia, just within articles rather than as standalone topics. CMD (talk) 04:18, 22 February 2026 (UTC)

Its far from an objective standard, which is why notability is a rebuttable presumption. Show that the topic is given in-depth coverage from at least a few independent, reliable sources (generally being secondary sources), and we'll presume that the topic can merit a full article. But there's so much variability in what qualifies as in-depth coverage, how many and what kind of sources, etc. that its far to call the test solely objective. Otherwise, we'd not have any problem at AFD with deletion.

But we do associate being notable as if the topic was important enough to independent authors to cover in-depth, that is, is the topic demonstrated the quality of being notable based on sourcing. Masem (t) 04:29, 22 February 2026 (UTC)

When you read that notability is necessary for inclusion on Wikipedia how is it not glaringly obvious that it is Wikipedia that sets the standards for what is notable?--User:Khajidha (talk) (contributions) 18:09, 22 February 2026 (UTC)

While we’re here, why don’t we look at all the other less-than-ideal names used for rules on Wikipedia? WP:NPOV (which isn’t neutral) WP:IAR (don’t actually do this) WP:DELETION (pages aren’t deleted). I could probably find lots of examples. Wikipedia is just like any hobbyist subculture in that it has a lot of weird jargon that doesn’t necessarily mean what the dictionary and common sense say it means. “Fixing” that will just create more problems as now both newbies AND veteran editors are confused by the weird new terminology. On top of that Newbies still won’t understand what it’s meant to convey, veterans will just keep using the same terminology they always used, and eventually it will just get reverted back with the same unnecessary cost as changing it. Dronebogus (talk) 15:00, 21 February 2026 (UTC)

• Notability is a terrible name because it's easily conflated with "importance", which is subjective—everything is important to someone. I've previously advocated for "criteria for inclusion". HJ Mitchell | Penny for your thoughts? 15:20, 21 February 2026 (UTC)

  One word synonym could just be "Includable." GeogSage ^{(⚔Chat?⚔)} 20:03, 23 February 2026 (UTC)

  It looks like we have a nice set of redirects in the Wikipedia:Criteria for inclusion line. I think that's a good thing. People can use whichever they like. WhatamIdoing (talk) 23:04, 28 February 2026 (UTC)

• I prefer "Notability". While "criteria for inclusion" would convey the idea, it would be awkward to use regularly. None of the other suggestions above work for me. - Donald Albury 19:04, 21 February 2026 (UTC)

  My POV hasn't changed since the discussion last year, specifically that we should eventually change this, and that the way to go about it is to pick some other word or phrase and use both, e.g., "On Wikipedia, notability, or eligibility, is a test used by editors..." or "On Wikipedia, notability is the article creation criteria that editors use..." Then editors have a choice, and if they choose to say "It's Wikipedia:Notable" or if they choose to say "It meets the Wikipedia:Article creation criteria" or if they choose to say "I think this meets our Wikipedia:Eligibility standards", then that's fine (though it'd be preferable if the guideline suggested a single alternate name). WhatamIdoing (talk) 23:02, 28 February 2026 (UTC)

Hey @Athanelar, I'm the person who started the last massive discussion. Good luck. The main message I came out of it with is there will be many more opposing people in actual RfCs rather than discussions; I started an RfC thinking I would have significantly more support than I did based on my experience discussing it at the idea lab. I think the only way to make this work is to make a smaller change first -- maybe some sort of movement among AfD contributors to use eligibility (linking to notability) would work to get it off the ground, but I have no idea how that would be organized. Maybe a WikiProject? Mrfoogles (talk) 20:59, 27 February 2026 (UTC)

• Can we at least footnote the WP:N lead sentence with an explanation along the lines of:

  (1) Wikipedia notability is largely independent of real-world notability, (2) while this is confusing, we continue to use the word because multiple discussions have failed to find a better one, and (3) alternative names (that have been considered, but not adopted) include notedness, criteria for inclusion, eligibility, suitability, admissibility, and wikinotability.

  New editors start out assuming that Wikipedia notability is at least somewhat related to real-world notability, which isn't helped by WP:N statements like Determining notability does not necessarily depend on things such as fame, importance, or popularity. While new editors don't start by reading all the PAGs, WP:N and WP:GNG are quoted so often they'll likely see them first, making it even more important these pages clarify common misconceptions. An overview of previous discussions will also be of value to more experienced editors. Preimage (talk) 06:41, 1 March 2026 (UTC)

  Alternatively, we could remove the term altogether (in effect, making WP:N a self-referential acronym): "On Wikipedia, WP:N is a test used by editors..." Preimage (talk) 07:08, 1 March 2026 (UTC)

  Please note that the existence of the term "Notability" is essential to a joke on the signpost. I think it was in the comix section of the last January edition. ~2026-11404-95 (talk) 19:51, 3 March 2026 (UTC)

• I dunno why people have complained how terrible "notability" is other than... probably it's unfair to those who may not be "notable" but might deserve an article perhaps. This is more akin to (failed?) efforts to repeal and (failed) constitutional challenges to the Affordable Care Act, both perhaps time- and money-wasting. Right? Frankly, "notability" has been fine as-is, despite hostile backlash and all, and something that consensus should practice often. Too bad certain others here wanna change it. BTW, have standards of "notability" been that low or that high? George Ho (talk) 19:55, 4 March 2026 (UTC)
• I like Preimage's solution of referring to Notability as a native concept abstracted from outside usage, but I like better the idea of changing the word notability. I've created WP:WOTABILITY to try to best differentiate outside notability with WP's notability. If anyone has any better idea than my sort of clunky one please share - I suspect this may be a big problem in editor retention, to have such an onerous stumbling block placed so early in editor lifetime. Embyarby (talk) 04:02, 5 March 2026 (UTC)

AI SEO

In WP:WikiProject AI Cleanup/Noticeboard#Chat hack there was a suggestion for some guideline or policy warning. Suggestion will be appreciated. Thanks Yesterday, all my dreams... (talk) 09:11, 21 February 2026 (UTC)

good luck trying to get anything done, the only policy people seem to want anymore is a policy allowing things Gnomingstuff (talk) 16:30, 21 February 2026 (UTC)

Well, we can always say C'est la vie. Yesterday, all my dreams... (talk) 17:57, 21 February 2026 (UTC)

I'd support a policy that says that all commercial AI products are immoral technology, but I can only see that proposal going over like a lead balloon. On a much more modest level, we could add a bullet point to the LLM warning, observing that LLM output can include deliberate misinformation. Stepwise Continuous Dysfunction (talk) 21:22, 21 February 2026 (UTC)

Please, Just Do It... Now. Yesterday, all my dreams... (talk) 21:36, 21 February 2026 (UTC)

I’d support a flat ban on AI, outside of examples on AI-related pages. Wikipedia should have zero tolerance for LLM text, AI-generated images, or any other kind of AI slop that people dump into articles (or anywhere else). Hosting AI images on Commons is kind of a necessary evil to discuss this technology and its “applications” (for lack of a better word) informatively, but I can see no other reason for Wikimedia to engage with or promote AI. It belongs in the Web 3.0 box of shame with crypto, which was rightfully banned as a donation method years ago. Dronebogus (talk) 09:07, 22 February 2026 (UTC)

Community Consensus is to allow LLM generated output with tight restrictions and warnings. I believe that this is a quality compromise between Anti-AI and Pro-AI viewpoints. ~2026-11404-95 (talk) 14:23, 24 February 2026 (UTC)

I think a total ban on all AI use on Wikipedia is an awful idea; not everything involving AI is automatically bad, and we should treat each use of AI in a nuanced, case-by-case method rather than just mindlessly assuming "AI bad." QuisEstJoe (talk) 17:48, 1 March 2026 (UTC)

Yeah I think a disclaimer and/or tight regulations are a lot more fair than just automatically assuming "AI bad" without thinking about whether or not the AI said anything bad. We can't let Wikipedia be tainted with the black-and-white "AI slop" mindset already rampant on the internet. QuisEstJoe (talk) 17:51, 1 March 2026 (UTC)

Editors are responsible for everything they add to the encyclopedia. So as long as any AI output is checked / corrected and all it's sources are verified before posting I don't see it as a problem. -- LCU ActivelyDisinterested «@» °∆t° 19:07, 1 March 2026 (UTC)

As an example: Talk:Zamia oligodonta. I didn't ask for in-line citations, so it took me a while to find which source a particular piece of content came from. The big time saver was the list of sources, which it would otherwise have taken me some time to dig out. The sources panned out, and while a few items tended towards more synthesis than I was comfortable with, I don't think any of it was wrong, just hard to literally verify from the cited sources. Donald Albury 20:07, 1 March 2026 (UTC)

Adding pre-debut members of music group

There are 2 pages that in conflict: TLC and NSYNC. Both have pre-debut members who never released any song as the group member. The problem is, some Wikipedia editors list them as past members. In this case, Blackpink's page should also include Miyeon, BTS with Supreme Boi, Big Bang with Jang Hyunseung, SNSD with Soyeon, and Innosense with Britney Spears.

Now, what is the consensus? ~2026-41110-5 (talk) 14:18, 23 February 2026 (UTC)

I don't see the problem. As long as the group has maintained the same name, then those pre-fame members are still former members of the group. There should definitely be a clear delineation of when a person was a member of the group in the prose and there may be special organization or footnotes in lists or tables, but they still need to be in there. --User:Khajidha (talk) (contributions) 17:28, 23 February 2026 (UTC)

Reading the further responses, I see some possible distinctions to draw. A group of musicians may come together and practice. At some point, they try out for bookings and print materials to advertise themselves. Eventually, they begin booking shows. They finally receive a recording contract and release their debut album. People may come and go at any point in this sequence. My position is that anyone who is presented to the public (either in marketing materials or actual performances) should be counted as a member. Where in this sequence do the people you mentioned fall? --User:Khajidha (talk) (contributions) 13:35, 25 February 2026 (UTC)

I don't know exactly why the pages for TLC and NSYNC have the very early members listed, but in the case of the K-pop groups listed; just absolutely no. You'd need to add over half a dozen "members" just for SNSD alone, because leading up to their debut, their management was swapping potential members in and out at seemingly a moments notice. There were at least four different line-ups prior to debut, with as many as twelve members in them. And that's just the ones we know of, I'm sure there were plenty more, are we gonna add every SME trainee from that period as a potential past member? Which brings me to a further point: good luck finding reliable sources any of this, because every thing I could find in my research for this reply was terrible fansites, or "sources" known to be unreliable. Pre-debut trainees are just that: trainees. They are not official members.DragonFury (talk) 22:28, 23 February 2026 (UTC)

I mean, the actual final plan of SNSD was 10-member group before Soyeon left voluntarily.

But yes, pre-debut members should not be included since it's not official. I also don't know why they including pre-debut members on NSYNC and TLC. ~2026-41110-5 (talk) 22:34, 23 February 2026 (UTC)

And to add another point; Twice was formed from the TV program Sixteen, so do we add the seven people not selected in the program as past members? Because if so, I'd like to see someone make the same argument for Kep1er and the NINETY contestants from Girls Planet 999 who weren't selected for the group. DragonFury (talk) 22:38, 23 February 2026 (UTC)

It should be whatever is reflected in reliable sources. If reliable sources describe those people as actual, bonafide former members of the band then sure.

For most of the examples you listed, however, this wouldn't be the case... they were just trainees in the same company along with the people who eventually became the final lineup. Agencies add and remove people from lineups all the time before they actually release any music. It doesn't mean they're a member of the band. RachelTensions (talk) 01:41, 24 February 2026 (UTC)

so you agree that we should not include pre-debut members? ~2026-41110-5 (talk) 19:44, 24 February 2026 (UTC)

I'm going to quickly reject "never released any songs as a member" as the dividing line, because bands can have a healthy life as a performing group before they become a recording group. There were no The Beatles songs released with Stu Sutcliffe on them until he was dead over thirty years (if I recall correctly), but he was a key player in their pre-record-contract days. -- Nat Gertler (talk) 02:16, 24 February 2026 (UTC)

The Beatles does not include Sutcliffe, Pete Best, etc in the infobox -- instead they add a link to the former members section, so that would be a solution for this kind of issue. ^~Hydronium^~Hydroxide^~(Talk)~ 04:18, 24 February 2026 (UTC)

Based on your contribution, this discussion seems to originate from a content dispute involving a temporary account that has since been blocked. As such, it is unclear why the argument is being revisited here rather than being handled on the relevant article's talk page, or whether it is intended to validate that blocked account's viewpoint. Regardless, there is general mutual understanding among most editors that only individuals who officially debuted and/or released work with the act are listed as members. Those involved solely during pre-debut stages, such as auditions or trainings, are typically excluded and do not carry long-term encyclopedic significance in relation to the act. Such information, if sourced reliably, may instead be included in the individual's biographies instead, should they have an article here. This standard has been applied consistently across comparable articles, with limited exceptions that are likely the result of per-article consensus. — 🧧🍊 Paper9oll 🍊🧧 (🔔 • 📝) 03:16, 24 February 2026 (UTC)

So the consensus is only official debuted members are listed, right? ~2026-41110-5 (talk) 07:33, 24 February 2026 (UTC)

For clarity, when I refer to "general mutual understanding", I'm specifically referring to South Korean musical acts only. That wording is intentional and is applied in conjunction with WP:VERIFY. As for anything else, refer to the last sentence in my earlier reply above instead. Additionally, it appears you are conflating two different categories of group formation. Certain Western acts where membership may be tied to founding history, name origin, or early lineup evolution are being treated as directly comparable to K-pop acts, where membership is defined through a formalized debut system and post-debut activity. Applying the same framework to both assumes a one-size-fits-all standard, which does not reflect how these industries function. Because of that conflation, comparisons such as invoking NSYNC to justify listing pre-debut trainees in K-pop groups are not particularly meaningful. For cases outside the K-pop context, exceptions and differing treatments may and or could already be accounted for on a per-article basis, or may not be, as noted previously. — 🧧🍊 Paper9oll 🍊🧧 (🔔 • 📝) 08:25, 24 February 2026 (UTC)

I mean, “pre-debut” means before debut, right?

Before debut = unofficial. Does it mean the same everywhere, or does each country have its own definition of “pre-”? Doesn't matter. It’s still unofficial.

I feel like Wikipedia is turning into a Wiki Fandom now. Why are we including unofficial members / non-final members in the same list as the official members? Where’s the standard? What makes Wikipedia different from Wiki Fandom? It's unofficial, like how I explain it better to you all. It's unofficial. ~2026-41110-5 (talk) 11:07, 24 February 2026 (UTC)

Alright let's summon User:Binksternet who putting Jason Galasso as former member of NSYNC. In his defense, Jason's name was part of the NSYNC name (which is already changed to Lansen). ~2026-41110-5 (talk) 07:47, 24 February 2026 (UTC)

• Why are we having this content dispute on VPP?—S Marshall T/C 10:23, 24 February 2026 (UTC)

  Because it's still about guideline. We are literally talking about an undisclosed guideline for hundred pages related to musical groups. ~2026-41110-5 (talk) 11:27, 24 February 2026 (UTC)

  No we aren't. This decision is fact-sensitive and needs to be made on a case by case basis. It depends on the person's contribution -- did they help write a key song, did they affect the band's development or sound, were they just a hired gun for a few shows? What do the sources say about them? There's no guideline to write. It's a simple matter of editorial judgement. If there's dispute then they don't go in the infobox (WP:ONUS).—S Marshall T/C 12:28, 24 February 2026 (UTC)

  Exactly that's why we are here. You think we are here for planning slumber party? No, we are here for discussion. And there is a big disagreement about whether people should include pre-debut members or not. Did those pre-debut members help the group? Put them on the History section, not the main infobox. That's the function of History section, to tell the story behind the group's creation. Infobox is only for the official information. ~2026-41110-5 (talk) 19:42, 24 February 2026 (UTC)

  Official in whose eyes? Is there an office somewhere where a team of people decide who is official or not? Without answering that queston it's no good bolding "it's unofficial". There are so many differences between times, places, genres and individual bands that it's pointless trying to create a general rule that will apply to everyone. And it seems that by pre-debut you mean before the recording debut. Many notable bands don't make recordings until a few years into their careers. Phil Bridger (talk) 19:42, 25 February 2026 (UTC)

The sources talking about the formation of NSYNC all agree that the name of the band came at a time when bass singer Jason Galasso was in the group. Galasso was warmly received when he joined, with other group members telling him his voice was what they were finally looking for. It was this formation that was deemed ready for a record label deal. Timberlake's mother Lynn remarked that, with Galasso on bass, the group now sounded very much "in sync". They noticed that the final letter of each group member's name could be assembled to form the name NSYNC, with Jason supplying one of the letters. That means Galasso was a foundational member of the group. Supporting sources include a Timberlake bio book and a People magazine piece on Galasso, calling him the "original fifth member of NSYNC".

I don't think there is any basis for artificially drawing a line for the purpose of rejecting Galasso. We should not be determining band membership on our own by saying "pre-debut" or whatever. That would be a violation of WP:No original research. The reliable sources should be telling us who are the group members. Binksternet (talk) 20:40, 2 March 2026 (UTC)

Inclusion criteria for those listed in the Epstein Files and updates to BLP policy

I’d like to invite broader community input on a potential addition to BLP policy. A recurring question has been how, and when, it’s appropriate to tag individuals named in the Epstein files, while avoiding a rush to judgment, guilt-by-association, or the appearance of a witch-hunt dynamic.

Clear inclusion criteria:

1. Only after at least 60 days have passed from the time the subject’s name appears in the released files.
2. The individual is formally under criminal investigation and/or has had criminal charges filed against them.

It seems fairly straightforward, aligns with BLP policy, and should be easy to put into practice. Input welcome. Coffeeurbanite (talk) 19:28, 25 February 2026 (UTC)

This would seem to rule out cases of mentioning other forms of high profile responses to the naming of individuals in the files, such as public protests to remove names from honorary buildings, etc., which seems a bit too broad to do WP:DUE justice. I'm not convinced we need any WP:RULECREEP here other than diligent observance of BLP and DUE. _signed, Rosguill ^talk 19:32, 25 February 2026 (UTC)

@Rosguill: I’m generally in agreement with you in principle. The concern, however, is the lack of consistent diligence in how this is being handled, which risks sliding into guilt-by-association tagging. As I’ve mentioned elsewhere in the project, we’re still in the middle of the immediate fallout. Many responses, whether high-profile or not, are understandably reactionary at this stage. Allowing some time to pass will give us a clearer sense of what is truly warranted and help ensure we’re acting thoughtfully rather than in step with the news cycle. Coffeeurbanite (talk) 19:38, 25 February 2026 (UTC)

And frankly, it may be worth considering a temporary pause as a community, a kind of fail-safe, so we can ensure we’re proceeding carefully and consistently rather than reacting in the moment. Coffeeurbanite (talk) 19:40, 25 February 2026 (UTC)

I'm not sure what you mean by "guilt-by-association tagging". _signed, Rosguill ^talk 20:10, 25 February 2026 (UTC)

The "Epstein Files" are not a secondary source, so, according to policy and guidelines we should not be creating articles about people just because they're mentioned there, or even mentioning them in other articles. The whole of at least the western world seems to have gone into some kind of collective madness over them, as if crucifying everyone who was in touch with one dead sleazebag will fix the problems of misogyny and pedophilia. Yes, they are important, but not so important that we should be changing the policy of an encyclopedia over them. Phil Bridger (talk) 20:35, 25 February 2026 (UTC)

@Phil Bridger: Is content being added to articles based on editors perusing the files themselves, rather than such content being reported in a source? I would agree with a prohibition against additions on that basis. BD2412 T 20:49, 25 February 2026 (UTC)

I can't point you to any existing article, but it looks as if that's what the OP is proposing. Phil Bridger (talk) 21:27, 25 February 2026 (UTC)

Then it's already moot, contentious material can't be added to BLP based on primary documents like the Epstein Files under existing policy. There is no need for additional policy. Katzrockso (talk) 21:40, 25 February 2026 (UTC)

But the OP is proposing to change existing policy about living people to allow that. Phil Bridger (talk) 21:55, 25 February 2026 (UTC)

Yes content is being added based on the primary source. It has started to calm down now, but as they were being released it was happening continuously. That issue is somewhat separate from the issue of inclusion when reported in other sources, but the details are little more than 'guilt by association'. -- LCU ActivelyDisinterested «@» °∆t° 12:30, 26 February 2026 (UTC)

We should mention it when its mentioned in reliable sources. For example, the NY Times is reporting today on Richard Axel's resignation from a Columbia University institute.[8] There's no reason it should be limited to people who are under criminal investigation. Jahaza (talk) 20:44, 25 February 2026 (UTC)

I second this. We report what reliable sources report, and those who dislike the fact that sources are reporting such things can take that up with those sources. BD2412 T 20:47, 25 February 2026 (UTC)

No, 'We report what reliable sources report' has never been Wikipedia policy. We exercise editorial discretion on what we report, depending on what sourcing is available, and on what policies and guidelines advise and/or proscribe (e.g. NPOV, and WP:BLP etc). Wikipedia is not an aggregator of 'everything on the internet' and has never aspired to be. Those who dislike long-standing Wikipedia policy and practice are obliged to conform to it until such time that they can successfully get it changed. AndyTheGrump (talk) 21:11, 25 February 2026 (UTC)

@AndyTheGrump, WP:AGF is also a policy to which we are obliged to conform. Don't assume that others are advocating violating Wikipedia policy.

The context here is a request to make a new time-based rule beyond the rules we currently have. As our content guidelines do say, "Wikipedia articles should be based on reliable, published sources, making sure that all majority and significant minority views that have appeared in those sources are covered" (my emphasis, and parenthetical removed). This doesn't mean ignoring other policies and content guidelines, but it aptly describes when we should add new information to an article all other things held equal. Jahaza (talk) 21:38, 25 February 2026 (UTC)

I'm not assuming anything. I'm stating as a fact that it isn't Wikipedia policy or practice to include everything published in reliable sources, and that including content on that basis alone can sometimes be a clear contravention of WP:BLP policy. As for time-based rules on when something can be included, I'd suggest that we should be exercising editorial discretion based around existing policy, not pulling arbitrary time limits from nowhere. AndyTheGrump (talk) 21:48, 25 February 2026 (UTC)

Being verifiable to a reliable source is something that all included content must have, but by itself it's not an inclusion criteria (WP:VNOT). Inclusion depends on context. One I reverted out was an individual who had reports stating he was called a 'good friend' in the Epstein files, but the context was that they had no contact with Epstein. They were considered a good friend by someone who emailed Epstein. That a friend emailed Epstein was obviously not due for inclusion, whether it was reported on or not. -- LCU ActivelyDisinterested «@» °∆t° 12:38, 26 February 2026 (UTC)

We clearly should wait until either their inclusion has lead to some type of charging or arrest, or has directly impacted that person (eg all the resignations that have happened). BLP reigns here as well as NOTNEWS, it is far better for us to wait to see if being named actually has impact. E are not a newspaper and this is a clear situation we shouldn't be regurgitating what the news puts out just because the name appears. Masem (t) 20:50, 25 February 2026 (UTC)

• My first instinct is to only include when something stems from the subject's listing in the files, such as a resignation or arrest, or if there are more reliable sourced information about the relationship (beyond a mere listing). Also, being mentioned in the files should not mean that a stand-alone page is created. --Enos733 (talk) 21:15, 25 February 2026 (UTC)

On the general question of whether the subject's name appearing in the files could be sufficient grounds on its own, even if discussed in secondary sources, to justify inclusion in articles, lists etc, I'd have to suggest that we'd need in-depth discussion in several sources at minimum. What we must not do, which apparently has been going on at List of people named in the Epstein files is attempt to include individuals on the basis that e.g. 'they were sent an invitation by Epstein', without evidence of even having responded. Even if sourced, this on its own is nothing but guilt by association, and remains so, regardless of sourcing: a gross violation of WP:BLP policy. Possibly 'resignation or arrest' might be stretching things a little to far in the opposite direction, for clearly-notable individuals where there has been extensive discussion in multiple top-quality sources, but in such situations, the primary-source file(s) concerned will only be a minor part of the coverage anyway if they are being reported on. Credible sources aren't going to be built around 'Epstein files' alone, and they will be assessing the content in the broader context of events they relate to. The 'files' themselves - a mishmash of material from the credible to random junk sent by nobody in particular - aren't 'a source' they are an accumulation of primary-source material kept together fundamentally for no greater reason than having the name 'Epstein' in them. We shouldn't be trying to assess them collectively at all. AndyTheGrump (talk) 21:32, 25 February 2026 (UTC)

I'd almost go one step further and posit that List of people named in the Epstein files is borderline violating WP:NOT regardless of what level of "in-depth discussion" merits inclusion in that article. The disclaimer in the lead section of that page does little to dispel the guilt by association here. mdm.bla 04:12, 26 February 2026 (UTC)

That list absolutely needs to go. It only would make sense after all investigations and legal actions are complete with the files, which may be years down the road. Masem (t) 12:35, 26 February 2026 (UTC)

Like I said on the talk page there, the whole concept is a nightmare combination of WP:INDISCRIMINATE and WP:BLPCRIME. The list should be deleted, there are other Epstein pages. Gnomingstuff (talk) 15:47, 26 February 2026 (UTC)

@Masem and Gnomingstuff: There is an ongoing deletion discussion with respect to the list at Wikipedia:Articles for deletion/List of people named in the Epstein files. BD2412 T 18:14, 27 February 2026 (UTC)

I have commented for deletion there. Masem (t) 19:15, 27 February 2026 (UTC)

My first reaction is "why are we limiting it to people in the files?"; if people are facing consequences because of their links to Epstein, that should be enough to be on whatever sort of useful list we want to make. I don't see the point in having a list of the Venn diagram between people suffering for their association and people on the list.

My second thought is that, as phrased (but presumably not as intended), this does not limit it to folks suffering from their relationship to Epstein; if someone's names appears in the files and they get charged with tax avoision, that would seem to qualify.

My third thought is that in the form stated, it does not limit itself to notable people, which brings up WP:BLPCRIME concerns regarding non-notable people charged.

My fourth thought has to do with a scheme to convince Flavor Flav that I am a member of the women's hockey team, and is thus not relevant to this discussion. -- Nat Gertler (talk) 21:36, 25 February 2026 (UTC)

It is entirely possible to be 'in the files' (or rather, in a file in the accumulation of primary-sourced material of mixed credibility known collectively as 'the Epstein files') without having interacted with Epstein at all. For example Janis Joplin and Elvis Presley are both mentioned in 'Epstein files'... AndyTheGrump (talk) 21:42, 25 February 2026 (UTC)

Hey folks. As a possible point of interest, there are now at least three separate discussions on this topic:

• This section
• Wikipedia:Biographies of living persons/Noticeboard#We need a clear policy about being in the Epstein Files
• Talk:List of people named in the Epstein files#Inclusion criteria - second draft

— Mudwater ^(Talk) 12:53, 26 February 2026 (UTC)

I resemble these remarks. Walter not in the Epstein files Ego 15:58, 26 February 2026 (UTC)

• To clarify, I was thinking about this in terms of whether the subject is either identified directly in the list itself (as a primary source) or mentioned in reliable secondary sources as appearing on the list. My concern is that there is a wave of resignations or removals that are occurring regardless of whether any criminal conduct occurred. If subjects are notable, those resignations or removals are likely to be covered in secondary sources, but that still reflects reactionary fallout rather than confirmed wrongdoing. So my question still stands, can we build in some sort of temporary pause? Coffeeurbanite (talk) 16:32, 27 February 2026 (UTC)

Users without extended permissions should be allowed on talk pages of extended-protected articles

I fully agree that newer users should not be allowed to edit extended-protected articles due to the risk of vandalism and heavily-biased editing, but what's the harm that could be done if normal users are allowed to simply talk about potential edits? The worst that could happen is that the talk page section gets a little bit toxic (and that's assuming that the admins aren't able to stop that with warnings/sanctions), and all that it does is that it prevents newer users with potentially good ideas from contributing. (And yes, there is the edit request wizard, but that does not allow for the same freedom or ease of discussion as participating in a talk page does.)

So yeah, only long-time editors should be allowed to edit extended-protected articles, but I don't get why that has to apply to talk pages of those articles as well. QuisEstJoe (talk) 21:27, 1 March 2026 (UTC)

@QuisEstJoe: Non-EC editors used to be permitted to make constructive comments on talk pages subject to ECR, but that clause was struck in favor of only permitting edit requests [...] provided they are not disruptive following a filing at ARCA and an 8-0 decision in favor of removing the constructive comments clause by the Arbitration Committee. Tl;dr, the previous language was problematic as non-EC editors were still prohibited from participating in RfCs, AfDs, etc. I'll especially encourage you to read the statement by ScottishFinnishRadish for the problems with allowing non-EC editors to participate beyond making edit requests. mdm.bla 21:55, 1 March 2026 (UTC)

Non-EC users are allowed to post on the talk pages of EC-protected articles (see the talk page of Donald Trump, for example). I'm assuming you mean articles under WP:ARBECR. Some1 (talk) 22:25, 1 March 2026 (UTC)

@QuisEstJoe: With the exceptions of the Arab-Israeli conflict, the Nagorno-Karabakh conflict, Kurds, the Russo-Ukrainian war, South Asian castes/tribes and Indian military history, any user can and should be able to edit the talk page of an article under extended-confirmed protection. The extended-confirmed restriction, as Mdm.bla says, was stiffened because the people who were causing problems on articles under 500/30 restrictions simply shifted their attention (and thus aggression, inability to shut up, and unwillingness to change the subject) to the talk pages instead of finding somewhere that isn't a powderkeg looking for a lit fuze. —Jéské Couriano v^_^v ^{threads critiques} 20:07, 2 March 2026 (UTC)

Abuse of Wikipedia by AI

It seems a third of the sources used to train AI is material from Wikipedia. Shouldn't something be done about that? We all are doing this for free to inform people, not to support billionaires AI investments who can push out the people of their daily jobs. I've been working on several Wiki's in different languages, and I have the feeling my work is stolen by big companies. — Preceding unsigned comment added by ~2026-13646-72 (talk) 19:49, 2 March 2026 (UTC)

1. Do you have sources to prove that "a third of the sources used to train AI is material from Wikipedia)?
2. Who cares if we're "supporting" billionaires? Not only is that a major oversimplification of the AI debate (more people use and are affected by AI than just the billionaires), but you also support billionaires through the brands you use in your day-to-day life (such as the device that you use to edit Wikipedia on, which was made by a company run by a billionaire), so the billionaire point doesn't hold much weight.
3. Where is the evidence that AI hasn't created more jobs than have lost, and what about the people whose jobs have been improved by AI (such as programmers, engineers, or medical researchers)? Besides, ending jobs doesn't make something automatically wholly evil; the internet has put a lot of jobs at stake (online shopping, for example, has put many brick-and-mortar stores on the line), yet that does not mean we should just forget about the benefits of the internet. The same thing can be said about AI.
4. How is AI analyzing information to train its ability to make something completely different "stealing?" Besides, your work on Wikipedia isn't wholly "your" work; not only have many other editors contributed to the articles that you have wrote on, but you and other editors have gotten "your" info from other sources, so it's not like AI is "stealing" your personal, wholly-original creation. Besides, Wikipedia is not meant to be anyone's source and its use is not meant to be restricted; it's meant to be a free-to-use platform for anyone to gain information. Why does that stop with AI analyzing that information? Furthermore, why doesn't it stop with others using Wikipedia as a source to get information for their own projects? I don't think you would get mad at someone on YouTube "stealing" from Wikipedia articles to get the info they need for their video essay.

QuisEstJoe (talk) 21:53, 2 March 2026 (UTC)

When you edit Wikipedia, you are agreeing to allow your work to be used by anyone in any way, basically. We don't have a way of excluding big companies (and indeed, some huge ones like Google use it in very obvious ways), and it would not serve the stated goals of the project if we did start excluding. -- Nat Gertler (talk) 22:00, 2 March 2026 (UTC)

I am not a fan of AI, but one of the pillars of Wikipedia is that all editors freely license their work to the public, and no editor owns an article – any contributions can and may be mercilessly edited and redistributed.

Whatever wikis you're working on probably have AI cleanup efforts you may be interested in. Gnomingstuff (talk) 02:47, 3 March 2026 (UTC)

I am not agreeing to allow my work to be used by anyone in any way. Wikipedia:Reusing Wikipedia content: Wikipedia's text content ... can be used under the terms of the Creative Commons Attribution Share-Alike license (CC BY-SA)... To re-distribute a text page in any form, provide credit to the authors... If you make modifications or additions to the page you re-use, you must license them under the Creative Commons Attribution-Share-Alike License 4.0 or later. Outside of that, the copyright reverts back to me. Hawkeye7 (discuss) 03:22, 3 March 2026 (UTC)

I desire to see a source for your claim. Also, you agree by using Wikipedia that "agree to irrevocably release your text under the CC BY-SA License and GFDL." And "You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license." This means that an AI agent providing a link to the Wikipedia page is enough to disqualify you from saying your work was stolen. You did agree to allow your work to be used. ~2026-11404-95 (talk) 19:48, 3 March 2026 (UTC)

This is what it means to license your work under a copyleft licence: you can't restrict who reuses your work if they meet the terms of the licence. And something is being done, by Wikimedia Enterprise getting Big Tech to pay for high-volume access without taking down the servers. See the various news reports following their announcement on our 25th birthday, such as this one in Ars Technica. ClaudineChionh (she/her · talk · email · global) 21:45, 3 March 2026 (UTC)

Hi ~2026-13646-72

The "one third" number needs a source, but yes, AI companies scrape Wikipedia for training data, this is a known fact. They are allowed to, under the CC BY-SA license, but other editors have identified that there is still the issue of attribution. As I understand it (I am not a lawyer), the considerations for licensed works used for training data is a legal grey area. And I agree, it does suck, because I agree that the AI industry sucks.

There's two senses in which you could say Wikipedia could "do something" about this. You either mean the Wikipedia community (the volunteer editors who edit Wikipedia), or the Wikimedia Foundation (the non-profit that hosts the website itself). I don't have much to say for what the Wikimedia Foundation could do.

For what the community could do, Wikipedia isn't really here to right great wrongs; we don't organize protests or anything, we're just here to build an encyclopedia, and we certainly shouldn't artificially inject anti-AI bias into the encyclopedia. You can, however, help chip in over at the AI cleanup efforts! We do (on the whole) consider using LLMs to contribute to Wikipedia to be abusive, but many folks try it anyways, and it takes no small amount of volunteer effort to deal with that abuse. You could always become an editor and assist over at WP:AINB. MEN KISSING (she/they) T - C - Email me! 20:10, 4 March 2026 (UTC)

I honestly don't even think that it sucks that much because Wikipedia is supposed to be a free-to-use encyclopedia for everyone to use, and suddenly closing that off to AI training itself because it's using "stolen" data is both unfair and nonsensical. If you come to Wikipedia to create "your own" article for yourself (which, just to be clear, I'm not saying that you in particular are), you're kind of missing the point of Wikipedia. Besides, it'd be one thing if this was an art-sharing or fiction-writing forum where we publish artistic expression, but saying to someone training AI that they can't use an article of real-world facts because "that's MY article of facts that I have the right to" is simply selfish. QuisEstJoe (talk) 20:40, 4 March 2026 (UTC)

Well, the sentiment against AI scraping of Wikipedia is not only based on the idea of content ownership being violated. It's a complicated issue with a lot more moving parts than that.

This more gets into the wider politics surrounding AI, and I'm sure that can be quite polarizing, so I'm not too eager to dig into it. But perhaps that wider conversation is one we should have, because some of the involved politics is quite relevant to the Wikipedia project. MEN KISSING (she/they) T - C - Email me! 22:32, 4 March 2026 (UTC)

As others have explained above, whether you're fond of LLMs or not, it would be antithetical to the purpose of Wikipedia for us to impose restrictions on who can use its content, and for what purpose. That is the entire point of calling Wikipedia the "free encyclopedia"—not only in the sense that anyone can edit it, but also in the sense that anyone can use it, reuse it, reproduce it, redistribute it, etc. Kurtis ^(talk) 14:48, 5 March 2026 (UTC)

Alternate potential usage of LLMs in editing Wikipedia—what is permissible, and what is not?

Say, for example, you have an editor who's written an article about XYZ. It is well-written, well-sourced, comprehensive, and it's about an actual person who actually lived. They get it to GA-status, and eventually, to FA-status. But later on, they admit that they used ChatGPT in helping them to create that article. They explained the process that they used in doing so:

• First, they found a bunch of reliable third-party sources about the subject in question.
• They use the following prompt to get ChatGPT to generate text: "Create a comprehensive overview of XYZ using the copy-pasted text provided below the horizontal line. Format this overview in the style of a Wikipedia article."
• They double-space, add three underscores (the "horizontal line"), and then copy large chunks of text from the various sources they've assembled, sectioning them according to the source from which they were excerpted.
• ChatGPT generates the text of a Wikipedia article; the user copies and pastes it into Google Docs.
• They then begin using their sandbox and the preview button to prune, paraphrase, copyedit, fact-check, expand, and further "Wikify" what ChatGPT generated.

By the time they're through with their work on the article and are ready to submit it, it can no longer be readily identified as AI-generated—it is almost entirely in their own words, using sources that they compiled. They checked it for factual accuracy, and they made sure that everything flowed together smoothly.

In your view, is this still a problematic use of generative AI for the purpose of editing Wikipedia? If so, why do you consider it problematic? And if an editor confessed to doing something like this, do you feel they should face sanctions for having done so? Kurtis ^(talk) 15:23, 5 March 2026 (UTC)

• Your example isn't realistic. If a person is going to rewrite an LLM-generated article so that every word in it is their own, then what's the purpose of LLM generation in the first place? ~2026-14165-49 (talk) 17:08, 5 March 2026 (UTC)

  Exactly. See my post below. EEng 17:16, 5 March 2026 (UTC)

  They would use it as a springboard to actually building a proper article, and to make the whole task feel significantly less daunting. Kurtis ^(talk) 17:17, 5 March 2026 (UTC)

  It can only "feel significantly less daunting" if they skip all the hard parts of writing an article i.e. gathering and internalizing the sources, selecting the facts for presentation, deciding on article organization, and so on. Your "springboard" is, in fact, a nice way of saying, "A way of letting people who aren't able to usefully contribute, feel like they're usefully contributing". Things like you're proposing will be the death of Wikipedia. EEng 17:32, 5 March 2026 (UTC)

• It's problematic because it's fiction. The fact-checking part would never happen, because by the time you prune, paraphrase, copyedit, fact-check, expand, and further "Wikify" what ChatGPT generated you could have just written the article from scratch with less effort (not to mention less chance of AI excrement slipping through). Anyone with sufficient competency to do what you describe would know this, and so would know better than to actually do it; therefore those who claim they're doing it actually aren't competent to do so (even if they fool themselves into thinking they are, in fact, doing so -- Dunning-Kruger). That's why there's no use case for AI-generated content, and why those who use AI to generate either article content or talk-page posts are, ipso facto, incompetent and should be blocked on sight. EEng 17:16, 5 March 2026 (UTC)

The reason I would think of for someone doing this, even if it ultimately expends the same amount of effort as simply writing the article from scratch (if not more), is because it might make the act of actually writing an article soup-to-nuts feel less daunting. Logically, anyone would surmise that they're just doing content creation in a roundabout way, but the sight of a "completed" article with flaws might give them more of an impetus to develop and build upon what was generated. It could create the illusion of editing rather than building an article from the ground up. Kurtis ^(talk) 17:27, 5 March 2026 (UTC)

"Illusion of editing"? You want us to foster an "illusion of editing"??? EEng 17:33, 5 March 2026 (UTC)

Was it not clear what I was attempting to convey? By "illusion of editing", I meant that it would feel more like editing an article as opposed to writing an article from scratch, even if that is functionally what it is. Kurtis ^(talk) 17:41, 5 March 2026 (UTC)

No, it was not clear. In general, most "editing" (in the sense you're using the word) involves improving presentation, copyediting, maybe pruning out UNDUE cruft, by making incremental changes to an article which is assumed, by default, to be verifiable, free of copyvios, and otherwise in conformance with key policies. What you're proposing is that we allow an inexperienced user be presented with a ton of material which without question is studded with hidden crap, and expect that user to find and remove all that hidden crap. EEng 23:06, 5 March 2026 (UTC)

Say, for example,

Nope, start over and try again. Which specific Featured Article are you vaguely alluding to in this hypothetical?

Anyway, your thought experiment here has a lot of problems:

• WP:LLMDISCLOSE strongly recommends that people disclose AI use from the get-go, in all associated edit summaries. This is not an outrageous, time-consuming thing to do. Here's an example of someone doing it usefully in good faith.
• Your sense of how the average AI Featured Article comes about is unrealistic. Based on the cases I've seen, the more common scenario is that AI is used to find the sources (potentially introducing non-reliable sources/WP:UNDUE emphasis/bias), to summarize those sources (likely introducing source-to-text integrity issues), and copyediting/rewriting existing text (potentially introducing tone issues, and distortion of meaning).
• There's no way to prove the negative here, but many articles that people think "can no longer be readily identified as AI-generated" can be identified as AI-generated in about 15 seconds if you know what you're looking for. I've flagged several GAs and FAs as AI-generated (and was right), and there are several more GAs and FAs that I'm pretty sure contain AI text but haven't bothered to flag because I don't really feel like getting into even more arguments than I already do. (Panic Room, it's your time to shine!)
• There's no way to prove how much fact-checking people do, but in my experience, when I spot-check sentences and claims that obviously came out of an LLM, the citations do not often verify the text, and sometimes they don't even come close. WikiEdu found last year that of the AI-generated articles they flagged, nearly every cited sentence failed verification. Similarly, a lot of AI text has a sheen of promotional tone that, for whatever reason, just doesn't register on some people's radar no matter how obvious.

Gnomingstuff (talk) 18:10, 5 March 2026 (UTC)

@Gnomingstuff: Which specific Featured Article are you vaguely alluding to in this hypothetical?—It really is just a hypothetical, but in the interests of disclosure, it's an idea that I'd been mulling over in recent times. Over the past few years, my executive dysfunction due to ADHD-PI has worsened (I suspect due to Long COVID-related brain fog), and so I have difficulty motivating myself to write much of anything. I've played with the idea of using ChatGPT to create a sort of "skeleton" for an article, or for generating something that I could use as inspiration. I want to be very clear: if I add something to Wikipedia, you can rest assured that it will have been thoroughly fact-checked and well-sourced, and each claim that has a reference attached to it is directly and explicitly verified by that reference. However, I was unsure of how the community would respond if I were to write an article, and then disclose that I had used ChatGPT to lay down a "blueprint" of sorts. I genuinely think that for a lot of editors, this would be seen as a serious breach of trust, even if what I submit is qualitatively different from what ChatGPT spat out; it effectively circumvents much of the article-writing process. I'm not sure if an editor who did this would be blocked for doing so, but I do think it would cast their integrity and their critical thinking skills into doubt, and it might trigger a review of whatever content they'd submitted using this approach.

Your linking of LLMDISCLOSE demonstrates that current community practice is more nuanced than I would have expected. Disclosure of using an LLM strikes me as the ethical thing to do, but it's fraught with risk. A lot of editors who attempt something like what I've described would probably opt against doing so, as it would undermine trust in them if they openly acknowledge using such a tool. Kurtis ^(talk) 03:30, 6 March 2026 (UTC)

A lot of editors who attempt something like what I've described would probably opt against doing so, as it would undermine trust in them if they openly acknowledge using such a tool.

I mean, it also undermines trust to learn about something the community strongly recommends doing (I realize LLMDISCLOSE is not really publicized that well) and decide "no, I'm not going to do that." It usually undermines it more -- generally if people are sanctioned for using AI it's because they are evasive about it, meanwhile there are a couple of people who are open about their process with AI who are not. Gnomingstuff (talk) 14:34, 6 March 2026 (UTC)

WP:LLMDISCLOSE is an essay. Nobody has to follow it, it's optional. Cambalachero (talk) 16:05, 6 March 2026 (UTC)

Correct that no one has to follow it, but undisclosed LLM use will undermine trust with many people in the community, which is what the essay WP:LLMDISCLOSE is trying to help editors understand. On the other hand, disclosure is a good way to WP:DGF: Conversely, clumsily using an LLM in a transparent manner, promptly receiving relevant feedback, and responding reasonably to that feedback, would generally mean that the user is able to receive the message, following which they are just expected to improve their editing, motivated by what is in Wikipedia's best interest. -- LWG ^{talk (VOPOV)} 16:34, 6 March 2026 (UTC)

I have tried this before on a couple of articles and it turned out to be more work than just writing from scratch. So I would find it problematic for an editor to do this regularly because once you have built the writing muscle, that is so much easier than using the chatbot. 📎 JackFromWisconsin (talk | contribs) 19:09, 5 March 2026 (UTC)

I should probably clarify that the above hypothetical was devised for demonstrative purposes. The fundamental question is: if someone admits to using generative AI for any facet of content creation, but doesn't specifically use it to actually generate content, is that still something that we should explicitly refuse to tolerate? Kurtis ^(talk) 18:07, 5 March 2026 (UTC)

Opinions vary on that point, but as EEng said, the non-hypothetical reality is that few to no examples of LLM use like you describe have been seen in the wild so far, while the LLM text we are actually seeing overwhelmingly fails verification. -- LWG ^{talk (VOPOV)} 19:38, 5 March 2026 (UTC)

There was an RfC about this topic only a few months ago. Gnomingstuff (talk) 19:40, 5 March 2026 (UTC)

Should something like the hypothetical scenario described ever actually come up… we can always look into it and decide on a case by case basis.

My one thought is that the editor in question made their job much harder by using the LLM… by simply summarizing the source material in their own words (from the get go) they could have saved themself a lot of extra steps (extra time and effort). Blueboar (talk) 20:37, 5 March 2026 (UTC)

• This reads like ragebait. Why would adding fact-checked, human-written material be problematic? (But the bait has inevitably been taken).Wh1pla5h99 (talk) 00:38, 6 March 2026 (UTC)

  To be clear, please: what reads as ragebait? EEng 02:37, 6 March 2026 (UTC)

  The whole post has the whiff of "let me act as if I need help tying my shoelaces". Wh1pla5h99 (talk) 02:45, 6 March 2026 (UTC)

  If an LLM is involved in any part of the process, it could cast the integrity of the editor into doubt in the eyes of many, even if they did their due diligence in ensuring that what they add is quality content. Kurtis ^(talk) 03:33, 6 March 2026 (UTC)

  I don't know why you would be worried about that. Wh1pla5h99 (talk) 04:45, 6 March 2026 (UTC)

  If an LLM is involved in any part of the process, it could cast the integrity of the editor into doubt in the eyes of many

  That's something they need to own, then. Gnomingstuff (talk) 14:29, 6 March 2026 (UTC)

• For things that involve actual writing, genAI's a net negative and I agree with EEng's scorched earth philosophy. But I think it's worth pointing out that a tool linked on WP:ATODAY was created using Claude AI, and having used that tool personally, it's pretty good. This is obviously not what you mean by genAI editing, but it uses genAI and it's for editing Wikipedia. It's worth stating the obvious that a tool like this can also be created without the assistance of AI, and I wouldn't be surprised if it would've been easier to do so. Tessaract2^Hi! 02:29, 6 March 2026 (UTC)
• I am curious. Two editors cite the high proportion of LLM generated text that "fails verification", and one example cites the WikiEdu process where we encourage newbie students to edit Wikipedia. What proportion of non-LLM-generated text on Wikipedia also "fails verification" (putting, presumably, our "I'm going to be strict" hat on). And what proportion of newbie student edits either fail verification or could be described as "hallucinated" or "clearly doesn't have the first clue" or "wouldn't make that mistake if they were an experienced editors like we all are".

To pick an article I hoped wouldn't be AI generated, I chose the User:Gnomingstuff's Agnes Grozier Herbertson. The first fact "(c. 1875 – 1958)" I'm going to guess appears somewhere in the 462 pages of the "The Oxford Companion to Edwardian Fiction". The citation lacks a page number. The second fact "a Norwegian writer and poet" I can characterise as "fails verification". A source cites Norway as her place of birth, but having Scottish parents, growing up in Scotland and later living in Oxford and Cornwall, and writing English-language works, I'm pretty sure there are no serious reliable sources describing her as "a Norwegian writer and poet". Our WP:MOSBIO says not to describe someone's nationality by their place of birth.

If I ask CoPilot "is Agnes Grozier Herbertson a Norwegian writer and poet" it replies: "Yes — Agnes Grozier Herbertson was a Norwegian writer and poet. According to multiple reliable sources, she was born in Oslo (then Christiania) and is consistently described as a Norwegian writer and poet, even though she later lived in the United Kingdom." The so-called "multiple reliable sources" include the Wikipedia article and another that appears to have lifted some text from the Wikipedia article. This makes me reasonably sure that falsehoods that fail verification predate the AI plague on Wikipedia, and that our fallible human editors are themselves the source of a great deal of AI's incorrectness. -- Colin°^Talk 14:36, 6 March 2026 (UTC)

Please don't ping me for discussions I am already aware of. The article isn't AI-generated, thanks for pointing out the style and sourcing discrepancies.

That being said, "fails verification" in the context of AI generally means that AI attaches a source to text when the source does not back up that text, and sometimes may not say anything even remotely like it. Generally this suggests that whoever added it didn't even bother reading the source (considering that many such issues can be found in 5-10 minutes' worth of spot checking). It doesn't generally mean unsourced content. Gnomingstuff (talk) 15:17, 6 March 2026 (UTC)

EDIT CONFLICT - basically what the unpingable user above said: There is no source attached to the claim of Norwegian nationality there, so this is not a source-text-integrity issue. No one is claiming that humans are infallible, what we are claiming is that AI routinely places in-line citations on text that those citations do not verify, and that a human who read and comprehended the source would be unlikely to think they did verify. -- LWG ^{talk (VOPOV)} 15:29, 6 March 2026 (UTC)

For comparison, here are articles generated from those sources using Grok and using ChatGPT, so you can compare and see how the source use and style issues differ. -- LWG ^{talk (VOPOV)} 15:50, 6 March 2026 (UTC)