Thepolicy section of thevillage pump is intended for discussions about already-proposedpolicies 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 somethingnew that isnot a policy or guideline, useVillage 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 manyWikipedia:Noticeboards.
If you want to inquire about what the policy is on a specific topic, visit theHelp desk or theTeahouse.
This isnot the place to resolve disputes regarding the implementation of policies. For such cases, consultWikipedia:Dispute resolution.
Please seethis 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 besplit to a separate page.
When discussion hasended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
I floated this atVillage 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)[reply]
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 ofWP:Verifiability andWP:No original research.SNUGGUMS (talk /edits)23:30, 26 January 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 alookatthesediffs. The choice to deliberately leave such sections with no sources is careless.SNUGGUMS (talk /edits)23:03, 27 January 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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.bla04:52, 28 January 2026 (UTC)[reply]
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)[reply]
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 (à laMOS:PLOTSOURCE). That said, I wouldn't oppose making{{Cite AV media notes}} (or w/e source) a requirement forWP: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)[reply]
Comment – I'd like to hear more about the intended benefit of promotingWP: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 fewMOS 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 atWP:PROPOSAL that should be followed for this discussion, including adding a formal RFC tag and posting a notice atWikipedia talk:Manual of Style.--Trystan (talk)13:50, 28 January 2026 (UTC)[reply]
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)[reply]
Oppose per SNUGGUMS. Clearly the advice not to source credits doesn't fit with wider policies and guidelines. And more broadly, perWP: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)[reply]
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)[reply]
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 aWP: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 withMOS: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)[reply]
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)[reply]
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.
Polling is not a substitute for discussion, but examining the !votes is a good place to startdivining consensus.Currently, there are 38 bullet points inthe 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) inthe proposal bySapphaline, 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 believea 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)[reply]
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 theWikipedia: namespace) A short summary of the complete set of changes:
Establish a minimum number of 10 threads on pages, except on user talk pages
Establish a maximum size of pages (about 200 KB) and page archives (about 150 KB).
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.
Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval
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
Introduce an enforcement mechanism for users failing to abide by the accessibility guideline (max size)
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?
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 – seeHelp: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 inWikipedia: namespaces. There are two possibilities:
A bot can generate pages for a given period that are assembled in a log (see examplehere). Discussions are started directly on these subpages. This is the procedure used atvarious 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 KBHTML 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 guidelinesscrapped 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 readingand 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 isan 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 offperformance and thepage 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 doright now.
Some users claimed that we should not do it becauseother 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.
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 asWP: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 inWP: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 usermay choose to blank most messages ontheir own talk pages, but archiving is recommended instead. There are messages that the usermust not remove.
If a user removes a message from the talk page, whether by themselves or assisted by automation, this will mean that the userhas read andis 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 likeWP:ERRORS violate this guideline by not keeping any archives.
Policy does not prohibit users, whether registered or unregistered, from removing comments fromtheir own talk pages, althougharchiving is preferred. If a user removes material from their talk page, it is normally taken to mean that the userhas read andis 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.
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 inUser: namespace, by custom you may manage these pages as you wish. Your requests not to edit yourUser: namespace will be honoured. However, your style of userspace management must be within reason and not lead to breaking these guidelines.
This is to separateUser: fromUser talk: namespaces. Nothing changes in theUser: namespace, and generally editors will still have free rein in their user namespace.
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.
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 theirUser 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 manageUser 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.
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 theUser: 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 surethe heightened accountability standards apply, even if such intervention does not involve administrative tools.
Note thathaving 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.
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.
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 peopleeven less time to check for vandalism until the bot strikes (that window is already as short as one or two days, in some cases). We absolutely should not make it the job of users to enforce accessibility considerations, that is the job of the actual paid frontend employees.Gnomingstuff (talk)15:25, 29 January 2026 (UTC)[reply]
also, I assume a) is meant to be "maximum number of 10 topics" because otherwise that makes most talk pages non-compliant. But I still oppose it either way, because setting a topic maximum codifies the loophole of spamming a talk page with many new topics to force the archive bot to trigger and disrupt the discussion.Gnomingstuff (talk)15:28, 29 January 2026 (UTC)[reply]
No, it's actuallyminimum. 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 ifthe last comment in a given thread is 10 days old or younger, unless the archiving interval was set at a lower value. And that's a hard one.Szmenderowiecki (talk ·contribs)16:03, 29 January 2026 (UTC)[reply]
Support all except point a - there should be flexibility on this point. 10 would be innappropriate for infrequently accessed talk pages, and 3 or 5 is perfectly adequate for encouraging discussion.Danners430tweaks made15:29, 29 January 2026 (UTC)[reply]
Skeptical of hard rules - If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? Do they have to fiddle with archiving something (perhaps even an active conversation) before they can tell everyone that Willy on Wheels is deleting the main page again?I'm fine with a smarter archive bot that can dynamically change how aggressively it runs based on page size. That seems worthwhile to me. Is forced archiving of user talk something that affects more than a few dozen editors? Is there a systemic problem here? However, if we happen to have 2 big, active important discussions on a noticeboard at the same time, I think accessibility is the sacrifice we make for keeping those discussions intact and in the expected place.It also might be worth exploring a finer grained structure for some noticeboards -Wikipedia:Administrator's Noticeboard/Quick Requests for things that don't need huge input is one wild guess I had that might work.Tazerdadog (talk)15:38, 29 January 2026 (UTC)[reply]
If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? ->ABSOLUTELY NOT. The question is why the page hits the ceiling. If the reason is that the page has very high traffic, but the bot is set at 10 days archiving interval or shorter, then deviations will be tolerated for the sake of keeping discussions, although huge discussions probably should be spun out in their own pages (see table). If the page hits the ceiling because the parameters are too loose and there's suddenly high traffic, they have to be set at 10 days. The page should not generally hit the ceiling despite low traffic, unless it's a userpage, where archiving will not be obligatory, in which case the enforcement kicks in. These archiving enforcement restrictions are absolutely not supposed to discourage or ban discussion.
I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding.Szmenderowiecki (talk ·contribs)16:13, 29 January 2026 (UTC)[reply]
This is probably worth exploring after this discussion is closed. At the grave risk of saying this about anything technical, it doesn't look like it'd be that hard to implement a minimum viable product of dynamic archiving.Tazerdadog (talk)01:57, 30 January 2026 (UTC)[reply]
Skeptical of hard rules I can understand the premise, but I am not convinced that we want a one-sized fits all solution. Fundamentally, I think there should be ways to "sticky" some threads on a talk page and there is a smarter way to search archives. --Enos733 (talk)16:32, 29 January 2026 (UTC)[reply]
Oppose: I think this is too inflexible to allow for the deviations mentioned. This (except a maximum page size which should be a requirement unless all sections are ongoing and not close-able) should be a set of recommendations, not enforced rules. That would be very unWikipedia.Turbo mega oppose a: I don't really see the purpose of a requirement that so deviates from our current practice. This would be a lot of enforcement for little benefit. I would think just one is enough, and I unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out.Aaron Liu (talk)16:35, 29 January 2026 (UTC)[reply]
unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out. This was discussed at thelinked 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 amaximum of 15 threads/30 for high-traffic areas. This is not the essential part of this RfC, so if the number is 3 or 5, so be it. I don't care that much so long as it's not 0. 1 is probably not good enough.Szmenderowiecki (talk ·contribs)16:42, 29 January 2026 (UTC)[reply]
As I was reviewing discussions, I found some users' concerns that empty pages discourage discussion. One may be pretty empty, particularly if the suggestion is not answered, as it is on most article talk pages.Szmenderowiecki (talk ·contribs)17:30, 29 January 2026 (UTC)[reply]
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. PerGnomingstuff'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. --tony16:46, 29 January 2026 (UTC)[reply]
Oppose all also BADRFC which goes against the consensus. RfC statement is not neutral nor brief. Pinging large groups of people wastes valuable volunteer time.Polygnotus (talk)16:50, 29 January 2026 (UTC)[reply]
I don't think such restrictive requirements are a good idea, and definitely stronglyoppose 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 ofthat one particular editoractive 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). --LCUActivelyDisinterested«@» °∆t°16:56, 29 January 2026 (UTC)[reply]
I firmlysupport 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 Isupport b & e, oppose a and am largely agnostic as to the rest.Vanamonde93 (talk)16:58, 29 January 2026 (UTC)[reply]
Oppose almost all, the onepossible support isb (maximum byte size for pages, a reasonable technical limitation) but that should probably be done in aseparate RFC on just that topic, and be a "soft" maximum anyway. Everything else is a bad idea that creates layers of bureaucracy and bad feeling over nothing important.SnowFire (talk)16:59, 29 January 2026 (UTC)[reply]
Oppose The OP claims thatWe have well-tested archiving tools/subpage creation tools that automate the process. This is not my experience. I've been editing Wikipedia for nigh on 20 years and I've not gotten on with any of the assorted archive tools which I've tried. And the archive pages for subprojects like ITN are among the worst offenders in my experience -- bloated and broken due to the template limit. What's needed is for the WMF to address the technical issues as that's their job. Wild development and draconian diktats are unlikely to be helpful.Andrew🐉(talk)17:05, 29 January 2026 (UTC)(edit conflict)[reply]
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. —Cryptic17:15, 29 January 2026 (UTC)[reply]
Essay Make an essay. Create the case there, supported by common sense, guideline and policy. Create a CAPLETTER link. Start linking it. If it catches on, within a couple years, you or someone else will promote it to guideline. This is the way to do it. These all-or-nothing hail mary proposals on VPP are lazy and usually don't work. You got to build something if you want to make change. --GreenC18:02, 29 January 2026 (UTC)[reply]
Oppose oppose oppose. Oppose RfC structure. The letters a-g don't match the rows in the table. My head hurts, and since this should be headed for SNOW close I won't renumber. Capital letters below talk to the table, not the lower-case list. Oppose A. Not mandating archiving of user talk (i.e. just deleting old stuff is fine) is valuable and should be kept. Archiving parameters (including "no archiving") is a personal preference. While the justification of the RfC is making user talk accessible, the proposal fails to explain why such harsh measures must be taken. Oppose B. No need for a specified number. Just force EEng to archive, and you've solved all problems :) Oppose C. Different talk pages require different archiving intervals. Archiving every 10 days is insane for regular user talk pages. Oppose D. Start a new separate discussion (without the infected atmosphere of this one). Opposing mostly because bundling this together with everything else is really ill-advised. Oppose E. The suggestions makes it clear the proposer don't know how people use archiving bots. The only sane minimum number of threads to keep is 4. 10 is way too many. Oppose F. For the same reason as D - start a separate discussion. Oppose G. Just hell no. Oppose H. For the same reason as D - start a discussion separate from everything else. In closing, the proposer really needs to study how to create constructive RfCs because this ain't how you do it.CapnZapp (talk)18:22, 29 January 2026 (UTC)[reply]
Yes to all I believe this is sorely needed for accessibility reasons, though I'm sure it will be opposed by people as too restrictive.ᴢxᴄᴠʙɴᴍ (ᴛ)19:38, 29 January 2026 (UTC)[reply]
Oppose as written This goes too far and is too strict (and "a" is just a bad idea). I'd support strongerrecommendations around archiving than we have now afterWikipedia talk:Talk page guidelines#RFC: Recommended maximum talk page size, but strict limits aren't going to work well and mandating bots archive every talk page would probably work even less well. Good luck figuring out what those recommendations should be though, since it seems the people who really care are mostly the ones who like having ridiculously huge user talk pages and they're happy to derail straightforward heuristics into demanding any rule be based on "page weight" and so on.Anomie⚔19:56, 29 January 2026 (UTC)[reply]
Oppose all. This entire proposal is a complete waste of time. There's no reason whatsoever why we should enforce a hard limit on talk page sizes. This has to be one of the most poorly thought out RFCs I've ever seen, let alone participated in.Sugar Tax (talk)20:11, 29 January 2026 (UTC)[reply]
Strong oppose all - A is a terrible idea. That willadd to clutter, not reduce it. It will make pagesless accessible, not more. B is also a terrible idea. This has been explained many times:how long it takes for a page to load is not based on how many kB the page is in size. Because A and B are bad ideas, the rest of the proposals, which seek to enforce A and B, are also bad ideas. And really, the last thing this website needs is more r00lz. There are like a million f'ing rules on this website because it's 25 years of people being like, "I don't like this, let's make a rule to prevent it!" Look, you want to make every page on Wikipedia load reasonably quickly, there is one way, and really only one way, to go about it: you pick your website performance tool, and you say "must load within 5 seconds (or whatever amount of time) on any browser less than 10 years old (or whatever amount of time), as measured by X tool (or the average of multiple tools, take your pick)." You don't regulate the damn kB or the number of minimum threads if you want a page to load quickly, because that doesn't solve the problem.Levivich (talk)20:31, 29 January 2026 (UTC)[reply]
Oppose all and suggestWP: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 inhttps://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize andhttps://www.mediawiki.org/wiki/Manual:$wgAPIMaxResultSize --Guy Macon (talk)20:47, 29 January 2026 (UTC)[reply]
Oppose all. In particular:
a)oppose minthreads=10. If you have sufficient experience with Talk pages you know that sometimes an individual thread can run long, including longer than 200kb on occasion, so this would contradict one of your other proposal terms.
b)oppose max pagesize=200 and max archive=150. This has been very recently debated, and it is inadvisable to raise this again so soon, even if subsumed as part of a longer proposal.
c)oppose mandated archiving: better clarify what you mean bymandated. We mandate very little at Wikipedia, other thanWP: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, perWP:CREEP andWP:BURO. You do not trust administrators atWP: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 aboutEEng'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 atWP: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 perWP:OWNTALK andWP:CREEP.
f)oppose oppose oppose UTP max size enforcement. See e), andWP:OWNTALK,WP:CREEP, andWP:BURO. Personally, I would consider invokingWP: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 likemandate,enforcement,limit,require,comply, andforce 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 likegenerally,should,typically,suggested,consider, and other terms that are often used inWikipedia policies and guidelines to indicate something less than a hanging offense? Your usage smacks ofmy way or the highway, and does not conform to general usage at Wikipedia, in my opinion.
In re "e)", if there's something about someone's User_talk: page that makes it difficult for other editors to communicate with them, then it is other editors' business.WhatamIdoing (talk)22:07, 29 January 2026 (UTC)[reply]
Not necessarily. If you have trouble accessing a webpage, it's not necessarily the problem of the webmaster to fix it, it might just be that you're using obsolete technology. It's not tolerable or practical to expect us to have every single web page work great for every single user no matter how obsolete (or laden with plug-ins, scripts, etc.) their client is. We should require ourselves to meet industry-wide web standards, not the standards of every random person on the internet.Levivich (talk)22:12, 29 January 2026 (UTC)[reply]
If you're required to post an ANI notice, and you can't because the editor has a million-byte-long User_talk: page, then we have a problem. "Hey, stop being a jerk and archive your talk page" is something we can do. "Dude, stop being poor and buy a new computer if you want to report someone to ANI" is not something we can do.WhatamIdoing (talk)22:54, 29 January 2026 (UTC)[reply]
Not necessarily. If 1,000 people have no problem posting the ANI notice, butone 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" donot have a problem, just that one person has a problem, and "fix or update your client"is something we can say. Again: we should comply with industry-wide web standards, not with the needs of every single person out there.Levivich (talk)22:59, 29 January 2026 (UTC)[reply]
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 thatLarge talk pages are difficult to read and load slowly over slow connections andUser talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier. - Hint: make pages accessible enough to make collaboration easier. Does this recommendation work? No. There is a reason government pages require basic accessibility support, with reference to WCAG guidelines. There is no reason we cannot require this on our side.Szmenderowiecki (talk ·contribs)23:10, 29 January 2026 (UTC)[reply]
And how exactly is this the job or responsibility of unpaid volunteers, as opposed to the engineers who are actually paid to make websites accessible and improve rendering time?Gnomingstuff (talk)23:47, 29 January 2026 (UTC)[reply]
And how exactly is this the job or responsibility of unpaid volunteers, as opposed to the engineers who are actually paid to make websites accessible and improve rendering time? Whyas opposed to? Por qué no los dos? Also, volunteersdon'thave to do anything at all, and yet they do. Your attitude just kicks the can down the road. And I don't have to remind you that WMF has had quite a few fumbles about their coding. In this thread, just look at the 03:31, 30 January 2026 (UTC) comment.Szmenderowiecki (talk ·contribs)11:31, 30 January 2026 (UTC)[reply]
I have never seen anyone get any actual negative action against them if they fail to post on a user's talk page for an ANI report. Many editors are eager (perhaps overly so) to notice omissions and correct them. To avoid this argument (and I think it's actually generally a good change) perhaps we should amend the ANI rules to say that if you cannot reasonably, for any reason, post on a user's talk page, mention that in your initial report (or immediate reply).Skynxnex (talk)00:54, 30 January 2026 (UTC)[reply]
More generally, even when specific forms of communication are not required, we expect editors to be able to communicate with each other. That includes making it reasonably possible for newbies to be able to leave a message on any page that is used for discussion.
ANI itself frequently breaks that limit; a handful of editors' User_talk: pages do as well. For example, I remember when DGG's talk page regularly ran >800K long (example) and sometimes exceeded a million bytes. That revision took about 10 seconds just now to load on a modern computer with a decent internet connection and all scripts/gadgets disabled viamw: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.
That old revision took about 8 seconds to load load on my modern phone over 5G. Most of the time was spent, I am pretty sure, by the server itself having to freshly fetch and render the page since it was probably uncashed for me. I think one circle I'm trying to square is that none of this should be be any editor's job. It shouldn't be a bot's job. There shouldn't be rules and potential punishments if you do it wrong. The MediaWiki itself should just allow editors to pick how many sections they see per talk page. Abd the rest are the archives. But of course the long history of talk pages just being a page makes that hard. But that sort of change is less disruptive than more rules.Skynxnex (talk)05:40, 30 January 2026 (UTC)[reply]
What do you think the loading time would be if you were using a low-end phone (e.g., aJioPhone) 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 (rememberWikipedia:Flow?) is that the change would have hurt one group of people and benefited a different group of people. So naturally the first group complains that it's all harm and no benefit (to them), and the beneficiaries are already have difficulty with joining conversations, so they have much less ability to make their view heard. I don't think that reality will change this decade. We will probably have to wait until the small minority of editors who primarily use mobile devices become a more vocal part of the Wikimedia communities. In the meantime, what's happening is that mobile-heavy communities are finding off-wiki places for discussion and coordination (e.g., Whatsapp or Discord).WhatamIdoing (talk)18:50, 31 January 2026 (UTC)[reply]
Isupport a limit on the size of user talk pages, but not on noticeboards, which are generally archived automatically and have not proved an issue in the past. However, I also think the horrendous formatting of this RfC has killed any chance of us getting a productive outcome here. Proposing seven different changes at once, some of which put the cart waaay before the horse (enforcement mechanism for a guideline that has yet to exist??) was a bad idea.Toadspike[Talk]21:34, 29 January 2026 (UTC)[reply]
Oppose all - I am yet to be convinced that there is a real problem with talk pages - annoyances yes, problem no. Nor do I think that any of the proposals would be an appropriate way to deal with the annoyances. When there is an issue with a talk page, our current rules (and lack thereof) give us FLEXIBILITY to deal with them as we think best fits the specific situation. This all seems to CREAPY to me… boxing us in unnecessarily.Blueboar (talk)21:46, 29 January 2026 (UTC)[reply]
Oppose as misguided and repetitious. As I already said in December,If archiving a thread is controversial, it very likely should not happen. If it's not controversial, there's no reason to wait until the page reaches some arbitrary size. The fact I am quoting myself from another RFC on this same topic barely a month ago suggests this RFC is problematic. —Rutebega (talk)23:00, 29 January 2026 (UTC)[reply]
Oppose all, as strongly as possible. Good grief, not this nonsense again! The idea of making this kind of stuff enforceable is downright offensive. --Tryptofish (talk)00:14, 30 January 2026 (UTC)[reply]
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.JumpytooTalk01:54, 30 January 2026 (UTC)[reply]
Support a maximum size, absolutely. I have a reasonably good computer, and it still takes an absurd amount of time for some user talk pages to load. This is a collaborative project, where accepting communications is necessary, and should not be hobbled by an inordinate pride in an absurd talk page size.BD2412T04:52, 30 January 2026 (UTC)[reply]
Strong support some kind of stronger enforcement for accessibility, including a maximum size for user talk pages. I don't know why editors think the layout of their talk pages is so important that they can impede accessibility for others. Wikipedia is not a forum and talk pages exist so editors can communicate with each other, not so they can be fancily decorated or have years old discussions visible at first glance. There is a good reason we have aWP:SIZERULE for articles, and there is evenless of a reason to not impose a strict limit on the size ofuser talk pages than for articles. WhileWP:CREEP can be a valid concern, it does not apply here, at least without meaningful justification as to why a user talk page might need to be that large.I don't have strong opinions on many of these particular proposals other than I generally echo the sentiment from others (particularly Toadspike) that this is far too specific/narrow a proposal to work. For the closer, you might interpret this as support b, e and f, oppose a and no opinion on the rest.Katzrockso (talk)13:45, 30 January 2026 (UTC)[reply]
No. With all due respect, this feels like a case of wasting the community's time to resolve a petty issue of minimal consequence. I struggle to believe that even goofy talk pages likeUser 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 loadUser talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds. --LWGtalk(VOPOV)19:34, 30 January 2026 (UTC)[reply]
Oppose - None of these seem worth doing. Too many edge cases, too much bureaucracy when it's only very rarely a problem. On-wiki page sizes are tricky measures to use, because the size of the wikitext is not the same as the size of a page in a browser, with all the images and templates and whatnot. And there are some talk pages that really do need to be longer than others. So this all seems like for circumstances when both of these are true: (a) multiple people have difficulty using a talk page and ask for something to be done about it (or tries to do something about it), and (b) someone ignores the complaints and/or reverses efforts to fix the issue. The latter is very rare, and only ever an issue in userspace, where we tend to frown on other users jumping in to archive. Really, I can only think of one case where both of the above have been true on a usertalk page. I do not know why that person digs their heels in, or why several people reliably show up to insist it's cool, but them's the breaks with norm-breaking and social capital on wikipedia (and, let's face it, most places). In other words, if anything it's a one-off for an administrators' noticeboard, no ta new policy; and I'd also recommend against that noticeboard trip as pointless. As I wrote below, a new entry in perennial proposals would be justified at this point. —Rhododendritestalk \\00:53, 1 February 2026 (UTC)[reply]
Why not zero? If all the discussions on my user talk page are a year old and refer to something long since resolved, who are you to tell me that I can't archive all of them? --Guy Macon (talk)01:41, 1 February 2026 (UTC)[reply]
Establish a minimum number of 10 threads on pages, except on user talk pages. So I think we are talking about article talkpages. But often article talkpages contain only stale stuff that has been dealt with years ago and is no longer relevant.Polygnotus (talk)01:53, 1 February 2026 (UTC)[reply]
I can see the value in the default being a non-zero value for article talk pages automatically archived by a bot, which cannot tell whether the stale stuff is still relevant. That also gives an approximate indication of how active the talk page is (if I ask a question there is it likely to be seen or should I hunt down a WikiProject?) but if editors at a particular talk page think a non-default value (including zero) is appropriate there then that should be allowed imo.Thryduulf (talk)02:01, 1 February 2026 (UTC)[reply]
OK thanks, I think this proposal is confusingly worded. Certainly we wouldn't require pages to have 10 discussions on them, it seem that that is supposed that 10 part is supposed to only be about a parameter for this mysterious archiving solution - and not actually a minimum number of topics required on a talk page (i.e. a talk page can't even be CREATED unless you start 10 or more discussions at once). —xaosfluxTalk01:32, 1 February 2026 (UTC)[reply]
Ithink this is intended to relate to the number of threads left on a page by archiving bots. For exampleWikipedia talk:WikiProject UK Railways archiving configuration has the parameterminthreadsleft = 5 so old threads (in this case defined as 30 days since the last activity) will not be archived if it would result in fewer than 5 threads being left on the page. I'm at a loss as to why this is something that needs to be a guideline, let alone anything stronger.Thryduulf (talk)01:50, 1 February 2026 (UTC)[reply]
Some people think a talk page with some discussions on it, even if they're really old, is more inviting for newbies. Possibly the proposer here is one of them. Or maybe the idea was just to avoid "unnecessary" archiving on very inactive pages since the proposal calls for automatic archiving of all talk pages.Anomie⚔02:01, 1 February 2026 (UTC)[reply]
That's the impression I got from reading the TPG discussion, where two issues were raised: disputes over manual archiving and empty talk pages that may result out of that. It was a minor thread in the discussion, but the people who did address it were largely opposed to both. Hence the proposal.Szmenderowiecki (talk ·contribs)09:06, 1 February 2026 (UTC)[reply]
The easiest solution is an addition that anyone can archive any inactive threads on any talk page, and reverting these archivals is disruptive.sapphaline (talk)10:10, 1 February 2026 (UTC)[reply]
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 fromMinority 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 seereasonably accessible but did not make it to the part where you defined "Reasonable". In summary, the specific parts of the proposed changes I do not like are a through g. Thanks for asking, but I can offer no support.— JohnFromPinckney (talk /edits)23:04, 2 February 2026 (UTC)[reply]
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.
Quick question: how does this help us achieve our goal of a world in which every single human being can freely share in the sum of all knowledge?Polygnotus (talk)21:01, 31 January 2026 (UTC)[reply]
I have asked Quiddity to find a WMFer who can dive into the technical stuff; that way we have a solution for all long pages once and for all.Polygnotus (talk)21:09, 31 January 2026 (UTC)[reply]
S Marshall is asked to stay on topic, avoid personalizing discussions, and stick to general principles of Wikipedia.
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)
I think this talk section illustrates vividly how unhelpful the entire idea proposed at the top really is. And frankly, this section (not the whole discussion, just this section) should be closed and hatted as a personal attack. --Tryptofish (talk)22:00, 31 January 2026 (UTC)[reply]
should have been hatted the moment someone brought donald trump into it, really
Has this been retained (not archived) for humor reasoning, a community consensus against one or more editors, or maybe the love of drama and large talk pages? Surely it is not because of a lack of archiving knowledge--Otr500 (talk)22:41, 31 January 2026 (UTC)[reply]
Is it time to just add "force EEng to make his user talk page functional" to thelist of perennial proposals? Or an extension ofWP: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. —Rhododendritestalk \\23:12, 31 January 2026 (UTC)[reply]
It occurs to me that a counterproposal that involves the idea of sanctioning EEng is something that EEng ought to be notified of. (Oh, but his talk page was too long to notify him, I get it!rolls eyes) So I did it:[1]. --Tryptofish (talk)23:39, 31 January 2026 (UTC)[reply]
I've been trying to talk to you for about half an hour Tryptofish and got edit conflicted every single time so you get the short version.Your claim that this reduces to a personal attack on EEng is wildly mistaken. It's about EEng personally. It's about a problem with EEng's talk page behaviour. But it's not an attack to propose a solution.—S MarshallT/C23:45, 31 January 2026 (UTC)[reply]
And, the solution for EEng is not the solution for every editor in the long talk pages category. Some of those talk pages load easily. Some of the editors are indeffed and it's not realistic to expect them to fix it.—S MarshallT/C23:47, 31 January 2026 (UTC)[reply]
But, EEng is a user in good standing who's bright enough to see that his talk page is a problem. He's well aware that it needs to be fixed. We've established at the DRV that preceded this mess that other people don't get to archive EEng's talk page for him.—S MarshallT/C23:49, 31 January 2026 (UTC)[reply]
Therefore there's only one person who can fix the problem and it's EEng. He knows he needs to do it. He hasn't. So I suggest ways of making him.—S MarshallT/C23:51, 31 January 2026 (UTC)[reply]
In a collaborative project you must have a talk page people can work with. If people can't work with your talk page then you're being uncollaborative. It's the Wikipedia equivalent of antisocial behaviour.—S MarshallT/C23:53, 31 January 2026 (UTC)[reply]
There isn't only one way to look at this. There's several different ways. One way I like to see it, is that outside of article space, I don't care how long a user talk page is, but it presents technical problems that have yet to be solved. When I comment on a long talk page on my desktop and on my mobile (using desktop view), there is a bit of lag that makes using the reply function impossible. Using the edit section isn't as bad, and adding a new comment entirely tends to work. This shows that there is a problem with MediaWiki, not EEng. How about we fix that first?Viriditas (talk)00:10, 1 February 2026 (UTC)[reply]
In a perfect world, MediaWiki would be less ghastly. But we don't control that. We have to work with the software we have, not the software we want. So we need volunteers to have the behaviours that make the software work. EEng doesn't. It's got a lot in common withhoarding: 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 MarshallT/C09:52, 1 February 2026 (UTC)[reply]
S Marshall, you and I have both been around this project for a very long time. (Indeed, I remember the verifiability-not-truth debates of a bygone era.) You, like EEng, are a user in good standing who is bright enough to realize that this discussion you have started is only inflaming the issue, and not accomplishing anything productive. If you have accomplished anything at all, it's that you just might have caused more editors to come over to the opinion that is opposite to your own. --Tryptofish (talk)19:31, 1 February 2026 (UTC)[reply]
Well then I don't know if it's the case that no one got the ping or it's just random users in the list didn't get it, or maybe those that were at the bottom of the alphabet? I knew that{{ping}} only fits 50 usernames but I didn't know that one comment couldn't have more than 50.Szmenderowiecki (talk ·contribs)16:17, 29 January 2026 (UTC)[reply]
@Szmenderowiecki This is just a bad RfC which is probably why people don't respond to it. And I don't really see the point. What are you hoping to achieve? We already had this discussion a short while ago.Polygnotus (talk)16:25, 29 January 2026 (UTC)[reply]
This is just a bad RfC - in what way? I'm looking atWP:RFC and I don't see your point. You can disagree with the premise (which I guess you will based on your prior comments) but it doesn't make it a bad RfC.
We already had this discussion a short while ago. - addressed in the table.
which is probably why people don't respond to it - We are just two hours into the discussion, so how do you know?
What are you hoping to achieve? - minimum accessibility standards that will cause at most moderate performance issues for all users wanting to engage in Wikipedia discussions; also stopping quarrels about archiving preference.Szmenderowiecki (talk ·contribs)16:34, 29 January 2026 (UTC)[reply]
This is just a bad RfCin 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 agoaddressed in the table. Maybe, but this is still a problem.
which is probably why people don't respond to itWe are just two hours into the discussion You are, that is my point, but" we" as an alleged community are not "just two hours into the discussion"
minimum accessibility standards that will cause at most moderate performance issues that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. But starting an RfC and pinging a bunch of people when you haven't really understood the problem, the various factions in the debate and the upsides and downsides of the various options is unlikely to lead to a good result.
I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding. But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help.Polygnotus (talk)16:41, 29 January 2026 (UTC)[reply]
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 isnot the first time.Polygnotus (talk)19:55, 29 January 2026 (UTC)[reply]
Wow, I missed that before. This whole, huge, indigestible discussion no longer looks like agood-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 tosupport.Mathglot (talk)07:16, 1 February 2026 (UTC)[reply]
The first link is irrelevant to this discussion, the second link is the DRV, the third is literally a companion discussion to DRV. I am using all forums for their intended purpose. Mathglot I started this discussion because it became apparent to me at DRV that there are no good procedures to enforce talk page accessibility, which I believe are needed. This is the only reason I was starting this discussion. I am amazed that some editors dismiss my concerns as fake. I urge you to strike your accusation of me trying to harass editors. If you insist or want to go the route of banning discussion, go ahead, but that accusation, and that of any other editors suggesting I'm trolling or creating the concern out of thin air, will also be brought to light in appropriate forums if need be.Szmenderowiecki (talk ·contribs)08:57, 1 February 2026 (UTC)[reply]
I am sorry, but that is my honest impression, right or wrong. If I were in your shoes, I would comment anywhere but here, as it will only draw more attention to your actions. In my opinion, you are skating on thin ice, and the more attention paid to this, the more likely it is that it will cause trouble for you now, or at some later date. You are of course always welcome to raise accusations you view as inappropriate at the appropriate forum, which would be my Talk page, followed byWP:AN/I if you don't get satisfaction there. If you just want to vent, I invite you to my Talk page. I can be very conciliatory, and will listen to what you have to say. Maybe it will make you feel better. Good luck,Mathglot (talk)09:40, 1 February 2026 (UTC)[reply]
I'm not going to be the one to escalate, so the ball is in your court. I don't think any disciplinary intervention is necessary for any party here, for now, at least if you strike that accusation. I'm not going to be the one who shoutsWP:UNCIVIL at the slightest hint somebody makes a faux pas and the one who drags you to ANI. I've worked jobs where people assaulted me every once a while and where I learned a lot of very interesting things about who I am and where I need return to (as a naturalised immigrant). I managed to still maintain a poker face most of the time and grow somewhat immune to these attacks. Bickering strangers on the internet are several pay grades below that. But I will mount a defence if necessary. Or remain silent where I believe it will be best for my case.Szmenderowiecki (talk ·contribs)09:53, 1 February 2026 (UTC)[reply]
I have no wish (nor time) to escalate, so we agree on one thing at least. Sorry to disappoint, but I will not strike, as it represents my honest opinion. I agree that remaining silent is best for your case. I should add that I did not realize you were an immigrant and I am very impressed (and envious) of your command of English, which to me, appears to be of native-speaker level. I wish my abilities in foreign languages were as good as yours. Kudos!Mathglot (talk)10:38, 1 February 2026 (UTC)[reply]
Szmenderowiecki, Actually, I will strike under one condition: I strike my comment, and immediately following that, you withdraw and{{hat}} this proposal as "|status=withdrawn". That would be to the general benefit of everyone. Do you accept?Mathglot (talk)10:50, 1 February 2026 (UTC)[reply]
If there is a viable alternative proposal, I will withdraw this one. I amin 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 onlyyour decision becauseyou made the claim. I don't want it to beon 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, thisshould imply that youhave good evidence to back it up, which will stand upon independent scrutiny and presentation of all exculpatory evidence. And I want that possibility to rebut any point of that potential complaint, hence the "reserve the right". I still appreciate honesty, even if it occasionally breaks rules of what discussion should look like.Szmenderowiecki (talk ·contribs)14:02, 1 February 2026 (UTC)[reply]
you don't have a clear understanding of the situation so any proposal you make is hindered by that - sorry?
that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. Read all these discussions, understood them well, and I disagree with your premise. You can disagree with mine. You can think of it as a terrible idea but it doesn't mean it becomes a bad RfC question.
But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help. And no one came up with that idea at the idea lab, where you could have participated and told me this was a terrible idea and maybe we should do something else instead... That discussion was up for almost a month in a high-traffic forum. You could have proposed that idea yourself, the idea I didn't have before that comment. Why nobody thought of that before? Why do you blame me? For what?
neutral and brief - you just seem to be opposed to holding the RfC because you are satisfied with the status quo rather than having problems with neutrality and brevity. Because you don't say how it's not neutral. It's not the shortest statement but it's definitely not out of place for RfCs I witnessed in terms of size.Szmenderowiecki (talk ·contribs)16:54, 29 January 2026 (UTC)[reply]
@Szmenderowieckiyou just seem to be opposed to holding the RfC because you are satisfied with the status quo To me it seems to be the other way around. It looks like you disagree with consensus formed in the recent preceding discussions (which is allowed of course) and then started an RfC that ignores the opinions expressed in them. Combine that with a very long and non-neutral RfC statement and you got a bad RfC.Polygnotus (talk)17:02, 29 January 2026 (UTC)[reply]
I mention that the way I read that discussion was that the 75 KB wikitext limit was removed,and that's it. Nothing more, nothing less. The question was not specific enough to say if that meansno limits or maybesome higher limit or something else.That was a bad RfC, because the result's interpretation is ambiguous. And you know it because you engaged in that discussion extensively.Szmenderowiecki (talk ·contribs)17:12, 29 January 2026 (UTC)[reply]
What the hell is this, your idea of a "big beautiful bill"? I presume I was pinged to here because of my close ofthis 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 theone change that youmost want to make, and which you believe has a strong chance of obtaining a consensus, and start with that, please. I'm not a member of a political party who will just vote up or down on your big bill, based on how my party leadership tells me to vote, without even bothering to read the details of the bill. –wbm1058 (talk)17:14, 29 January 2026 (UTC)[reply]
What the hell is this, your idea of a "big beautiful bill"? Trump aside, the proposal was up for a month on a high-traffic page. Why didn't you engage? I gave a list of ideas and anyone could have said the thing you say now. But no, I have to be pummeled at the start of the RfC because people don't bother to look at thevery place intended for workshopping proposals. Why workshop them at all then?
I presume I was pinged to here because of my close of this thread. - no, that's because you posted in the Discussion : Recommended maximum talk page size part.
It seems you've disregarded my advice to start separate RfCs for article-talk and user-talk. As I said, I see no functional difference between these two. I am free to disregard your advice if I believe it's bad advice.
your ping was an annoying distraction when I'm trying to stay focused on tasks in my to-do list which require focused concentration - Jesus Christ, I didn't know that pings can make people so cross. You don't have to engage with it, you can come to it later if your task list is what you need. There's no need to be so worked up.Szmenderowiecki (talk ·contribs)17:28, 29 January 2026 (UTC)[reply]
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 themaximum talk page size discussion of all places, notminimum. So I felt it was necessary to address. I again get pummeled for that.
(Contrary to some suggestions, I don't mean this proposal as a snide against EEng. EEng's page was not the first time I had this problem, I just didn't speak up. This is a general applicability rule. Any talk page about 500 KB is absolutely terrible for my browser just reading it, pages of the size of ANI are terrible editing them).Szmenderowiecki (talk ·contribs)18:24, 29 January 2026 (UTC)[reply]
You'll notice there are very few guidelines as rigid as what you propose.Ease of implementation is always something policywriters need to consider. Min threads and max archive size are going to be hard to implement.It is great that you've identified and analyzed issues and are willing to put in the work or fix them. But often, if you put them forward in an RfC—the process for attracting as many participants as humanly possible—without consulting through non-RfC discussions, you are going to attract as many participants as humanly possible that have a lot of questions.Aaron Liu (talk)22:32, 29 January 2026 (UTC)[reply]
This proposal does not say anything about min size.minthreadsleft or similar exist in both of the used bots. Max size is easily implementable by something like this: If pagesize exceeds, say, 200KB, archive the oldest discussions whose last comment was at least a year ago; if still exceeds, decrease by 30 days until you get within 200KB, but not below 10 days. Or something like that. But often, if you put them forward in an RfC—the process for attracting as many participants as humanly possible—without consulting through non-RfC discussions the problem is that Ihave consulted my proposal. The gist was always there: mandatory automated archiving and limits on all pages intended for user communication. There may be an detail that I have not, but I consulted most of it. And people are shouting me down for this.Szmenderowiecki (talk ·contribs)23:00, 29 January 2026 (UTC)[reply]
Yes, I'm talking about min threads. You're not going to stopthe extremely-popular manual archiving by just forcing changes to the most popular bots. It will also be hard to set up automatic archiving everywhere.I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits. I did not see where you mentioned mandatory automated archiving at all.Aaron Liu (talk)03:36, 30 January 2026 (UTC)[reply]
It will also be hard to set up automatic archiving everywhere. Nope, all it takes is a bot function that automatically introduces e.g.{{subst:setup auto archiving}}, when the first talk page thread is created. It is going to default to the loosest parameters, but you can change them manually later. For existing pages, check for existing archive, if there is none but there are talk page threads, automatically deploy. I'm not a coder but pasting a text if a certain piece of text exists isn't a complicated piece of code we are speaking of.I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits
a was originally expressed as the minimum size limit (it was 500 KB HTML, but it could be 200 or 300 or even 100, so long as it's not 0. The pseudocode part at the bottom included the minkeepthreads parameter. I got feedback that the code was "too complicated", so I simplified it. I was never that part was a bad idea.
c (mandated archiving) is literally the second bullet point in the VPI.
f is the seventh bullet point
g was discussed along the way.
the change from "should" to "force" Equivalent in meaning for purposes of guiding user behaviour. If "should" had been supposed to be a non-binding recommendation, the discussion would have made no sense.
the 50%/90% reduction in the page size limits. I don't know what you are talking about.
Szmenderowiecki, is it then your position thatmandatory automated archiving would apply to all user talk pages, including those currently archived manually? As an example, my user talk page, now nineteen years old, is manually archived and always has been. If your proposal achieves consensus would I have to give up manual archiving and submit to obligatory bot archiving? What about users who manually archive by theme (or other algorithm of their choice) instead of last comment age? Oblige them to switch as well?Mathglot (talk)03:49, 30 January 2026 (UTC)[reply]
Read the proposal carefully and you will get the answer. Short answer: no, do whatever you want so long as you keep within the size guidelines out of your own accord. If you refuse upon request, or you have trouble keeping the maximum size long-term, only then it becomes a yes. Archiving by theme will not be possible because we don't have bots that guess the discussion's context and sort discussions into buckets according to what you are talking about. If an admin wants to manually sort their discussions, fine, but I don't expect admins to do that because they likely won't hve the time and their job is not to micromanage others' talk pages. If you don't want this to happen, keep within your 1200 KB HTML and you'll be golden. I'm upfront that this is a restriction on user autonomy, but user autonomy, just like generally being allowed to edit, is not a right, it's a convention. If your user autonomy makes others suffer, you are abusing it.Szmenderowiecki (talk ·contribs)10:46, 30 January 2026 (UTC)[reply]
Any talk page about 500 KB is absolutely terrible for my browser just reading it @Szmenderowiecki: Three quick questions. What browser are you using, how much RAM do you have, and how fast is your download speed? This is because I think the problem here may be your device, whatever it may be.
This is not to say that people shouldintentionally 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 toedit EEng's talk page, however, is a different matter...SuperPianoMan9167 (talk)23:19, 29 January 2026 (UTC)[reply]
Sure: Chromium 143, 8 GB RAM, 25 Mbps download on WiFi. RAM is 100% not an issue because I have tons of spare RAM without forced cleaning, neither is download speed because the whole source code should be downloaded within at most a second, shorter than the rendering itself. Everything works pretty fine with these parameters on any web siteuntil I get to gargantuan talk pages on Wikipedia. Or try to edit big talk pages. It's not a "me" problem.Szmenderowiecki (talk ·contribs)23:31, 29 January 2026 (UTC)[reply]
Okay. I figured as much but I still wanted to ask.
I admit that Ihave sometimes experienced issues on very large pages; I've gotten the "This webpage was reloaded because a problem occurred" message (which is Safari's way of telling you that the page crashed because it ran out of memory) on large talk pages before. When I scroll down a very large page, it usually takes a couple of seconds for the page content to appear. And of course, the sheer size of these pages makes them difficult to navigate on mobile (Minerva skin helps to make this less tedious).SuperPianoMan9167 (talk)23:41, 29 January 2026 (UTC)[reply]
Minerva skin looks shit on desktop, and besides readers are very likely not aware that they can change the skin using the "Mobile version" link, and quite a few may not be even aware of the possibility.. So long as we allow IP editing, any reader may become an editor with no warning. Any IP who wants to post on any noticeboard or talk page and the noticeboard is 500K+ is likely to abandon the effort due to the lags. This is unacceptableSzmenderowiecki (talk ·contribs)10:50, 30 January 2026 (UTC)[reply]
My understanding is that there's no standard way of archiving pages and so there's a mish-mosh of bots and tools. I've evolved my own way of filing my talk page but it's too manual for my taste. Anyway, I have a question. What I'd really like is a simple method of moving a section from one page to another. This is the way that email and other documents are usually filed -- you move them to folders. Is there such a thing in Wikipedia?Andrew🐉(talk)17:30, 29 January 2026 (UTC)(edit conflict)[reply]
I believe the closest we have is one click archiver, but in theory it should be possible to develop something that can do a similar action but to a manually defined page.CMD (talk)03:34, 30 January 2026 (UTC)[reply]
BTW, every time I've tried to say something in this discussion, I've gotten an edit conflict. Wiki software is really poor at doing user communication when compared to just about everything else.Andrew🐉(talk)17:34, 29 January 2026 (UTC)[reply]
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 anincompatibility which is going to break it. I've seen many useful tools broken as a result of change and that's why I think all such infrastructure and interface should be managed centrally by the WMF.Andrew🐉(talk)23:19, 29 January 2026 (UTC)[reply]
I daily-drove the parser migration tool (which allows you to set your default parser to parsoid) in late 2024 and had no issues with CD (in fact,little issues at all other than the reduced server caching increasing page load times). I just checked again and everything works. @ChildrenWillListen probably had a configuration issue.There's been many calls for WMF to maintain promising infrastructure.WMF couldn't even install it. (slightly clickbait, but I couldn't figure out a better way to summarize this, sorry)Aaron Liu (talk)03:31, 30 January 2026 (UTC)[reply]
You mean the same engineers who built out the internet to give us a postliterate society where everyone is addicted to screens, where people no longer read books, where society is more susceptible to disinformation and propaganda, and who are solidly against the humanities and democratic values? Those guys?Viriditas (talk)22:47, 31 January 2026 (UTC)[reply]
Please keep in mind about mobile users, who because of such small screen size have to contend with extremely difficult scrolling of pages with long discussions or too many threads (especially as the font size for thread headings can be relatively large~2026-63332-0 (talk)17:54, 29 January 2026 (UTC)[reply]
~2026-63332-0 consider going toWP: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 themeta:Community Wishlist andregister your wish.Mathglot (talk)19:34, 29 January 2026 (UTC)[reply]
Minerva skin already provides a "Latest comment" link at the very top of the page and in the header of each section, which is very helpful. In fact, it is so helpful that I sometimes find it easier to comment on talk pages on my phone than on my computer in Vector 2022.
(Yes, I use Vector 2022. Experienced editors may now publicly shame me. I've been reading articles here for long enough to remember a time when it didn't exist yet. I also (gasp!) used VisualEditor when I started editing, but I eventually quit using it because I find that writing wikitext directly ismuch faster, especially on mobile where I don't have access to keyboard shortcuts.)SuperPianoMan9167 (talk)23:52, 29 January 2026 (UTC)[reply]
That's good to know; that means that the code to do this already exists, and porting it to other skins should not be that difficult. I would say in response to temp user 63332, that either in addition to, or instead of the Community Wishlist idea, you could file aPhabricator ticket requesting it as an enhancement. (I think you have to be registered, but make a request atWP:Help desk and I am sure someone could help you with that.)Mathglot (talk)02:32, 30 January 2026 (UTC)[reply]
CapnZapp I'm confused about your order of opposes in justifications.
The A part refers to what, the introductory statement or the mandatory archiving? Mandatory archiving does not speak about user talk exemptions or even user talk at all in the justification. User talk is specifically exempted, end of story. What are you talking about?
The B part presumably refers to specific limits. I don't have a problem with EEng, I do have a problem with his talk page, as with hundreds of others I cannot easily read, interact with, let alone edit. Also, good luck.
C (max archive interval) misunderstands the proposal. The 10 day limit is only meant to cover high-traffic pages ("likely to routinely exceed the maximum size limit"), and that's additionally explicit in the last sentence.
D is not substantial to this discussion, I could have edited this myself.
E: Why 4 minimum threads specifically? I had opinions that 1 is the number. Some prefer 2. Some prefer 5. We can discuss it.
F: Impossible to discuss in separation of B because there are no maximum user talk page size regulations right now, so such change would be meaningless. I'm not sure what I'm poisoning by opening this discussion.
H: Possible to discuss at the archive bot pages, but will likely discourage people from using bots. So pretty much impossible to discuss without A because it's pointless. It is meant to be the automated enforcing mechanism.Szmenderowiecki (talk ·contribs)18:48, 29 January 2026 (UTC)[reply]
I explained at the start. Basically, I went through the table, creating a point for each row. Only once I was done did I realize you failed to match your a-g to your table.CapnZapp (talk)18:54, 29 January 2026 (UTC)[reply]
My comment before was thatEndorse 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.
From the table:Single discussions split into their own pages due to size considerations are exempt from internal archiving but have to be searchable through archives of the page they were split from.There might be creation of subpages due to size considerations, but I understand that there may be discussions with huge turnout wbhich cannot be split, or pages with several questions that are interconnected ando so would be inadvisable to split. So there's no dedicated solution for this problem. Accessibility is an issue due to poor performance, but any other solution would be worse.Szmenderowiecki (talk ·contribs)22:13, 29 January 2026 (UTC)[reply]
I'm here because of the ping. I don't like anything about this proposal, but Ido like the comparison made in this discussion to the so-called Big Beautiful Bill. --Tryptofish (talk)00:17, 30 January 2026 (UTC)[reply]
You gave the reason yourself above (@23:10, 29 Jan) why this Rfc was unnecessary and a gigantic waste of time; quote:
We already have a recommendation [about] [l]arge talk pages...
Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is, which is why adding copyrighted material to a Wikipedia article or libeling someone is going to get you in hot water faster than conflict of interest violations, which in turn will get you in trouble faster thanWP:Manual of style violations.
As you say, we already have a recommendation about this, but apparently, your opinion is that the existing recommendation doesn't have enough teeth in it on the enforcement side, hence all the draconian language trying to sharpen the teeth. But this violates the sense of proportion. There is a reason that libel and copyright get more attention and stricter enforcement. No doubt in the thicket of Wikipedia regulations, improvements can be made, but we do not want very large talk pages to have the kind of enforcement wording or response that libel does; it is way out of proportion to the seriousness of the violation (if it is even deemed a violation at all). Nothing in your Rfc proposal is an improvement over current guidelines imho, imperfect as they my be; rather, they would make page and archiving guidelines worse, and cause additional strife among editors, perhaps resulting in enforcement discussions against users with long talk pages. Is that really the hill you want to die on?Mathglot (talk)02:58, 30 January 2026 (UTC)[reply]
Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is You may disagree with me on this point, but overbearing talk pages that barely load and are all but impossible to edit are pretty much a serious violation on a website whose core tenet is enabling editingand 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 longeranyone who can edit.Also, the enforcement for libel and copyright violations is potential blocks as well. This rule is not meant to create another means to block someone because this can be resolved without blocking anyone. And I wrote just that in the reasons. So despite the seriousness of obstruction of talkspaces, it does not escalate to revocation of editing privileges.Szmenderowiecki (talk ·contribs)11:13, 30 January 2026 (UTC)[reply]
"Overbearing talk pages that barely load and are all but impossible to edit"would be a problem if they existed, but they don't. As another user said, "Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds."
And even if they did exist, the rational approach would be to go to ANI, document the problem, see what happens when others try to replicate it on similar hardware, and if the problem is real deal with that one page. (If anyone does this, ping me. I have a number of ancient computers running ancient browsers available to me) --Guy Macon (talk)03:16, 31 January 2026 (UTC)[reply]
Also, while it might be great if everyone could easily use any device to leave messages at all talk pages, forcing compliance with a uniformity rule would make Wikipedia a nastier place with the side effect of encouraging rule-pushers while discouraging a variety of editors.Johnuniq (talk)03:50, 31 January 2026 (UTC)[reply]
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 loadUser 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+.
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 unlessabsolutely 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 featureslow-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 discouragesme 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.
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.
Find a page on which the problem is reproducible (ANI?)
Visit that page in an incognito (sic) window, without logging in. Does the problem still occur?
In a non-incognito window: disable your scripts and DiscussionTools in preferences, then try again. Does the problem still occur?
Enable your scripts and DiscussionTools again and capture aperformance profile (not the HAR file) and post a link.
I will tell you the results: Point 2: Loading pages like EEng's make browser visibly struggle upon rendering even when logged out. Justslightly less time than in my JS configuration. Impossible to say if editing is impacted because my editing environment in source is the2017 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 justreadingUser 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 mswithall 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)Butall 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 italways 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 arenot 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 brilliantpublic service announcement by the government of Wales on disability that illustrates my way of thinking - why don't you just raise the roof if you can? Or, in this case, why don't you make the pages uncluttered enough so that any user can answer? The roof job may be expensive but the uncluttering isn't asking for much.Szmenderowiecki (talk ·contribs)14:00, 31 January 2026 (UTC)[reply]
@Szmenderowiecki Interesting, thank you. I can download files up to ~20tb in size.
It looks to me that the problem is not the amount of plain text (as I predicted). The problem is the amount ofDocument 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 aperformance profile and diagnose the problem? Thanks,Polygnotus (talk)15:24, 31 January 2026 (UTC)[reply]
DOMs are in large part generated by text you and other editors type. Too much DOMs is usually a problem of the page and not the user who tries to load the page. If the page is user-generated, then it becomes the responsibility of the user(s) who contribute to that page, and to maintainers of the engine rendering that page, to make sure the amount of DOMs does not impact user experience. The meaning of DOM is not also something we typically expect from a regular user to know about. They just expect the website to work. DiscussionTools were disabled because I use Convenient Discussions, which is incompatible. WMF can contact me directly for inquiries at any time.Szmenderowiecki (talk ·contribs)15:55, 31 January 2026 (UTC)[reply]
@SzmenderowieckiDOMs are in large part generated by text you and other editors type. DiscussionTools adds a whole bunch of DOM elements per comment. About ~8. If you want to we can make a test page that contains the same DOM elements but no text and you'll see it load slowly on your computer.
It is the responsibility of the WMF to deal with performance problems. Quiddity has over 2 decades experience on Wikipedia and started working at the WMF in 2013. They'll know who to ask.
DiscussionTools were disabled because I use Convenient Discussions, which is incompatible. Unfortunately DiscussionTools still adds those DOM elements to the page, even if you have it disabled and even if you are not logged in.Polygnotus (talk)16:02, 31 January 2026 (UTC)[reply]
Irony above: "This page is too big. Excessive page size can cause accessibility problems for some editors. Please temporarily speed up the page archiving rate or split large discussions to separate subpages"~2026-68406-1 (talk)15:19, 31 January 2026 (UTC)[reply]
I have a 4Mhz (That's megahertz, not gigahertz) Z80 running CP/M and Fusix that communicates at 9600 baud. It can display and edit text-based discussions of any length on USENET or BBSs lightning fast -- no need to limit discussion size. If computers that are thousands of times faster than that are struggling, the obvious answer is to talk to the WMF and ask them to look at what they are adding to the text. --Guy Macon (talk)17:38, 31 January 2026 (UTC)[reply]
I mean, any website would load well, whatever its volume, if it looked likeThe Motherfucking Website. It could probably run on a potato - but that's not really the point. In 2026 I'd expect at leastthis orthis orthis orthis. I'm not saying there isn't a room for code improvement (although I don't know if it's true) but if the suggestion is that I have to disable certain in-built features just to be able to view/edit large pages, that person also has it backwards.Szmenderowiecki (talk ·contribs)21:24, 31 January 2026 (UTC)[reply]
I'm actually sort of curious whether you feel it performs better for you once you get to the point of actually scrolling around. Not really the initial load (it's not a useful comparison because it's less cached by the parser which slows it down, and it doesn't actually initialize DT reply widgets which speeds it up), but we were able to massively reformat the HTML used there in ways the talk pages community consultation didn't let us consider.DLynch (WMF) (talk)15:37, 3 February 2026 (UTC)[reply]
I played around withdocument.querySelectorAll('*').length and that first assumption is incorrect. Reducing all talk pages to 10 bytes max does fix the problem so the second one is hard to disprove.Polygnotus (talk)20:21, 31 January 2026 (UTC)[reply]
Polygnotus what's your plan if WMF says that everything is all right with the software or if they do not answer back your ping (presumably because they don't think that your suggestion of simplifying MediaWiki output is not worth the effort))?Szmenderowiecki (talk ·contribs)10:08, 1 February 2026 (UTC)[reply]
@Szmenderowiecki There are people who work at the WMF whose entire job it is to ensure that Wikipedia works properly on as many devices and in as many situations as possible. Quiddity works or has worked in the relevant team.
Help them help you, this is your best shot. There are people who have been tracking such stats for years and are interested in situations where the user experience is bad, so they know what to do and not do.
Quiddity is usually quite busy so we can leave a message on their talkpage in a week or so , if necessary. If you are polite and constructive they will help you. They may ask you some follow-up questions or do some tests so they can understand your experience better.Polygnotus (talk)12:48, 1 February 2026 (UTC)[reply]
This doesn't really answer my question. Sorry if I'm not clear, so I'll rephrase it. While I disagree with their opinion, some users say that WMF alone is responsible for this, not users (my opinion is that it's a joint responsibility). Suppose that WMF/MediaWiki says any of the following:
Our software works just fine, no bugs impacting performance detected, anything else?
We fixed bugs that give a boost of 1.3% in loading time, but that's about all you will get.
This is core functionality that we are not ready/willing to disable.
We are introducing something new that willincrease JS load, so no scaling back (given that webpages get more bulky over time and old devices, including, hopefully, mine as well someday, get changed - not a stupid thing to expect). We are not introducing any "lite" version of MediaWiki with just the bare minimum of DOM elements necessary for MediaWiki functioning and images linked instead of actually loaded. There will be no toggles.
I agree with Szmenderowiecki that just because there's a technical limit to a page that our servers can handle doesn't mean that any individual page ought to push towards it because of UX issues. (They may even issue a recommendation in their user guides to the effect that a page is not supposed to be over X KB wikitext unless necessary)
In other words, suppose WMF/MediaWiki says it's actually not their problem, it's the problem of the community, because there's nothing/not much to fix on the software side (regardless of whether they tell the truth, because you are not going to get anything (more)). What happens next?I will reiterate that if@Quiddity (WMF): or any other person who they believe will be competent to look into this issue wants to get feedback from me, they can ask all relevant questions and get relevant test results. Here, by email or otherwise.Szmenderowiecki (talk ·contribs)13:16, 1 February 2026 (UTC)[reply]
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 realityat least some of the people who work at the WMF are nice, hardworking peoplewho share our goal. That doesn't mean I agree with every decision ever. Quiddity was a Wikipedian for years before he started working at the WMF.
Since they share our goal they want Wikipedia to work well for everyone, on any device. That means they will at least try to investigate the situation.
Will you be happy/agree with the result of the investigation? Will there be a quick fix that solves the problem in a week? I do not know, but if we don't give them the information they need we can't complain about performance.
If they say "WONTFIX" then at least we know where we stand. I can look at your pc (if you let me), but not their servers. The WMF can see exactly what is happening on both ends if you let them. So they are in the position to fix this.
I am pretty certain they will at least look at the problem. I can't promise you'll be happy with what they do with that information because they don't work for me. They are independent beings with free will. And they are your best bet to fix this problem once and for all.Polygnotus (talk)14:04, 1 February 2026 (UTC)[reply]
Listen, if MediaWiki suddenly runs 3x faster and the load time is no longer a nightmare, I think anyone will be ecstatic. I would still argue the switch is necessary on other grounds - for example, because large pages, even if they load OK, are hard to navigate. But at least the barrier to discussion will be not as severe. So yeah, I wait for instructions from MediaWiki/WMF team.Szmenderowiecki (talk ·contribs)14:11, 1 February 2026 (UTC)[reply]
(reply-to @07:56, 31 Jan) The performance report (parser profiling data linked atT416247) on loading the long user talk page you most complained about, shows a CPU time of 5.977 and real time of 6.714 seconds. This is only half again over the limit of 4 s you list as acceptable performance. If that is the actual load time for the worst Talk page at Wikipedia, then I'd say we were doing pretty darn well! I believe you wen you say that it is taking much longer than that for you to load the page on your hardware/software configuration, even if it takes much less time for others who have tried it on various setups, including ancient ones. Various conjectures have been raised about why that is, and the phab ticket will hopefully shed some light on that and lead to improvements for everyone. But making a proposal to limit Talk page size based on a misdiagnosis of a problem you are seeing and others do not, and then adding a draconian archiving proposal on top of it to be imposed on everyone based on the original misdiagnosis seems to be compounding error upon error, and not a valid proposal. I suggest we wait until we understand why you are getting the delay you are. And thanks for agreeing to provide input to the investigation tracked at the Phab ticket.Mathglot (talk)03:55, 3 February 2026 (UTC)[reply]
There is irony and confusion. Why do we need more "rules"? Maybe this is putting the proverbial cart before the horse in some or most cases. Read #7- "Require pagesthat 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 atWikipedia 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 abot, 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, andWikipedia:Talk page guidelines#User talk pages (maybe in the "Personal talk page cleanup" section) might be a good place to have some information on page size? It seems this may be important for new users or editors who would like some teeth and a place to point to. It is sort of a sad idea to attempt to teach someone to swim by just tossing them into the water. I think we should steer clear of user talk pages. --Otr500 (talk)01:10, 1 February 2026 (UTC)[reply]
A lot to unpack here:We don't know what the specs of that device that loaded the page for 30 seconds were, and what software they use.We don't know if that device is one of the "ancient" devices that the user uses for browsing the web (what is "ancient"?). What they said does not exclude the possibility that they tested it on an iPhone 16 Pro or some modern PC for $2000+. We don't know what the "other pages" are.I'm the user in question: that particular test was with an obsolete Android phone from circa 10 years ago. I tried it today with a 2015-model Raspberry PI 2 that I bought in 2016 for about $30 (now past end-of-life, has been sitting in a non-climate controlled junk drawer for years) and was also able to successfully load the page and open the editor (first load on that machine took about 10 minutes, but subsequent loads took ~30 seconds, indicating that the slow first load was due to media loading/caching, not byte size as targeted by this proposal). I don't claim to understand your computer setup better than you do, but I'm just saying that you seem to have far more powerful hardware than I do, on a better internet connection, yet you seem to be getting worse results. --LWGtalk(VOPOV)02:22, 1 February 2026 (UTC)[reply]
OK, so that makes sense now. I mean, yes, obviously a Raspberry Pi will be less powerful than my computer. But contrary to what you say, my computer is not so bad as to be loadingUser talk:EEng for 10 minutes. It takes about 30-35 seconds on the first load (so no cache yet available) with browser freezing in the meantime or extreme difficulty to navigate any other part of the browser or the already rendered part of the page. With cache, this decreases to something like 15 seconds. It still is unacceptable behaviour. Say what you will about Google but they know how to code shit and know about reasonable expectations of performance, and also know a bit about UX/UI as well.Szmenderowiecki (talk ·contribs)09:18, 1 February 2026 (UTC)[reply]
It still is unacceptable behaviour. Ok, so it sounds like your experience is pretty similar to what I get on my primary devices. It seems like the core point of contention here is:should Wikipedia users be obligated to maintain their talk pages to provide aGoogle-levelindustry standard UI/UX experience to all conceivable hardware/browser configurations? to which the answer of the community appears to be matchingrecent North American weather with a resoundingno. --LWGtalk(VOPOV)16:37, 1 February 2026 (UTC)[reply]
You areasking the question no one was actually asking. The good/needs improvement/poor score is a score thatany website can get and these score are relevant for any website. It is not guidance for Google-owned sites only, it is guidance for all web sites. So no, Google-level UI/UX experience is something we probably should strive towards but this was NOT proposed as a requirement.Szmenderowiecki (talk ·contribs)16:48, 1 February 2026 (UTC)[reply]
Sorry for being unclear, by "Google-level" I didn't mean to imply only Google owned sites, just the best practices they advocate. Which is a fine question to ask, but the community seems to be comfortable with falling a few seconds short of that ideal. --LWGtalk(VOPOV)18:57, 1 February 2026 (UTC)[reply]
Also the top 99 contains only 19 users that are active (defined as having edited in the past 12 months) and not blocked, 2 indeffed users and 78 users who have not edited in the past 12 months. There is no reason to edit the talkpages of inactive and indeffed users.Polygnotus (talk)02:35, 1 February 2026 (UTC)[reply]
This discussion was opened two days ago (14:29, 29 January) so why does it already feel like a month? The section sizes template (which I don't trust for word count) tallies the discussion at 129,627 bytes and606 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]
Looks like it'sWP:SNOWing to me. The proposal seems too flawed to get much support, and the discussion seems to be mostly people sniping at each other or re-arguing whether slow old devices are actually slow and old rather than trying to work out something better. We can leave it a while longer if people want to see if it turns around, but I'd be surprised if it runs all the way until March.Anomie⚔03:59, 1 February 2026 (UTC)[reply]
I really don't like closing down discussions after two days. I don't want to feel like I have to check Wikipedia every day just so I don't miss some discussion that gets opened and closed while I am spending a weekend away from my computer. --Guy Macon (talk)05:07, 1 February 2026 (UTC)[reply]
Well, lemme see. I like the close-it-yesterday aspect of A, but I hardly see the point ofrequesting that someone waste their time divining a consensus. I think nothing good can come of B, and I find the claims that productive discussion is still happening downright ridiculous, although I enjoy the humor of SuperPianoMan's idea. Perhaps we should just leave it open forever. --Tryptofish (talk)19:42, 1 February 2026 (UTC)[reply]
I completely agree with this. Could the closing summary have been better? Yes. Did reverting the closure benefit the project in any way? No.Thryduulf (talk)21:19, 2 February 2026 (UTC)[reply]
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 – seeHelp: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 – seeHelp: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.
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 atWikipedia:Talk page guidelines#Personal talk page cleanup thatThe 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 beremoved. But this proposal does not allow drive-byremoval 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.
"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" andwp:own. "if the user has autoarchiving deployed, the archiving presumably must conform to the preferred choice of archiving by the user, correct?" - I think pages with auto-archiving can be excluded. "what if the user says: I only want discussions to be blanked, I don't want no archive box or any fancy bots?" - they should be blanked, then, not archived. "how do you address some editors' complaints that empty talk pages are uninviting" - can they explain why they are uninviting?sapphaline (talk)10:45, 1 February 2026 (UTC)[reply]
So something like this:
Current text
New text
Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions – seeHelp: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 – seeHelp:Archiving a talk page. Apart from the exception described in§ User talk pages, discussions should be archived, not blanked.Any person can archiveor 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.
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 notthat 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 withdiscussions 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.
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 editorrestored them. An admin then turned up torevert their action because it appears that this user has a developing tendency to disrupt. The problem is that Wikipedia is the encyclopedia that anyone can edit and so our editors have a wide range of (in)competence. As they cannot be relied on to agree on such matters or have the necessary skills and understanding, they should not be encouraged to mess with other users' personal workspace. The Wikimedia software ought to have a foolproof interface maintained by its professional staff and, if there are technical problems with it, there ought to be a properly professional system for reporting and resolving them.Andrew🐉(talk)13:50, 1 February 2026 (UTC)[reply]
with other users' personal workspace The problem with arguments like these is that I don't think such thing exists on Wikipedia, at least if we considerWP:OWN (No one "owns" content (including articles orany page at Wikipedia andWikipedia offers wide latitude to users to manage their user space as they see fit. Nevertheless, they are not personal homepages,and are not owned by the user. They are still part of Wikipedia and must serve its primary purposes; in particular, user talk pages make communication and collaboration among editors easier. These functions must not be hampered by ownership behavior.) A better descriptor would be "a communal workspace assigned to a user for issues relating to a user, with customarily large latitude at self-management"Szmenderowiecki (talk ·contribs)14:21, 1 February 2026 (UTC)[reply]
Oppose - There is no god-given right to talk to each and every other user on this website. Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user. Can't post an ANI notice on their page? Fine, then they don't get an ANI notice on their page. That's their problem. The notion of limiting all 250,000+ editors to some stupidly arbitrary and onerous rules, or letting busy-bodies mess with other people's talk pages, just because some editors don't want to wait for some talk pages to load, is ridiculous. Editors should not try to be so controlling of other editors.Levivich (talk)14:28, 1 February 2026 (UTC)[reply]
"Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user" - Wikipedia isn't a social media website; you can't opt out of communication in a collaborative project.sapphaline (talk)14:39, 1 February 2026 (UTC)[reply]
Yes. And template collaboration happens on template talk pages. And project wide collaboration happens on Wikipedia space talk pages. You don't need to talk to people on their user talk pages in order to collaborate with them.Levivich (talk)14:46, 1 February 2026 (UTC)[reply]
Yes conduct issues exist. You don't need user talk pages to resolve them. We have conduct noticeboards. If you didn't get a chance to discuss conduct issues with a user because their talk page was too long, that's too bad for them. It doesn't mean everybody else needs to follow new rules.Levivich (talk)16:13, 1 February 2026 (UTC)[reply]
The conduct boards have a giant notice saying that you must leave a message on the person’s talk page and that a ping is not sufficient, so I don’t think that would be acceptable.ExtantRotations (talk)23:35, 2 February 2026 (UTC)[reply]
FromWP:USER:User pages are forcommunication 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, andexist to make collaboration among editors easier. FromWP:OWNTALK:User talk pages must serve their primary purpose,which is to make communication and collaboration among editors easier.Szmenderowiecki (talk ·contribs)14:45, 1 February 2026 (UTC)[reply]
1) you're bludgeoning. You've posted these quotes already in this discussion. 2) you're not making any point here with these quotes.Levivich (talk)14:46, 1 February 2026 (UTC)[reply]
No, I'm rebutting a point which is obviously wrong according to current policy. Policy says this is the literal purpose of these pages. You may want to use pages not according to their intended purpose but that's your personal preference. I'm going to use these pages according to what they are for and which use policy explicitly endorses. And I should not be punished for asking that these pages be used for the purpose specifically outlined in the policy. I also don't believe that any argument to the effect of "let's allow users to force discussions in non-obvious forums because they don't want to do the housekeeping in the places where such discussion is intended to take place" complies within the general intent of Wikipedia policies and guidelines to promote discussion.Szmenderowiecki (talk ·contribs)14:53, 1 February 2026 (UTC)[reply]
None of our policies and guidelines sayEvery user talk page must load within a time frame acceptable to User:Szmenderowiecki. I checked EEng's user talk page (the longest on the website) on pingdom and it said 11 seconds load time. If that's too slow for you, too bad. It doesn't mean we need to have everybody else in the website limit their page sizes.Levivich (talk)16:11, 1 February 2026 (UTC)[reply]
Another problem with this proposal is that sometimes threads "2+ weeks without new messages" should still remain on a talk page. Sometimes returning old threads from the archives is exactly the right thing to do. To require those to be archived, or to prevent them from being un-archived, mass collaboration harder, not easier. Rarely have I seen "solution in search of a problem" as clear as this.Levivich (talk)14:44, 1 February 2026 (UTC)[reply]
There is no god-given right for any editors to have their user talk page be organized or contain any content that they wish it does. User talk pages exist for a purpose - to facilitate communication.Katzrockso (talk)20:00, 2 February 2026 (UTC)[reply]
Oppose all per most people above. There should be (and indeedare) already guidelines about talk page size, but they should remain no more than guidelines because there are far too many variables for a hard and fast one-size-fits-all rule to be useful, even if one were desirable (per most people above). If you need to post on someone's talk page to notify them about something then state that, with a ping, in whichever discussion you want to notify them about. Either they will respond to the ping or someone who can post on their talk page will leave a message on your behalf.Thryduulf (talk)14:38, 1 February 2026 (UTC)[reply]
Oppose all, with no small amount of annoyance. Seriously, if someone comes to my talk page and wants to blank it, that's OK, but if I revert even part of that, I'm violating policy? Now, I'm quite tempted to blank this VPP discussion, and would love it if I were empowered to do whatever pops into my mind, with nobody allowed to object (woo-hoo, I wanna be an autocrat!), but no, just no. --Tryptofish (talk)19:37, 1 February 2026 (UTC)[reply]
Oppose this and all future attempts to give random trolls power over what I can post on my talk pages:
(I have no problem with anyone bringing up any problems they have with my talk page at ANI and asking an admin to deal with them. That's why they get paid the big bucks.)[CitationNeeded]
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 youare strapped to a chair, etc., then let me address this message to your captors: First of all, keep up the good work. Secondly, please take away their keyboard. --Guy Macon (talk)19:44, 1 February 2026 (UTC)[reply]
PerWP: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 becomebogged 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 becausereason" would be sufficient to meet the requirements of method #1.Szmenderowiecki, you are in a unique position to be able to end the Rfc now. Would you be willing to do so? You are, of course, under no obligation whatever, and you don't even need to respond to this if you don't wish to. Cheers,Mathglot (talk)23:00, 2 February 2026 (UTC)[reply]
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.
Something I have seen often is professional public relations firm reps hinting or requesting they'd like their requests worked on by certain editors much like people specifying certain servers at restaurants based on past experience. I believe something that encourages randomized matching would benefit with protecting the integrity of neutrality. The concern I am seeing with the current system is serious potential for the formation of premediated "buddy system" planted by resourced public relations firms. Algorithm based random matching of requester and volunteer responder would prevent such collusion.Graywalls (talk)18:26, 2 February 2026 (UTC)[reply]
I was unaware this wasn't already protocol. If not, this layer of protection in terms of neutrality ieWP:5P2 seems like an obvious improvement.DN (talk)18:39, 2 February 2026 (UTC)[reply]
As an experienced Wikipedia editor who also submits COI edit requests from time to time (I have I think 3 of them open now) and has even answered a few of them, I'd have great concern about some sort of random-assignment basis. At this point, a request is going to be handled either by 1) someone who was already watching the article and saw it get posted, or 2) someone who chooses an article from the list. While 1) won't be changing under your request, changing 2 seems like it would have some problematic fall-out. If I'm looking at the COI edit request list, I'm not picking the first one off the list, I'm looking for something that I'm likely to understand the issues, so I might be more confident in my ability to handle a biographical edit request than a medical one. Removing my choice from that both discourages me from doing such edits at all (part of being a volunteer here is that i get to choose what I do) and is likely to assign me one on which I don't feel competent. Having already faced some competency issues with the people who choose to handle such things, I think we should be wary of exacerbating that. Plus, anything that discourages editors from handling the request backlog will only increase that already-sizable backlog, increase the lag in reasonable edits being added, and thus encourage folks to ignore COI concerns. And unless you eliminate the possibility of option 1, you'll still have a fair chance of bias in the editing. --Nat Gertler (talk)18:50, 2 February 2026 (UTC)[reply]
I don't think there's anything untoward about that. I've been asked before and I politely decline and say that there's a queue and someone will get to it. Unless you have evidence that reviewers are not properly applying PAGs, I don't see a need for any changes.voorts (talk/contributions)18:51, 2 February 2026 (UTC)[reply]
You will probably have my support if you tell "professional public relations firm reps" where to stick their COIs, but I haven't seen any evidence of a problem with the current system.Phil Bridger (talk)21:30, 2 February 2026 (UTC)[reply]
If I were a notable person who had no clue about how Wikipedia worked but noticed obvious errors in an article about me, I'd probably hire someone and want them to do it properly. There's no reason to be hostile towards people who are doing their job within the rules that have been set for them.voorts (talk/contributions)21:37, 2 February 2026 (UTC)[reply]
Without naming specifics, I can say public relations editing gets hairy at times. What does "within rules" mean? If a wealthy 65 year old man gets into a relationship with their granddaughter's 18 year old friend. In the US, government law considers such to be consensual relationship between consenting adults. While, legal, it is considered culturally unacceptable in most circles. A lot of strongly discouraged Reputation Management and PR edits that are technically within Wiki rules fall into that territory. Even practices that are considered acceptable in marketing and communications profession may not be on Wikipedia.Graywalls (talk)00:51, 3 February 2026 (UTC)[reply]
As I am aware, many editors who submit COI edits who notify specific editors target those who have worked on the article before or have responded to edit requests before. The reasons for this are understandable: these targeted editors are likely to be familiar with the subject, and are more likely to respond to an edit request in a timely manner, which is a definite concern for COI-request submitters who often have to wait months to even get an initial evaluation. This looks like a loophole, in that a plant could assist in this way as you describe, but in that case it would be a lot easier to just have the plant make the edit themselves without any declaration. If theydo decide to use the COI-request route, they would be under scrutiny anyway regardless of a planted assistant; talk pages are public after all, and COI requests getting snapped up instantly would attract attention. --Reconrabbit21:03, 3 February 2026 (UTC)[reply]
I just don't see this as a practical solution to anything. Even though the problem of COI editing is a real one, as noted, this would only stop PR firms from taking an approach that leaves a paper trail and invites scrutiny. And I think it's incompatible with the volunteer ethos of the project. You'd have a lot fewer editors if you were required to only edit randomly selected pages, you'd have a lot fewer reviewers if AFC reviewers were required to only review randomly selected drafts, and you'd have a lot fewer editors answering edit request with this policy.CoffeeCrumbs (talk)12:45, 7 February 2026 (UTC)[reply]
Many times I became a "regular" at some article with a declared COI editor. Reconrabbit described the real reasons, which are legit. I've never ran into someone expecting improper treatment.North8000 (talk)12:56, 7 February 2026 (UTC)[reply]
Since becoming more active in COI, I have worried about this issue. I focus on the oldest edit requests and clearing out the backlog. However, if there is some hidden priority system there could be a whole section of this content that I do not see. This discussion lacks data. I wonder if there is a way to get a histogram of all edit requests in the last year and the time it took between request being made and the request being closed. If this distribution is not exponential I suspect there is a problem. However, I am uncertain how to make such a distribtuion without a lot of programming. I may be able to write a Module if this if no one has a better solution.Czarking0 (talk)19:57, 10 February 2026 (UTC)[reply]
I don't think that'd be very helpful. I think you'd see 2 forces, FIFO editors like yourself and random editors who do newer requests (which are generally easier) and those in their topic area. MetalBreaksAndBends (talk) (contribs)20:07, 10 February 2026 (UTC)[reply]
And a third force, which is people who aren't going to the requested edit list at all, but are seeing the edit request because that page is on their watchlist or they stumble across it while editing the page for other reasons. --Nat Gertler (talk)15:54, 15 February 2026 (UTC)[reply]
Your best bet for finding a history of requests would probably be to look at the history ofUser:AnomieBOT/COIREQTable. You might be able to get the stats you want from looking at when things were added to and removed from that page, although you might lack information on whether a request was denied for needing more discussion or the like.Anomie⚔23:50, 10 February 2026 (UTC)[reply]
Clearly not appropriate. From a desktop, I can't even click on it. Needs blocking until they get it changed for something actually useable. Should be reported at ANI, not here though.AndyTheGrump (talk)17:48, 11 February 2026 (UTC)[reply]
Now that I'm thinking about it more clearly, I posted it here because I think it's a policy matter, i.e. it shouldn't have been possible for them to do that in the first place, and similar things should be made impossible.TooManyFingers(he/him ·talk)18:33, 11 February 2026 (UTC)[reply]
@TooManyFingers I've started the discussion for you -m:Talk:Title blacklist#Non-spacing characters. The page is only semi-protected (I'm not a meta admin either). I've not been able to work out what the settings for autoconfirmed are on Meta, your account is almost certainly old enough but you may need up to 9 more edits to that project before being able to contribute to the discussion.Thryduulf (talk)11:14, 12 February 2026 (UTC)[reply]
Hello. I am an editor of Russian Wikipedia, where arequest is currently being considered by the Arbitration Committee regarding the ipblock-exempt flag. I would like to ask you for a brief comment on how this process works in English Wikipedia.
In Russia, virtually all foreign sites and apps such as YouTube, WhatsApp, Facebook, Twitter, Telegram, etc. (but not wiki), are currently de-facto blocked.
In this regard, I have several questions:
If an editor from Russia applied on the English Wikipedia for the ipblock-exempt right, would it be possible to obtain it? (On Russian Wikipedia, it is currently effectively not granted to anyone.)
Is the inability or failure to properly configure a VPN (in such a way so that Wikipedia is excluded) considered grounds for denying the right?
If 70% of the editors and readers of the English Wikipedia were facing a similar problem, would the current CheckUser policy be adjusted?
The circumstances under whichWP:IPBE is granted here locally are covered on that page, specificallyWP:IPEC andWP:IPECPROXY. Considerable understanding is given to users who edit from certain parts of the world as the need is readily apparent.
Grants of IPBE here do not carry over ru wiki or any other Wikimedia wiki. In fact even a global exemption granted at meta only allows editing through global blocks but not any local ones; details atWP:GIPBE andmeta:IPBE.
Thank you, but I was not referring to the formally written rule; rather, I was interested in the practical application of this tool on the English Wikipedia. And yes, I am aware that the rules of the English Wikipedia do not apply to other language editions. I simply need a few opinions from participants of the English Wikipedia about how this process works in that wiki.Mitte27 (talk)05:58, 13 February 2026 (UTC)[reply]
The policy page caters for so many different situations, but I believe it covers the basics. We ask: do you need the right in order to edit, and will you abuse it. Assuming you've been around without problems for a few years (sometimes much less), the key question would be, is there an articulable need? We are not usually impressed by something like "I can't be bothered to turn off my VPN", whereas something like "it's important I keep my VPN enabled", or "it's extraordinarily complicated", might be more persuasive, if true. Right now, we usually tell users who are using Apple Private Relay (and equivalents) to just find the settings and flip the switch. Because most of the time that's not a great cost. Or maybe it is? It's up to you to make the case. I'll add that it also helps, when making the case, to identify an example block being experienced. --zzuuzz(talk)06:53, 13 February 2026 (UTC)[reply]
Thank you very much for the clarification. I have one more small question: would it be considered an additional argument if, in a given country, not only websites and applications are blocked, but manyVPN services are also blocked, making it quite difficult to find one that works reliably on a permanent basis? Moreover, many of the remaining VPN services do not offer an option to add Wikipedia to a whitelist. I would also add that users in Russia are likely unable to pay for many VPN services, sinceWestern banking systems are not available in Russia.Mitte27 (talk)07:09, 13 February 2026 (UTC)[reply]
If someone is using a static VPN that isn't blocked, then they won't have a need. If their IP changes to a blocked range, they may have a need. Otherwise we are not usually interested in how you acquire the VPN. Does that answer the question? Another answer is to ask why VPNs are being blocked by the country. Using a VPN to access a site which is not otherwise blocked is probably not a great argument, but it may indicate other problems, such as intrusive (and consequential) surveillance or arbitrary access interruptions, which would be viewed as a need. --zzuuzz(talk)07:50, 13 February 2026 (UTC)[reply]
How can we avoid Wikipedia containing misleading information that makes people think Uyghurs and Tibetans are not Chinese dissidents?
I have found numerous misleading statements in Wikipedia articles using the phrase "Uyghurs, Tibetans, and Chinese dissidents," which may lead people to mistakenly believe that Uyghurs and Tibetans are not Chinese dissidents; I hope you can help me correct this to "Chinese dissidents, e.g. Uyghurs, Tibetans" or a similar expression!Uyghurs (talk)21:04, 15 February 2026 (UTC)[reply]
Could you give some examples? I have searched for that exact phrase and been unable to find even one article using it. And we shouldn't give the impression thatall Uyghurs and Tibetans are dissidents, although many may be.Phil Bridger (talk)21:31, 15 February 2026 (UTC)[reply]
Tibetans are Tibetans. Uyghurs are Uyghurs. Whether they qualify as 'Chinese dissidents' may depend on context, and to some extent on opinion. Wikipedia certainly isn't going to uncritically parrot the official position of the CPC on this question. We don't do that, any more than we parrot anyone else's position.AndyTheGrump (talk)21:43, 15 February 2026 (UTC)[reply]
Structural Concerns About AfC Review of Scientific and Technical Topics
The following discussion 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.
The following discussion has been closed.Please do not modify it.
I would like to raise a policy‑level concern regarding AfC’s handling of scientific and technical submissions. This is not directed at individual reviewers but at systemic issues that affect Wikipedia’s reliability as a global public resource.
Scientific notability does not follow media‑driven patterns. Scientists are not public figures, and publicity is often discouraged because it can compromise intellectual property, distort scientific communication, or encourage pseudo‑science. As a result, scientific impact is measured through scholarly citation networks, patent citations, industrial adoption, and peer recognition — not through traditional news coverage.
AfC reviewers, who are generalists, are not trained to interpret these indicators. This leads to technically strong drafts being declined because they lack news profiles, even though news coverage is not a meaningful metric of scientific significance. Conversely, less rigorous content may be accepted because it fits a celebrity‑based model of notability.
Additionally, scientific biographies necessarily include technical context. Frontier scientific work is not common knowledge, and without explanation of methods, frameworks, and contributions, readers cannot understand why the subject is notable. This content is not “fluff” or resume‑like; it is the core encyclopedic record of scientific progress.
I propose that AfC develop clearer guidance for evaluating scientific notability, encourage deferral when reviewers are out of depth, and collaborate more closely with relevant WikiProjects. These steps would help align AfC practice with Wikipedia’s mission to provide accurate, balanced, and comprehensive information.U249601 (talk)01:00, 16 February 2026 (UTC)[reply]
The AFC process is optional except for editors with a conflict of interest (or who are required to use it due to community sanctions). Additional instruction/policy creep seems undesirable and editors with a COI are well advised to learn what's necessary to justify notability.Jahaza (talk)01:09, 16 February 2026 (UTC)[reply]
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.
What's the difference between these two things? I ask because I recently nominatedDomkino for deletion (seeWikipedia:Articles for deletion/Domkino based on the fact that it was a DAB page consisting only of redlinks, and I received some strong pushback indicating that this is not, in fact, a DAB page, but is instead at "set index article" (and was marked with{{Set index article}}. But my reading ofWP:Set index article indicates that an SIA should be a fleshed out article about a broad topic that may have many links to specific articles (such asDodge Charger, which broadly describes the brand, and links to many articles about specific years and sub-models of that car). But there is not broad discussion of the topic atDomkino, merely a set of links to specific places named Domkino. So where does the difference lie?WikiDan61ChatMe!ReadMe!!15:25, 16 February 2026 (UTC)[reply]
Someone had mistakenly added an unrelated red link "Dom Kino" before you nominated it for deletion, so it didn't look like a set index article at the time. For the variations in set index articles, look atSpecial:WhatLinksHere/Template:Set index article. That template tag at the bottom of the articles is there to help make it clear to editors adding new material but didn't work in this case.StarryGrandma (talk)18:33, 16 February 2026 (UTC)[reply]
A DAB is a navigation aide to help readers find an article about a topic they are looking for when there are multiple articles about various topics with similar names. A set index article is a list of instances of a particular topic with the same or closely similar names, which attempts to be a complete list whether of not an article exists for each instance. There is overlap, but I think there is a significant distinction.Donald Albury20:18, 16 February 2026 (UTC)[reply]
Ultimately the only reason that set indexes are a distinct thing from disambiguation pages is that a sufficient proportion of editors who maintain disambiguation pages care about adhering to the very rigid disambiguation page style guidelines over being flexible enough to accommodate messy real world. In reality there is a single continuum from prose articles that contain a list through prose articles that are mostly list, list articles that contain a large amount of prose, list articles that contain minimal prose, set index articles, to disambiguation pages. Where you draw the lines between them is arbitrary.Thryduulf (talk)22:19, 16 February 2026 (UTC)[reply]
Polygnotus (talk)20:21, 31 January 2026 (UTC)[reply]