Template talk:Setup auto archiving

Default archive size

100K might have made sense when this template was created back in 2012, but is painfully little now. Making a moderate increase to 150K, a number that seems fairly commonplace. CapnZapp (talk) 14:44, 11 September 2021 (UTC)

@CapnZapp I'd err on the side of safety and keep it at 100K: archive pages can take a while to load for some users and it doesn't cause much (any?) harm to have a few more of them. ― Qwerfjkltalk 20:40, 7 November 2021 (UTC)

If someone is having a problem with 150K archives, you may want to let them know that Windows XP hasn't been supported in over a decade.

In the interim, I've updated the docs to let ne'er-do-wells that may wander by that the default is just that, a default, and that larger values may be better for higher traffic pages. —Locke Cole • t • c 06:12, 15 September 2025 (UTC)

Locke Cole, see Wikipedia:Editing on mobile devices. — Qwerfjkltalk 10:14, 15 September 2025 (UTC)

Thank you, User:Qwerfjkl, but I didn't see anything relevant to page size on that page? CapnZapp (talk) 15:50, 15 September 2025 (UTC)

I am not sure I agree with the (recently added) "om some pages ten times more than the default is appropriate". While I'm sure such archives exist, 1000K is a lot.

I wish we could agree on setting the default to 150K. One advantage would be the descriptive text could allow for both smaller and larger archives. I've seen 100K and 75K - the biggest issues are intertwined: you simply get very little discussion for your click. Especially on a desktop monitor it feels annoying to have to change web page for every other discussion. On the other hand, more than 300K and the pages start to get really unwieldy, with very long Table of Contents and frustratingly long scrolling distances.

As for mobile, I am fully aware more people read Wikipedia on a phone or tablet than desktop. But the vast majority of serious editing is still done on desktop. Lots of mobile editing are done for sure, but most of it is of the simpler sort. Are we sure we're prioritizing correctly if we adapt talk page archive size for mobile? Any task an editor performs where talk archives are involved to me is not the basic editing task most people do on phones. If you need to read through the archives of a talk page, are you not very likely to use a computer?

Anyway - my preferred recommendations would be to use a default of 150K as a starting point, and recommend editors to use values between half that and double that (values below 75K or above 300K probably should not come recommended, even if they are certainly the best for some obscure special case).

Regards CapnZapp (talk) 16:02, 15 September 2025 (UTC)

WP:AN/I is where I was coming up with the 10× value. It is currently set to 800K though so I suppose 8× would have been more accurate. We recently had an editor attempting to split archives into smaller 100K sizes because of this default value, so some note seemed necessary. Feel free to massage the value to something more reasonable like 5× (especially if the default is changed to 150K). —Locke Cole • t • c 18:14, 15 September 2025 (UTC)

I thought as much, which is why I also said While I'm sure such archives exist... and they are certainly the best for some obscure special case!

My point is that we do not have to, and indeed should not, include in any general recommendation any outlier/extreme values. That is, just because something exists (and is justified to exist) doesn't mean it is a good idea in general. For the very few Wikipedia pages with traffic much MUCH higher than pages set up by regular users a completely different value (such as 800K) might be entirely justifiable, but there's no reason to include that in a recommendation. Especially one targeted to relative newcomers (such as users of this help template, who prefer not to learn how to set up archiving manually).

I would therefore maintain that anything significantly outside 0.5× and 2× (for 150K that would be 75K to 300K) is something we should actively avoid recommending. I think 5× is too much even for a default of 100K (and 5× 150K = 750K is definitely a figure we should not recommend). Again, I don't mean it should never be used - I mean we should never recommend it, and leave the exceptions to cases where the editor isn't deciding based on a help page for a newbie template. This is not a technical specification of possible values. This is a guide to probably useful values.

Cheers CapnZapp (talk) 11:34, 16 September 2025 (UTC)

Special:Search/insource:"Template:Setup cluebot archiving" and Special:Search/insource:"Template:Setup auto archiving" suggest the former is used about 4 times as much, probably because Help:Archiving (plain and simple) used it for years, though it seems to have changed a few months ago. — Qwerfjkltalk 14:54, 17 September 2025 (UTC)

CapnZapp, the specific section I was referring to was Wikipedia:Editing on mobile devices#Editing performance. My personal experience of looking at archives is just to view a single discussion (rather than multiple ones as you seem to). If you need to read through the archives of a talk page, are you not very likely to use a computer? Maybe? Who can say. I suspect the type of people do so will be the less vocal sort anyway. — Qwerfjkltalk 14:47, 17 September 2025 (UTC)

• I find it discouraging that, at this late date, people still treat wikisource size (i.e. as seen in edit histories) as some kind of proxy for page load times, when in fact load time is dominated almost completely by the number and size of images on a given page. Since talk page archives don't have images, the load time argument is a red herring. As to the "unwieldy, with very long Table of Contents and frustratingly long scrolling distances" thing, well, there are two ways talk archives get used:
  • (1) You're following a link to a specific thread. The link takes you directly to the conversation you want. No TOC, no scrolling involved. Doesn't matter whether the page is big or small.
  • (2) You're searching the archives to find a vaguely remembered old conversation, or to reconstruct the history of some issue as reflected in a series of threads over time. Here you'll be using <ctrl>F; again, no TOC and no scrolling. And, in fact, there really is a big advantage to a given talk page's archives having a small number of large pages instead of a large number of small pages. If you're <ctrl>-F'ing to find something you don't quite remember, or trying to find and string together a series of discussions over time that have touched on some issue, it's just FRUSTRATING to have to open 20 tabs and switch back and forth among them while searching for one string and then another, and even more frustrating to have to be switching around all the time when pulling together text from multiple old threads to use in composing a post for a current discussion.

  With an archive-page size of 800K, the entire history of Talk:MOSNUM for the past 6 years fits on four convenient pages; I can't tell you what a difference that makes when a thorny old issue reappears and we need to take stock of why the guideline is the way it is. By contrast, the prior 6 years of discussion is fragmented over a 21 pages (and the full 20-year history of Talk:MOSNUM is spread over a whopping 163 pages!). Numbers like that make using the archives in any significant way almost impossible.

The arguments against very large archive pages are vague, unsupported performance claims, but the argument for them is real. And BTW, the amount of traffic (posts per year, let us say) to a given talk page is irrelevant. If a given article's talk page gets just a few posts per year, and over 20 years they all fit on one archive page of 400 to 800k, that's great. Why split the discussions over 4, or 3, or even 2 pages, when you can have one-stop shopping? The default should be 900k (but if people really can't stomach that, let's say 500k). EEng 19:24, 17 September 2025 (UTC)

I would support any increase of the current default, the 150K CapnZapp proposes would be the absolute minimum we should bump it to, but I tend to agree with EEng that the benefits for larger archives far outweighs any claimed negatives. That said, I support 900K as my first choice, 500K as my second choice, and 150K as my last choice.

Like EEng, I can Ctrl+F or ⌘+F and find older conversations quicker on one/few pages vs. trying to find it on dozens or hundreds of smaller archive pages. —Locke Cole • t • c 19:55, 17 September 2025 (UTC)

I had a look at WP:MOSNUM's talk page archive. Archive pages are around 800K (sometimes 700K sometimes 820K etc) and feature about 75 or 90 talk sections each. That to me solves the fragmentation issue but nudges into unwieldy territory. Like when you encounter someone's talk page and they've never archived and you realize mouse scrolling to the end (of the TOC! not the end of the page) will take a small eternity. So while I appreciate the support (I too can't see why you would want to edit Wikipedia on a phone so feeble it can't even load a 150K talk page...) my personal choice would be 300K. The main reason I've fought for 150K is simply to avoid anything lower. CapnZapp (talk) 21:32, 17 September 2025 (UTC)

Just to add: please remember this is only about the defaults of a single template (and the example it sets, and the help instruction recommendations). I would strongly prefer that whatever number we settle on is used throughout the various pages of the archiving realm and not merely here. CapnZapp (talk) 21:35, 17 September 2025 (UTC)

"Unwieldy territory". Unwieldy how, exactly? No one scrolls down the TOC of archive pages. In what way are people wielding archive pages that is somehow made harder when they're big? Near the top of this thread someone said the default should be 100K so as to "err on the side of safety" -- safety against what danger, exactly? We're 1/4 way into the 21st century, people. EEng 03:47, 18 September 2025 (UTC)

Take your own talk page as an example of what I would consider clearly unwieldy, User:EEng. Even on a desktop computer over a 100Mb fiber connection, it takes noticeably longer to load than the average Wikipedia page. The table of contents is 291 items long. Page information says 960K. To me, that's massively unwieldy. What this tells me is that your conception of "unwieldy" is clearly not compatible with mine, and I would to strongly urge you not to assume your standards are even close to the mainstream. Regards, CapnZapp (talk) 10:16, 19 September 2025 (UTC)

We're 1/4 way into the 21st century, people. I still back up my favorite talk page archives to 1.44MB floppy disks, at least the proposed minimums won't make me upgrade my rig to CD-RW. =) —Locke Cole • t • c 04:01, 18 September 2025 (UTC)

EEng, someone said the default should be 100K so as to "err on the side of safety" yes, I said that. Long loading times are a pain to deal with, as many people who've visited your talk page can attest. It makes navigating and quickly flicking through the page difficult. People (even editors) view Wikipedia on a variety of devices. Maybe some pages need 900k archives, but the vast majority don't. I stand by 100k, and still think even 150k is too high, though I can see the opinion here is against me. — Qwerfjkltalk 20:52, 18 September 2025 (UTC)

A reminder: please remember this is only about the defaults of a single template. I would like us to use whatever number we land on at all related pages. For instance, the same and not a different number should be the default for {{Setup cluebot archiving}} as well. It should also be used as the default for any prominent quick-and-easy examples elsewhere, such as over at User:Lowercase sigmabot III/Archive HowTo and its "copy and paste for easy use" code at Example 2: Incremental archives. I'm sure there are more places. CapnZapp (talk) 09:47, 19 September 2025 (UTC)

Yes, we should synchronize this default recommendation across all pages, just as we have kept other parameters in sync.

Note that @Locke Cole has started setting the quick setup scripts to 400k Template:Setup auto archiving, Template:Setup cluebot archiving.

For the record, since no one actually brought it up, but just hitting F5 on any talk page with little content loads about 1.1 MB over the wire on average. Which really actually puts the whole "75k vs 100k" in perspective.

Just while I was typing this response using the reply tool, the async protocol that periodically saves the draft has transferred an additional 600kb of me writing these few words here.

So, I think 400k seems pretty reasonable and justified as it's basically overhead over the baseline that wiki just loads. Hitting send at 1.7MB. Raladic (talk) 10:08, 19 September 2025 (UTC)

Well argued. I’d say raising to 200k (as I initially boldly did) should be the bare minimum for today. I’d also be fine with 500k. I do think we should stay below 1mb as mobile browsers can start struggling a little bit to display that much text to be found (for some reason they seem fine with larger size images). Raladic (talk) 07:32, 18 September 2025 (UTC)

I'm most comfortable with a number in the 150-300K range myself. This takes into account the fact that the higher our local consensus ends up with, the higher the risk of push-back elsewhere. What I mean is, I genuinely think it will be easier to arrive at a compromise and a site-wide consensus if we suggest 150K or 300K rather than, say, 500K or 800K. This does not mean I oppose the currently active proposal of 400K, only that I think we might be pushing our luck, as it were. From my perspective, if we can even reach a consensus to increase every default and recommendation to 150K, minimizing the number of 75K or 100K archives, that's still worthwhile. Baby steps. CapnZapp (talk) 10:26, 19 September 2025 (UTC)

We have to remember that this is about archive pages, which see little traffic, especially for most run off the mill articles. They may not even get anywhere near 400k in 5-10 years.

Compare that to the extremely high traffic archive pages at say ANI, which due to the constant backrefs to previous discussions and such do actually get a lot of traffic. Those archive pages stand at 800k.

which combined with the bare scaffolding from wiki as I mentioned above, which are up a blank talk page at about 1mb, puts the total page load somewhere in the 1.5-2 MB range, seems entirely reasonable. So I really think that if we think long and hard and do a bit more than the quick napkin check I just did to validate average page loads, we’ll still likely arrive at the fact that the couple KB of text are not what bloats a page load.

It also very much drives home the point that search is ubiquitous as no one would dare to manually scour the 1200 archive pages of ANI, or even just a single one Wikipedia:Administrators' noticeboard/IncidentArchive1199 by hand.

There are really only so many editors that really care about the default parameters with reasonable data based arguments.

So as long as we have a reasonable verifiable local consensus here to reference back, we can probably avoid another pile on if we can link back here and remind people that we should not spend too much more time on picking the right color for the bike shed.

At the end of the day, archive pages are there to serve talk pages from getting too big, not the other way around, so in the context of the auto archiving, having the smallest common denominator of threads on the talk page to not overwhelm the active talk page is infinitely more important than how big an archive page is that may see very few visitors. I just plucked another random archive pages from ANI to check the traffic reports - traffic 863 - it has existed for 10 years, has a daily average of about 1, with the spike value somewhere around 30 visitors on one day. The size of that page is 700kb and has been so for the last 10 years.

I think the more time we invest in this and the deeper we dig into the data, the more this conversation really does seem to lean into we’ve over engineered our shed already, I think we should go with Vantablack, as an allegory of most archive pages seeing about as many visitors as the darkest shade of black reflects light. Raladic (talk) 11:03, 19 September 2025 (UTC)

minthreadsleft

Raladic I'm not making sense of your edit summaries you use to justify your changes:

The 4 for ToC is old news. This isn't true since WP:VECTOR2022 anymore and even just 1 section will show a TOC.

What is "old news" and what isn't true?

minthreadsleft to 2 in line with more common usage nowadays

Says who? Who's common usage?

Generally, you fail to argue what makes |minthreadsleft=2 better. In fact, what makes it so much better for users of the new Vector skin that this justifies the inconvenience for editors still using legacy Vector?

A setting of |minthreadsleft=4 not only ensures a TOC for users of every Vector, it also leaves a healthy sampling of past discussions. This is considered friendly by many users including myself.

Of course I can see instances where old discussions are undesirable, but here we're talking what recommendations we want to give our users, especially the presumably non-power users that use templates instead of setting up bot config themselves.

I suggest we settle on |minthreadsleft=4 as a good-practice number for the general case. Individual editors can easily override the defaults if they wish or need to. CapnZapp (talk) 11:36, 28 August 2025 (UTC)

I don’t know what doesn’t make sense to you here.

As of 2023 there is basically no vector legacy users - Wikipedia:Vector 2022#The Vector 2022 skin on English Wikipedia, so it should not optimize for a case that does not exist. There are some people that use other skin such as mono book, but not the vector legacy skin, which basically is just gone. So you cannot argue that it’s better for uses of vector legacy if there is no statistically traceable users of such remaining.

As for why four is too much, if you regularly jump to articles that don’t have any archiving set up, which is the point of this template, you can find pages that have four or sometimes even more threads and they’re all from a past decade, which just does not serve users that land on such a page because they will just be like” OK. Why is there all these old discussion?”

Uses are used to searching stuff nowadays, not reading through endless amounts of old threads manually. So pruning discussions to leaving to behind, but any completed discussion that has concluded and has been untouched for 90 days, aka not a single comment has been made in three months, is likely not going to serve future users who just landed on this talk page, as again, they’re not likely to go manually read over countless threads. And having a large number of really old threads is usually intimidating, because it could mean that people don’t really care about this article. They are likely to use the search archives function of a talk page header however, given that we use uses are taught to use search nowadays, thanks to Google, Bing and co, and now more recently AI prompts which are entirely search prompt based. Raladic (talk) 15:54, 28 August 2025 (UTC)

I don’t know what doesn’t make sense to you here. Several things.

While I'm sure the adoption rate is greater than the actual data behind your linked graph, are you aware you are linking to a 2023 data set where the English adoption rate for Vector 2022 is 2.32%? The overwhelmingly large pie slice (94.76%) is for the Vector skin. (I won't argue it is solely the legacy Vector skin, but I suspect it is).

Even assuming Vector 2022 is 44.2%, as a legacy Vector user I find your stance unacceptable. You need to be much more careful - several orders of careful in fact - before you spout nonsense such as there is basically no vector legacy users, a case that does not exist, the vector legacy skin, which basically is just gone and, especially, there is no statistically traceable users of such remaining (which you would have found hilarious if you sat in front of my keyboard, looking at Wikipedia using the legacy Vector skin).

But never mind. I'll simply revert your uninformed changes, not even bothering to argue the bigger issue: even if Vector 2022 were all-encompassing, I still don't find your arguments persuasive; that is "4 = bad but 2 = good", so good in fact that we simply must change our long-standing recommendation. CapnZapp (talk) 17:19, 28 August 2025 (UTC)

are you aware you are linking to a 2023 data set where the English adoption rate for Vector 2022 is 2.32%? No, I wasn't, mea culpa, I assumed that the legacy vector is the small unlabeled red sliver at the top of the graph. So if that's not the case, we should probably not have this graph there as it's really rather confusing since the number you mentioned doesn't appear anywhere on the page, or the graph, so should probably clean that up.

which you would have found hilarious if you sat in front of my keyboard, looking at Wikipedia using the legacy Vector skin). - I didn't say there are none, I said "basically no", just that the graph didn't show more than the red sliver, which I thought was where those were in. So again, as above - based on confusion caused by graph as labeled (so it wasn't spouting nonsense, as much as getting mislead by the page/graph.

Anyway, in light of this, fair enough, if the legacy skin is in fact still used more widely, then the 4 makes sense and the other point is moot for now, so agree that there's no need to discuss it further at the moment.

Thanks for pointing out the misunderstanding and reverting the change to 4 for default. Raladic (talk) 18:10, 28 August 2025 (UTC)

Template docs overhaul

@CapnZapp - since you were starting to update some stuff on the Template:Setup auto archiving/doc page, just want to stop you there, since the unstructured mess that the current Usage section is doesn't serve users well. We should instead create a proper {{TemplateData}} Parameter section, which has a suggested values for enums/numerics and a type column for booleans, numbers, enums, and an optional/requred/suggested column. You can check out Template:MOS-TRANS/doc which I overhauled a few days ago as a template to follow, or I'm happy to do it tomorrow or over the weekend. Raladic (talk) 10:16, 19 September 2025 (UTC)

Message received. You can go ahead. Thanks CapnZapp (talk) 10:18, 19 September 2025 (UTC)

Will do, for now, I go to bed :) Raladic (talk) 10:20, 19 September 2025 (UTC)

Synching defaults

Now that this page appears to have settled down a bit, let's see which pages are relevant for archive bot defaults, and what defaults those pages currently suggest. Parameter names can vary; using the same names here for ease of comparison.

{{Setup auto archiving}} (this template)

|age=90 days |size=400K |minthreadsleft=4 |minthreadstoarchive=1

{{Setup cluebot archiving}}

|age=90 days |size=400K |minthreadsleft=4 |minthreadstoarchive=1

Lowercase sigmabot How-to

|age=30 days |size=150K |minthreadsleft=4 |minthreadstoarchive=1

Help:Archiving a talk page#Choosing a bot

|age=90 days |size=200K |minthreadsleft=5 |minthreadstoarchive=2

Note instructions such as Article talk page threads should not typically be archived in less than 30 days except for very busy talk pages. Of special note is Each individual archive should not be larger than 512kB, because this may cause accessibility problems for some devices. and Because a large batch of threads can "overshoot" the maxarch[ive]size parameter, the parameter should always be set lower than the maximum acceptable archive size.

User:ClueBot III/JustArchiveThis

|age=90 days |size=0 (zero meaning "no limit to size" - everything gets archived into a single file) |minthreadsleft=0 (meaning the talk page will be emptied out if all sections are old enough) |minthreadstoarchive=0 (meaning the bot will run as soon as there's anything to archive)

For comparison, the actual code defaults (these don't matter at all, assuming everybody supplies parameter values when setting up bot config):

actual code defaults (Lowercase sigmabot)

|age=24 hours |size=1000M 😯 |minthreadsleft=5 |minthreadstoarchive=2

actual code defaults (Cluebot)

AFAIK, defaults are zero - the bot will archive everything into a single archive a.s.a.p

Related:

{{Archive basics}}

|size=150K

{{Please archive}}

No specific numbers discussed

{{Archive request}}

This template concerns itself with the size of talk pages, not the size of any archives.

Still, it considers only page sizes of less than 75K to be completely within guidelines. Already at 150K it considers a talk page "very long" and at 225K it exhibits an angry red border. This does not seem to be congruent with our message that archive pages can be 400K. I mean, sure archives are not used as frequently as main talks, so archives can be larger, but more than four times larger? (I believe that, in isolation at least, 75K makes sense if archives are 150K. Now that archives are more than twice as large, maybe talk page guidelines should also be twice as large...?)

Also, 75K is so small, you can run into a conflict between "keep at least four sections" and "archive because size is too large".

In this regard, I feel it is important to note how WP:TALKCOND/WP:TALKSIZE does not actually prescribe any specific size limit since March 2025 (discussion: Wikipedia talk:Talk page guidelines/Archive 17#Limit)

{{Uw-archive}}

A user warning template apparently considered fine to apply already when someone's talk page exceeds as little as 75K(!) Personally I don't see how it would be okay to deploy this earlier than the angry red border of the previous template, and that's currently at three times this limit.

I have probably missed a few instances of Wikipedia suggesting config params, so please add them. I did see HBC Archive Indexerbot but don't think it performs any actual archiving. Thanks! CapnZapp (talk) 12:16, 5 October 2025 (UTC)

CapnZapp, I think relitigating this debate in a bunch of places is a waste of time and prone to WP:LOCALCONSENSUS; if you really want to do so, hold an RfC. Though this feels like a WP:BIKESHED issue. — Qwerfjkltalk 10:18, 7 October 2025 (UTC)

Can you explain what you mean? Is it that you think I shouldn't bother with details you personally don't find relevant or interesting? Because I think that if we have settled on a recommendation (a default), we should consistently use that number everywhere we make that recommendation (default). Sure, it might be a bit of wikignoming, but surely the simplest resolution be that you... simply devote your energies elsewhere and leave me to it? I mean, if you actively contest my work here, that's fine, but that's not exactly what you're saying, as far as I can tell. As far as I'm concerned, I'm not "relitigating" anything. Instead what I'm doing (or at least, what I think I am doing) is: having awaited the new consensus of 400K to settle, I now have identified a number of places we should logically implement that same number. What's so wrong with that? (And please don't answer "I think you're wasting your time" because I believe you can trust me to be the judge of that) Cheers CapnZapp (talk) 10:38, 7 October 2025 (UTC)

As a comment, I would like to direct your attention to what I said earlier, up in #Default archive size: I'm most comfortable with a number in the 150-300K range myself. This takes into account the fact that the higher our local consensus ends up with, the higher the risk of push-back elsewhere. What I mean is, I genuinely think it will be easier to arrive at a compromise and a site-wide consensus if we suggest 150K or 300K rather than, say, 500K or 800K. This does not mean I oppose the currently active proposal of 400K, only that I think we might be pushing our luck, as it were. Just sayin'... CapnZapp (talk) 10:40, 7 October 2025 (UTC)

So, it seems I fell down this rabbit hole at an opportune time. And I have some details & data that I believe is worth adding, regarding User:CapnZapp's mention of using User:EEng's Talk page as a benchmark - so plz forgive a bit of verbosity here.

I am in MS Edge right now and it's been asking me to update for about a week. For political and financial reasons, the highspeed broadband in my apartment complex is Grade C+, at best - both in speed and latency. I have 263 browser tabs open (yes I am a recovering tab hoarder), including about 20 Wikipedia tabs - in part because I've spent 4+ hours trying to figure out exactly when Sigmabot's setup on Talk:ChatGPT was first altered to an interval of 30 days, (I think some time in 2024) and I had started to genuinely wonder if it was a deliberate attempt to manipulate consensus. Finally I started trying to go through the bot's setup instructions to find a guideline, and realized a better explanation is ambiguity around the phrase "very active talk pages." That's when I switched to digging my way through this thread to figure out where everyone is at. And since my PC is agonizingly old and slow (last rebuilt with low-end hand-me-down parts about 8 years ago), I tried opening User:EEng's Talk page in a new tab several (15ish) times, to see if I had any consistency in load time.

- 3-7 seconds; it never took Eeng's Talk page more than 7s, twice it was fully up in 3.

- I also spent at least 1.5 hours going back and forth, between just the main ChatGPT Talk page and its 2 Archive pages, trying to follow 1 subject across 3 or 4 threads. Threads that ultimately had all had activity between today (17 Oct) and mid-July.

As you might imagine, I now have some very strong opinions on setting consistent File size and frequency suggestions, which favor fewer Archives pages (voting for >=400k) and longer frequency (no less than 90 days) for most Article Talk pages. And that would include updating any consistently used documentation on setting up archiving, so they are all on the same standards.

I'd be happy to help with that last part, since knowledge building is one of my jams, as is the admin side of planning/coordinating a knowledge rollout. I could also plan more load testing, if anyone feels a consensus would be easier to achieve with more quantitative data - between fam and my sis' work I have access to dozens of diff devices, PC and mobile. Just Ping me! CleverTitania (talk) 12:02, 17 October 2025 (UTC)