User talk:Lowercase sigmabot III/Archive HowTo
| This is the talk page for discussing improvements to the How To guide for Lowercase sigmabot III |
|
Archives: 1Auto-archiving period: 2 months  |
Question about "minthreadsleft"...
edit0xDeadbeef, The Earwig, Σ - I am wondering why the following line in the "Parameters explained" table states:
- minthreadsleft - 5 - The minimum number of threads that should be left on a page (to prevent pages from getting completely harvested).
The choice of "should" makes the choice seem like it's written in stone, as if "5 threads always left on the article talk" is a Wikipedia Best Practice. I've seen active talk pages with 1 or 2 minthreadsleft (and varying lengths of auto-archiving) sitting in the archiving code, to keep the talk page from getting overwhelming and hard to manage. I'm not sure it matters if the talk page is completely harvested, I've seen plenty of empty article talk pages - if there's no ongoing/recent discussions, that seems fine to me. If there are no active/ongoing discussions, what is good/useful/encyclopedic about keeping months old or even sometimes years-old threads on the article talk page? Thanks - Shearonink (talk) 15:41, 10 May 2025 (UTC)
- It's an instruction telling the bot what to do. E.g. if minthreadleft is 10 then the bot should leave 10 threads on the page. I don't think we're meant to interpret 5 as a best practice, only a sensible default. You're welcome to change the wording to The minimum number of threads that will be left on the page or something if you think it's clearer.
- I don't have a strong opinion on how low it should be set. My guess is if a talk page is completely empty, a newer user might be less inclined to leave a comment, because it seems like no one else is. And if there are only a few threads and the talk page is short, there isn't as much benefit to archiving them. I'm generally of the opinion that unless the discussion is completely irrelevant (not just old – this is a judgment a bot can't make) or the page is too long to become difficult to navigate, it's worth keeping discussions around rather than trying to hide them. YMMV. — The Earwig (talk) 18:33, 10 May 2025 (UTC)
- I think it can be reduced to 4 to match higher up on the page:
- User:Lowercase sigmabot III/Archive HowTo#Example 2: Incremental archives
- I don't think it should be set to less than 4 on any talk page no matter how old the threads, or how busy the talk page.
- People move in herds, and if they see others have commented, then they feel freer to do so also.
- Also, I have seen many talk pages where some editors are actively trying to limit discussion and complaints about what they are doing. I have often moved the minimum back to 4, and pointed to here.
- --Timeshifter (talk) 19:45, 10 May 2025 (UTC)
First off, minthreadsleft is optional and can be left out entirely. Not saying you should, just that you can - the bot will simply take that as minthreadsleft = 0. I haven't checked page history so my guess is that 5 was just a number picked by sigma when the help was originally written. Yes, the "should" isn't directed towards the reader but the bot. If it's more clear we could change it into will, because there's no uncertainty here: if the minthreadsleft parameter is set to 5, the bot will leave (at least) five threads, full stop. Finally, the reason I prefer and recommend using a number that is 4 or greater is because the TOC (table of content) of any wiki page only appears (per default) when there are at least four sections. That is, any talk page with fewer than four sections won't have a TOC (unless you add one in manually). Since this makes the talk page appear significantly different than all the talk pages WITH a TOC, I consider it sufficiently confusing that I always make sure to add minthreadsleft = 4. Not a huge deal, but also easy to add. I don't think I'm only talking for myself when I say I am conditioned to expect talk discussions starting with the TOC. No TOC, and I'm momentarily confused, possibly thinking any discussions are something else than regular talk discussions. I imagine it helps (by avoiding confusion of the "where did the talk discussions go" when the page doesn't start with the familiar TOC) much more than it hinders (when minthreadsleft is used it potentially keeps more stale discussions on the talk than otherwise, though other params can result in this as well) - all in all my preference is to not abstain from using minthreadsleft. I think minthreadsleft = 0 isn't worth it, no prior discussions is decidedly not as welcoming to further discussion as some prior discussions, and I often make sure minthreadsleft is 4 (or more). I have no problems with the help page using 5 or 4 as its example number. Just as long as the number doesn't go below 4 I'm good. CapnZapp (talk) 10:30, 11 May 2025 (UTC)
- If having a TOC is a consideration - and yes I agree it's a layout aspect that our readers expect - I always use the magic word "TOC" - __TOC__. Having a TOC is useful - one reason being having one makes it easy to put a direct link to a separate discussion elsewhere. Though now I know the "should" is directed towards the bot, I misinterpreted the "should" as making the "5" seem like a firm prerequisite. So yes I am going to change the wording along the lines of Earwig's suggestion above, I think the set-up page could be misquoted as if the set-up page is a policy or guideline. Thanks, Shearonink (talk) 13:52, 11 May 2025 (UTC)
- I've edited the help instructions further. Defaults are what the program code defaults to - defaults are not recommendations. As far as I can see, the program code defaults to a minthreadsleft of 1. CapnZapp (talk) 11:52, 12 May 2025 (UTC)
- For clarification, especially for later readers of this thread, when we are talking about a visible table of contents showing up we are talking about Vector 2010. I mentioned that in the minthreadsleft section of parameters, and added the link too. --Timeshifter (talk) 11:40, 30 May 2025 (UTC)
- I've edited the help instructions further. Defaults are what the program code defaults to - defaults are not recommendations. As far as I can see, the program code defaults to a minthreadsleft of 1. CapnZapp (talk) 11:52, 12 May 2025 (UTC)
default is 2 if minthreadstoarchive parameter
editI simply think a value of 1 is:
- The expected behavior
- The only value that doesn't mean the bot's behavior needs explaining
- This How To isn't documenting a particular implementation; it's educating editors on how the bot works, including suggestions for useful parameter values
Cheers CapnZapp (talk) 12:32, 5 August 2025 (UTC)
- @CapnZapp:. I recently noted that the minthreadstoarchive default was listed as 1 in the default column of the table here:
- User:Lowercase sigmabot III/Archive HowTo#Parameters explained
- I corrected it to 2 per the source code you discussed elsewhere.
- The description column of that table gives various options and suggestions with reasoning. It could probably use more info.
- Are you suggesting that the default should be changed to 1 in the source code. If so, I agree. It would avoid the problem of people wondering why the archiving is delayed, and finding nothing in the bot code on the talk page to explain it. That happens when the minthreadstoarchive parameter is not listed in the talk page wikitext, and so the bot defaults it to 2. As discussed here:
- Template talk:Talk header#Reminder: minthreadstoarchive.
- Wikipedia talk:Village pump (proposals)#Archive bot was missing some parts.
- --Timeshifter (talk) 16:30, 5 August 2025 (UTC)
- A read-only copy of the source code may be found at User:Lowercase sigmabot III/Source.py. The defaults may be found by searching for
setUp(self)class Archiver:- if you want them changed, you need to attract the attention of Σ (talk · contribs). --Redrose64 🌹 (talk) 22:02, 5 August 2025 (UTC) amended Redrose64 🌹 (talk) 20:10, 15 August 2025 (UTC)- Redrose64. Thanks. What do you think of changing the default for minthreadstoarchive to 1? Please see the linked discussions. --Timeshifter (talk) 22:44, 5 August 2025 (UTC)
- I have no opinion on that. But the documentation should describe what the bot actually does, not what we would like it to do. I am frequently fielding questions at User talk:Σ because people have misunderstood the bot's actions. --Redrose64 🌹 (talk) 23:21, 5 August 2025 (UTC)
- Redrose64. Thanks. What do you think of changing the default for minthreadstoarchive to 1? Please see the linked discussions. --Timeshifter (talk) 22:44, 5 August 2025 (UTC)
- A read-only copy of the source code may be found at User:Lowercase sigmabot III/Source.py. The defaults may be found by searching for
I was discussing the practical HowTo examples. These should definitely describe what we would like the bot to do, not what the bot actually does (if left to its own devices) 🙂. After all, the page we're discussing is an how to article. Let's look at "Example 2: Incremental archives":
{{User:MiszaBot/config
| algo = old(30d)
| archive = {{SUBST:#titleparts:{{SUBST:FULLPAGENAME}}}}/Archive %(counter)d
| counter = 1
| maxarchivesize = 150K
| archiveheader = {{Archive}}
| minthreadstoarchive = 1
| minthreadsleft = 4
}}
Note how the HowTo article here suggests/recommends people to set |minthreadstoarchive=1. This is of course because if the parameter is left out, the code defaults to 2. Note that I can totally see legit cases where a value of 2 might be appropriate and useful. It's not that the value 1 is the only "correct" one, or that I necessarily think the default is "wrong".
As long as we keep recommending |minthreadstoarchive=1 I see no urgent need to get Σ to change the actual code. In those cases another value is warranted, the editor 99% knows what he or she is doing. More to the point here, I simply do not think it is commonplace (or happens like ever) for editors to set up Lowercase sigmabot archiving without including some value for minthreadstoarchive in their bot instructions. Leaving out the parameter from the bot configuration (or somehow klutzing the configuration, say misspelling the parameter name etc) is the ONLY way to get the code defaults in play, and I have just never seen that happening!
A similar reasoning applies to |maxarchivesize= as well. I almost never see a value outside of the 100K to 300K range, and in those cases, it almost always triggers a talk discussion of either the "talk archives are absurdly small and many" or the "talk archives are absurdly large and slow to load" varieties. In other words, should an editor leave out the maxarchivesize parameter I fully expect others to give pushback on that; the default value (nearly 2M) is severely out of whack with how we expect Talk archives to work. So in theory this is a huge problem and needs to be fixed urgently; but in practice I judge it to be a complete non-issue.
Should someone uninitiated stumble across this message, let me once again clarify that my chief impetus here isn't any of this, but to get the relevant templates ({{Talk header}} and {{Archives}}) to explain to users why the bot isn't taking action, when the cause of that inaction is because |minthreadstoarchive= has been assigned a value greater than one by the local page's bot configuration parameters.
Hope that helps illustrating my take on things; Have a nice un' CapnZapp (talk) 09:57, 7 August 2025 (UTC)
- Well then, since some people seem stuck in the mud concerning explaining things to users at Template talk:Talk header#Reminder: minthreadstoarchive, I suggest doing an end-run around the problem there by making the default "1" here for minthreadstoarchive.
- Redrose64 said: "I am frequently fielding questions at User talk:Σ because people have misunderstood the bot's actions."
- And I linked to an old discussion about a minthreadstoarchive problem at the Village Pump. The problems are more common than you think.
- So unless there is an objection I suggest User:Σ, and/or the other bot maintainers, change the defaults for all the parameters to those suggested at
- User:Lowercase sigmabot III/Archive HowTo#Example 2: Incremental archives.
- Then even new editors could create reasonably good talk archiving just by pasting in this:
{{User:MiszaBot/config | archive = {{SUBST:#titleparts:{{SUBST:FULLPAGENAME}}}}/Archive %(counter)d }}
- The bot will use the default settings for all the parameters. Which, if updated, would be good enough for most article talk pages.
- If {{talk header}} is already in use, then nothing else needs to be done since it has archive links and archive search.
- If not, then {{archives}} can be added. My preference:
- {{archives|banner=yes}}
- Pinging the bot maintainers: User:Σ, User:0xDeadbeef, User:The Earwig, and User:Enterprisey.
- --Timeshifter (talk) 14:51, 7 August 2025 (UTC)
- This edit notified nobody. It's explained at WP:MENTION. --Redrose64 🌹 (talk) 22:29, 7 August 2025 (UTC)
- Thanks Redrose64. Is there a Phabricator task about fixing this? Pinging in this new comment: User:Σ, User:0xDeadbeef, User:The Earwig, and User:Enterprisey. Please see my previous comments. --Timeshifter (talk) 02:34, 8 August 2025 (UTC)
- Apparently, pings/mentions aren't sent if a user page is a redirect. User:0xDeadbeef redirects to User:dbeef. So I am pinging User:dbeef in a new comment. Hopefully, the user name is updated near the top of User talk:Σ. --Timeshifter (talk) 03:36, 8 August 2025 (UTC)
- I for one don't have a strong opinion on what the default should be. I see arguments for it being "what someone would probably guess the bot would do if they didn't know any better", which is probably 1, and for "what is least likely to frustrate people who didn't think about it", which may be >1 since it avoids talk page churn. Probably I'd err on the side of not changing it unless we have a stronger consensus, but I'm happy to implement the change if we do.
- One thing I do have a stronger opinion on: Hopefully, the user name is updated near the top of User talk:Σ. This could be you! :) — The Earwig (talk) 04:11, 8 August 2025 (UTC)
- Looks like it has been updated since our comments. I had glanced at the wikitext earlier, and gave up when I couldn't find it quickly. Now with more time I see it is buried in a subpage. --Timeshifter (talk) 11:38, 8 August 2025 (UTC)
- @Timeshifter: There may be a phab task, but if there is it will have been closed as "wontfix". This is because the behaviour is intentional, I think that it's so that people don't get notified repeatedly when other people amend their own posts. I'm certain there was a recent discussion somewhere on-wiki, WhatamIdoing (talk · contribs) may know where. See also Help:Fixing failed pings. --Redrose64 🌹 (talk) 19:45, 8 August 2025 (UTC)
- Apparently, pings/mentions aren't sent if a user page is a redirect. User:0xDeadbeef redirects to User:dbeef. So I am pinging User:dbeef in a new comment. Hopefully, the user name is updated near the top of User talk:Σ. --Timeshifter (talk) 03:36, 8 August 2025 (UTC)
- Thanks Redrose64. Is there a Phabricator task about fixing this? Pinging in this new comment: User:Σ, User:0xDeadbeef, User:The Earwig, and User:Enterprisey. Please see my previous comments. --Timeshifter (talk) 02:34, 8 August 2025 (UTC)
- Timeshifter, did you read and understand my post? Changing the code defaults changes nothing, fixes nothing. In nearly all cases, the defaults never come into play. Regards CapnZapp (talk) 00:09, 8 August 2025 (UTC)
- AFAIK problems occur, but because the individual talk page bot config sets minthreadstoarchive to >1, not because the defaults do. The solution is to have the templates clearly explain to readers why the bot "refuses" to work. CapnZapp (talk) 00:13, 8 August 2025 (UTC)
- This edit notified nobody. It's explained at WP:MENTION. --Redrose64 🌹 (talk) 22:29, 7 August 2025 (UTC)
CapnZapp. Did you read and understand my comments? Did you read what RedRose64 said? Did you read the thread I linked to? People do leave out parameters. People are confused for that and other reasons. So defaults do come into play, and poor parameter choices.
I already supported your proposal at Template talk:Talk header#Reminder: minthreadstoarchive. And I said above "some people seem stuck in the mud concerning explaining things to users" at that thread. So until more people get involved your proposal is apparently going nowhere there.
My proposal allows newer editors to add talk archives with reasonably good parameter choices much more easily. Because the defaults are set to reasonable choices.
{{User:MiszaBot/config
| archive = {{SUBST:#titleparts:{{SUBST:FULLPAGENAME}}}}/Archive %(counter)d
}}
Thus lowering the confusion Redrose64 talked about. And avoiding some of the multiple problems with minthreadstoarchive and maxarchivesize. It won't solve all the problems, but it is a start. It's a win-win. I don't get why you are against it.
Hopefully things will get unstuck, and {{Talk header}} and {{Archives}} will (as you wrote) "explain to users why the bot isn't taking action, when the cause of that inaction is because |minthreadstoarchive= has been assigned a value greater than one by the local page's bot configuration parameters." --Timeshifter (talk) 03:04, 8 August 2025 (UTC)
- Why am against it? Chiefly only because it's a load of work you'd be hard-pressed to see completed. Not only getting Sigma or someone else to implement the code change. You would need to go through all existing bot configurations and remove settings to see the defaults in play. (Why otherwise go through the trouble of making a change to code, when it only helps those few cases you're talking about) And when you do, do make sure existing parameters (like minthreadstoarchive=2) aren't intentional (sometimes they are!), or you'd annoy lots of editors. So yeah. Now, if you're prepared to do all of that then I should give you that, technically, I'm not opposed to the change. I guess you could say I instinctively tried to help you avoid a huge morass. But now that I know you know what you're getting yourself into, let me clearly state: go ahead, knock yourself out. Best of luck, I honestly think you'll need it. Regards, CapnZapp (talk) 16:06, 9 August 2025 (UTC)
Section break
editI got a bit confused by what seem like competing proposals, so I'll try and state where I stand. From Redrose64's 23:21 5 Aug. post:
- But the documentation should describe what the bot actually does.
That is axiomatic, and I hope nobody disagrees with that. If the bot code defaults to 87 threads, then the doc should say it defaults to 87 threads. That is in no way a recommendation, it is a description of behavior.
I am mystified by this comment. :
- Changing the code defaults changes nothing, fixes nothing.
If you change the code default to 1, archiving behavior would instantly change on thousands of Talk pages with archive configs, and would immediately align with your "expected behavior" from bullet 1 of your OP (which I agree with, btw). I would think that is something you would want. (An advanced search or two would reveal the exact number of pages, if that would help.)
I support a change to a bot default of 1. It is not complex, it is a simple change to one character in line 365 of the bot. It is true that this is not backwards compatible in that archiving behavior will change on pages that accept the default, but since these are precisely the pages where no value was given, and will lessen confusion on those pages about bot behavior (according to opinion above, which I agree with), I do not consider the compatibility issue problematic in this case. If someone would like to organize an Rfc or informal poll to change the default to 1, I will vote to support. If you want me to write it, I will. Mathglot (talk) 18:21, 9 August 2025 (UTC)
- @Mathglot: Please do. As you wrote: "It is not complex, it is a simple change to one character in line 365 of the bot." --Timeshifter (talk) 20:19, 9 August 2025 (UTC)
- Timeshifter, Happy to do so. Just wanted to wait a bit and give CapnZapp a chance to weigh in first, in case he has a comment or prefers to delay before placing it. It would be good to go in as a united front, so it starts off with three Support's right at the top—probably make it easier to gain consensus that way. I would plan to open it as a discussion first, and only convert to Rfc if there is no obvious consensus after some time. I think the logical place to raise it is at WT:ARCHIVE, with a feedback request pointing to it from WP:VPT, but let me know if you see a better approach. Mathglot (talk) 02:20, 10 August 2025 (UTC)
- I have no strong opinion on the defaults or changing them. My position is borne out of not really agreeing with
If you change the code default to 1, archiving behavior would instantly change on thousands of Talk pages with archive configs
since just about every such page (that I have seen, at least) has defined all the parameters - I never really see the bare-bones config discussed above (where param values are left to their default values). So I assumed nothing (much) would change, because the defaults seldom (if ever) come into play. Aside: I've never used {{Setup auto archiving}} myself; if your experience is that it sees a lot of use, why not instead change the template to yield|minthreadstoarchive=1unless explicitly told otherwise? Again, I'd assume that makes it superfluous to change the code defaults... Especially since the real problem (again so I assumed) is that readers read the template archive bot notice, and don't understand why the bot isn't archiving their talk sections, chiefly because the templates still fail to explain that the bot might be inactive when|minthreadstoarchive=2or greater. Which isn't fixed by this, because minthreadstoarchive=2 is a legitimate setting that I myself is fond of using. minthreadstoarchive being set to >1 is the wrong problem to solve. So going through the trouble of changing the code wouldn't really be worthwhile (in my mind). I am not opposed to changing the code or its defaults per se; I just don't think it accomplishes very much. Just wanted to help a fellow editor avoid what I saw as a huge pile of work for very little payoff. Since you appear to know what y'all is getting into,knock yourselves out
. I should add that I really wished you spent all that energy on getting {{talk header}} and {{archives}} fixed instead; that, to me, is much more worthwhile - the defaults have never caused me any trouble whatsoever, since they're always overridden by local configuration (again, in my experience). And again, "if only minthreadstoarchive was always one, the problem would be solved" is misguided. minthreadstoarchive should be settable to 2 (or 10); it's just that we need better (read any) support explaining this to non-technical users that won't read page source. Hope that helps; thank you for a good discussion. CapnZapp (talk) 09:08, 10 August 2025 (UTC)- Hi, Capn; thanks for your message. One thing we agree on for sure, is that the doc could/should be improved. Other than that, the specifics of your comment made me realize that if there is going to be some proposal about this, then we should provide solid data, rather than just guessing how it is used. I am working on gathering data, but for starters, here are some responses to your points, backed by what I've been able to discover so far:
- So I assumed nothing (much) would change, because the defaults seldom (if ever) come into play
- The defaults come into play on 12,455 Talk pages (37% of all cases) including three of the top five pages with the most archives (more on this below).
- readers... don't understand why the bot isn't archiving their talk sections, chiefly because the templates still fail to explain that the bot might be inactive when |minthreadstoarchive=2 or greater
- I think this is undoubtedly true, and the template doc should be improved as best as can be, but many will still not read it, and I wonder how many outside STEM would really understand it even if they did read an improved version. The proposal is partly trying to do that, but runs into a wall-of-text problem; this is not an easy thing to solve, but I'd love it if you would take a crack at improving the doc. After it is improved, I would add a slightly scary-sounding sentence, like: "Do not use this parameter unless you understand the implications", and put it in bold font.
- minthreadstoarchive=2 is a legitimate setting that I myself [am] fond of using
- I tend to agree it is legitimate (although the data is making me waver a bit; more on that below). At this point, I would not be in favor of barring users from setting it to 2 if they so choose, as long as they understand the implications. Can you tell me when you use it, and what you perceive the benefits to be?
- minthreadstoarchive being set to >1 is the wrong problem to solve (bolded in the original)
- This proposal is not about setting it to >1; it is about the default value when they don't set it to anything. Otoh, the proposal (draft #1) is based on nothing other than my own opinion, and speculation about usage in the wild. That is a poor basis for a proposal, and is about to change, as I am gathering data to see how the param is actually used in reality. I will come up with a modified draft below, including some numbers to base my conclusions on, but mostly, I just want to expose the data to everyone, so they can draw their own conclusions based on something real and not mere preference.
- I am not opposed to changing the code or its defaults per se; I just don't think it accomplishes very much
- I respect that. I am gathering the numbers to see exactly what it might accomplish. My hunch is that the main thing it would accomplish, is to immediately put an end to a majority of user questions of the type, 'Why isn't my page being archived?' and 90% of such questions, where the culprit turns out to be minthreadstoarchive > 1.
- the defaults have never caused me any trouble whatsoever, since they're always overridden by local configuration
- If you override the defaults, you will never see a problem, before or after the implementation of any proposed change. In 63% of the cases (21,573 Talk pages) the default is overridden, just as in your experience; but that still leaves the other 37%, and my guess is, that that is where all the user confusion is coming from. Take the five articles with the greatest number of archives (202 for Donald Trump, down to 104 for Race and intelligence). Of those five, only two of them include the parameter, the other three do not. So, even among those top five most highly archived Talk pages, the param is not being used. And one might argue that it is being misused in the two cases where it is used, because in those two cases it is set to 1. I'm not sure why people use values >2 for the param (like 27 at Talk:Henry James), but if there was ever a reason to use a larger value for minthreadstoarchive at an article, the Donald Trump talk page with 202 archives is the one, to keep the bot from needlessly hitting the page every day or two as it is now, possibly even causing edit conflicts, and wasting disk read/writes. But even there, I question who would even notice a change, and who would gain, by upping it to 2, or even 5. (I can see no page in Wikipedia that would benefit from a value greater than 5, and even that is maybe too big.)
- So I assumed nothing (much) would change, because the defaults seldom (if ever) come into play
- Where it might make more sense to use the param with a higher value, perhaps, is at some really fast-moving page. So, let's look at WP:AN/I, with 1196 Archives. And, guess what? No minthreadstoarchive param there, either. The bot shows up once a day (occasionally 2x/day, like on 3 August) and always has more than one discussion to archive, sometimes five or more, because it is such a fast-moving page, so you don't need the parameter. On a really slow-moving page, you don't want the parameter set to >1, because stuff will just sit there forever; not that it matters much, if nobody visits the Talk page. So, if you don't need it on a fast-moving page, and you don't want it on a slow-moving page, then when do you use it to good effect? I am starting to wonder what the best arguments are for keeping the param aroud at all, as opposed to just removing it.
- Stay tuned for some solid data with links to back up what I am suggesting here. Thanks, Mathglot (talk) 22:32, 10 August 2025 (UTC)
- Thanks again Mathglot for all the work! So, "The defaults come into play on 12,455 Talk pages (37% of all cases)". I had no idea it was that many. It would explain one of the reasons why Redrose64 was "frequently fielding questions at User talk:Σ because people have misunderstood the bot's actions".
- I am wondering what is the maximum number of times a day that the bot looks at a talk page. If it is limited to once or twice a day due to server limits, then I see little need to keep the minthreadstoarchive parameter at all. A built-in default of one has little effect. I don't think twice daily action of the bot hurts anything. The bot is pretty fast, and so edit conflicts are infrequent. But the default setting of 2 is noticed, since it can take days, weeks, months to get that necessary 2nd thread above the cutoff number. --Timeshifter (talk) 23:05, 10 August 2025 (UTC)
- You could ask that question at User talk:lowercase sigmabot III, and I'm sure they'd tell you. I've never seen it more than twice a day on the fastest moving page I am aware of, and there only rarely. I can see why the default setting of 2 is noticed, especially on slow-moving pages, but I think part of the problem is the interplay between minthreadsleft and minthreadstoarchive, and how to describe that to someone in a way that makes sense, and doesn't seem like hopelessly nerdy minutiae.
- The other part of the problem, is to concretely indicate where the benefit lies. If we have a user-configurable param, that implies that different param values are suitable under differing circumstances, so that adjusting the param up or down works better on this page or that page. What are those circumstances, and which are those pages?
- Imagine that you are playing devil's advocate, and you are tasked with making the case for keeping minthreadstoarchive, and giving two or three examples where setting the value to 2, or even 3 or higher, is a good thing, and others, where 1 is better. What article talk page would you pick as an example of one that benefits from a 2 or 3 value? A fast-moving Talk page? A slow one? Somewhere in between? And once you make your pick, describe how that is the right value: what advantage accrues to the users of that Talk page, by setting the value to 2 or 3?
- If nobody can make the case why it is better to alter the value on at least a few pages, then the parameter should be dropped. If we can make the case, then please lay it out for me. Btw, I am still not opposed to keeping the parameter around if others want to retain it for some reason; I understand what it does, I just wouldn't know what to do with it myself, as I see no example of a page that benefits from having a value different than one. That's another reason to have a wider discussion, as someone out there might have a great reason to use the param that I wasn't aware of. ANI is probably the best use case for a >1 value (it has 2 by default now) that I can think of, and I doubt anybody would notice if it was set to 1 or 3. I can't think of a single other page where it matters, and it probably doesn't matter there, either. Mathglot (talk) 23:42, 10 August 2025 (UTC)
- Before I post a more detailed reply, let me first state I am so very out of this discussion if all this ends up amounting to nothing more than "just get rid of minthreadstoarchive". All my efforts strive toward fixing the only problem anyone has reported - users not understanding when minstreadstoarchive > 1 prevents the bot from archiving their content; which I attribute to the relevant templates refusing to explain this. It's not hard; why some treat this as rocket science is beyond me. I will assume y'all see the value of this parameter (I see it relatively frequently; I ONLY see it used intentionally - that is, I can't recall even a single instance of the bot config relying on the code defaults); otherwise just tell me so I can stop wasting time and leave. CapnZapp (talk) 12:18, 11 August 2025 (UTC)
- @Mathglot I think minthreadstoarchive should almost always be set to at least 2, and on lower traffic pages would probably be better set to a higher value like 3 or 4. Setting it to 1 doesn't really really have any benefit that I can see. Bot edits add pointless watchlist spam and it's harder to follow the page history when most of the edits are bot edits of one kind or another. It's really not that important that the bots keep the pages emptied out.
- For the most part readers shouldn't look at or care about these settings. (Unless the bot is misconfigured and cleans out new topics too quickly, in which case someone should come and re-configure the bot to be less aggressive.) –jacobolus (t) 18:47, 18 August 2025 (UTC)
- Strong disagree. Setting it to 3 or 4, and the minthreadsleft being set to say 4 means there would have to be 7 or 8 threads on the page before anything gets archived.
- This regularly results in some talk pages having ancient discussions from 10+ years there, which serve no one as their relevance is very rarely useful and is much better served to be cleaned up into the archive on the off-chance that someone brings up a point from 10 years ago. Raladic (talk) 19:42, 18 August 2025 (UTC)
- Yes, but these subtleties just go to show that we cannot reasonably expect most editors to understand the interaction between discussion age, minthreadsleft and minthreadstoarchive. It's tricky even for the people who think about it a lot. Mathglot (talk) 09:45, 20 August 2025 (UTC)
- Hi, Capn; thanks for your message. One thing we agree on for sure, is that the doc could/should be improved. Other than that, the specifics of your comment made me realize that if there is going to be some proposal about this, then we should provide solid data, rather than just guessing how it is used. I am working on gathering data, but for starters, here are some responses to your points, backed by what I've been able to discover so far:
- I have no strong opinion on the defaults or changing them. My position is borne out of not really agreeing with
- Timeshifter, Happy to do so. Just wanted to wait a bit and give CapnZapp a chance to weigh in first, in case he has a comment or prefers to delay before placing it. It would be good to go in as a united front, so it starts off with three Support's right at the top—probably make it easier to gain consensus that way. I would plan to open it as a discussion first, and only convert to Rfc if there is no obvious consensus after some time. I think the logical place to raise it is at WT:ARCHIVE, with a feedback request pointing to it from WP:VPT, but let me know if you see a better approach. Mathglot (talk) 02:20, 10 August 2025 (UTC)
Proposal candidates
editHere is a first cut on how I might word a proposal to change the default of minthreadstoarchive. It is long. I would like to make it shorter, but there is a risk. The whole idea is pretty tricky, and even old hands like us have to be careful to say exactly what we mean, in order to be properly understood among each other, in this ___domain. Just popping out a three-sentence proposal is, imho, an invitation to a muddled discussion, and widespread failure to even understand what is being discussed, much less what the proposal is. So I broke it down into sub-sections: Background, Problem, Remedy, Implications. and Justification. Here is my first draft:
Mathglot draft 1 of bot default value change proposal
|
|---|
|
This proposal aims to change the default value for param minthreadstoarchive of archiving bot User:Lowercase sigmabot III from 2 to 1. Background: This bot is programmed to archive discussions after certain user-defined config thresholds have been reached, principally, the age of the most recent comment in a discussion. But there are other, perhaps less well-known params, such as The problem: All of the bot config params have default values, in case the user activates archiving without providing any values. The current default value for minthreadstoarchive is 2, and has been for a long time. However, this has caused users to complain at Talk pages and Help pages that the bot is not archiving their discussions, and why not? Often, the reason is that there is only one archivable discussion on their Talk page, and the missing minthreadsleft param takes on the default value of 2. These questions and user annoyance will never go away, as long as the default value is 2. Exacerbating the problem, is the fact that so many find archiving setup to be complex, that simplified procedures such as Template:Setup auto archiving were created in order to simplify it, and unless you override it in the template call, it takes the default value of 2. Remedy: The fix is simple: change the bot default value of minthreadstoarchive to 1. Implications: This change is not backwards compatible. All bot-archived pages that have a minthreadstoarchive param of any value, will continue to work as before. Bot-archived pages that do not have a minthreadstoarchive param, will see bot behavior change from waiting until there are 2 discussions before archiving anything, to archiving even if only one thread meets the remaining criteria (age, minthreadsleft). Justification: This change, even though not backwards compatible, will be a net benefit to almost everyone. Power users of archiving generally use all of the params, because who memorizes what all the bot defaults are for a given param, anyway. Those who are not power users may let them default, as they may be less comfortable with defining a config, and may find it confusing or intimidating. These are likely to be the very same users who get confused when the bot "isn't working", and have to have minthreadstoarchive explained, and the default value of 2 explained, and the current remedy explained, namely adding minthreadstoarchive to their config and setting it to 1. This is just a lot of unnecessary pain for everyone involved: those running into the "non-working" bots, and the editors always explaining the reason why. Setting minthreadstoarchive to a default value of 1 will fix all of that. Who suffers under the breaking change inherent in this proposal? Those users who: 1) neglected to provide any value for minthreadstoarchive in the config; 2) understand what it means; 3) expect it to default to 2; and 4) notice that the bot occasionally archives just one discussion, "even though only one was eligible, and not two, like the default requires". Is there truly anyone in that group? And if there is, the injury to them by changing the default value is far outweighed by the benefit to everyone else.
Survey
Discussion
|
If you can do it better or shorter, please add your version, or comment on how to improve this one. Ideally, I would like to see at least the three of us come up with a version we can all support, and then present it as a group. Thoughts? Mathglot (talk) 03:45, 10 August 2025 (UTC)
- Sounds good to me. Thanks for all the work! A radical(?) thought: We already agree among us to change the minthreadstoarchive default to 1. Or aren't opposed. So let's just do it. Let's ask if one of the bot editors will do it. That is to change one character in line 365 of the bot. --Timeshifter (talk) 20:33, 10 August 2025 (UTC)
- We can't just do it, because it is a breaking change. I think it should still be done, but that requires wider consensus, than just us. also, CZ is not of the same view, so it is down to 2; so hang on for the next draft. Mathglot (talk) 20:44, 10 August 2025 (UTC)
There will likely be a draft #2, with additional info and a new poll option to remove the parameter entirely, for those that may opt for that as the best path forward. I would have argued strongly against the latter just a short while ago, but in response to Capn's comment above, I have done a deeper dive and gathered data about where and in what way minthreadstoarchive is actually being used, and now I am not so sure as I was before. I still lean towards keeping it, but I believe some in the discussion will disagree, and they may lean towards removal; we shall see. I will add some data here soon, and you can draw your own conclusions. Stay tuned. (edit conflict) Mathglot (talk) 20:43, 10 August 2025 (UTC)
- It now seems unlikely that there will be a new draft proposal in the near future. See the threaded discussion in the next subsection. Mathglot (talk) 01:09, 13 August 2025 (UTC)
Miszabot/config data
editHere is some data about how many pages have a Miszabot/config to describe archiving params, and what namespaces they are in. Also, some data on the use of param minthreadstoarchive, as used in the Talk namespace.
Show stats about page counts, values of minthreadstoarchive, and more
| ||||
|---|---|---|---|---|
|
Page counts
Values of param minthreadstoarchive
Talk pages with a lot of archives
|
More to come. Mathglot (talk) 01:30, 12 August 2025 (UTC) updated (diff) by Mathglot (talk) at 23:40, 18 August 2025 (UTC) per this comment by Jacobolus;
- More great work. hastemplate came in handy for Help:Table searches of all the table help pages. For example, to search for places where sticky tables are discussed.
- So I see that almost 1800 talk pages use minthreadstoarchive set to 2 or above.
- Probably some people would be opposed to the bot archiving twice a day. So they choose 2 or above in hopes of minimizing that. I think it is silly, but if that's what they want who am I to block it.
- So I withdraw my proposal to eliminate the minthreadstoarchive parameter.
- I still think the default should be 1. Since 12,455 talk pages are allowing it to default. I doubt most of those pages consciously left out the parameter knowing how it would default.
- So that still leaves the problem CapnZapp focuses on: people being confused by why the bot isn't archiving threads that have gone beyond their "Best By" date, and need to be archivally composted. :) I agree with his solution. --Timeshifter (talk) 06:22, 12 August 2025 (UTC)
- I also think the default should be 1. For one thing, that would stop all the confusion; but there are other reasons to support that. Two questions: which solution of Capn's do you mean? And secondly, why do you withdraw the proposal to eliminate the param? I was against that at the beginning, but the more I look at it, the more it seems a reasonable option. Not ready to say I unreservedly support withdrawing it, but I am pretty sure if we open a wider discussion abut this, at least some people might want to vote for that, so we should offer that as an alternative. Mathglot (talk) 06:56, 12 August 2025 (UTC)
- I got pinged. But I don't understand why you insist on avoiding the core issue, and the obvious solution. My stance remains: changing the defaults makes no difference for pages where minthreadstoarchive is given a value, and that value is >1. I believe these (apparently 1461+) pages contribute a significant portion of the confusion, and thus: lots of work, very little payoff.To be very clear: the problem isn't that 1461+ pages set minthreadstoarchive to 2+. The problem is that this causes confusion, because the templates refuse to explain the situation. I strongly oppose removing the minthreadstoarchive parameter. Why not skip changing the code and instead attack the source = bot config that relies on defaults? Including
- A) write a one-time script to update the 12K pages you found that relies on defaults in one form or another to include giving minthreadstoarchive a value of 1? (This should face very little pushback; assuming you explain your action clearly. The amount of pages relying on the default supplying a 2 is probably exceedingly small, and also easily fixed by manually changing the parameter from 1 to 2 after your script's execution) Honestly that probably gets rid of most of your issue (but not mine). But if you want, you can keep at it with...:
- B) Tweak those templates people use to create archive bot config ({{Setup auto archiving}} and others) so minthreadstoarchive is always included, and always set to 1, except when explicitly given another value? This to help editors not recreate problems for themselves in the future. Again, a practical solution that doesn't involve first getting hard-fought consensus; just do it.
- C) In the same vein, simplify the Archive How To (this page) to much more clearly tell people to use #Example 2: Incremental archives since that avoids the problems altogether (and hiding everything else, for the corner cases where other archiving setups are warranted). To be frank, the current How To is a programmer talking to a programmer; and non-technical types are just overwhelmed by choice. Basically, I feel the community is best served by a brand new, vastly simplified, How To being written. The technical documentation (including all the parameters in every permutation) should be a different page than this How To. Anyway, this is just help text, and thus another example where no advance prep is needed, just edit the page.
- D) Don't forget about ClueBot III! Rinse and repeat, this time for its
|minarchthreads=parameter. - And most pressing of all, E) why not boldly change {{Talk header}} and {{Archives}} so their bot notices explain in plain language why the bot doesn't archive when minthreadstoarchive/minarchthreads > 1 and there is only one section to archive? (Just ignore the voices that claim this is rocket science; it definitely is not.)
- Once all this is done and done, you can F) change the code defaults at your leisure.
- Have a nice day, and I don't expect to have anything more to say on this matter, unless there's an RFC, in which case I'm sure you will courtesy ping us involved editors so I can basically copy this post there too. And oh,
bot archiving twice a day
has nothing to do with minthreadstoarchive; that would be the algo parameter being set to|algo=old(12h)If you don't understand why minthreadstoarchive sees usage, please do not discuss removing the parameter. CapnZapp (talk) 09:17, 12 August 2025 (UTC)
- I also think the default should be 1. For one thing, that would stop all the confusion; but there are other reasons to support that. Two questions: which solution of Capn's do you mean? And secondly, why do you withdraw the proposal to eliminate the param? I was against that at the beginning, but the more I look at it, the more it seems a reasonable option. Not ready to say I unreservedly support withdrawing it, but I am pretty sure if we open a wider discussion abut this, at least some people might want to vote for that, so we should offer that as an alternative. Mathglot (talk) 06:56, 12 August 2025 (UTC)
CapnZapp About how often the bot can run: I was referring to limitations by whoever is running the servers. For example, see:
It may not matter what people set the algo parameter to, if it is set to be more frequent than what can be accommodated by server and admin limitations. - (oops, brain fart. I mixed up parameters. --Timeshifter (talk) 03:15, 13 August 2025 (UTC))
Mathglot wrote: "I've never seen it more than twice a day on the fastest moving page I am aware of, and there only rarely."
Maybe that is because of algo parameter settings alone, and few people picking less than the default: 24h.
In any case I guess some people really don't like seeing the bot operate more than they consider necessary. So they use minthreadstoarchive set to 2 or above. That's fine by me, if they have consensus on the talk page. That means I no longer support eliminating minthreadstoarchive altogether.
But then that leaves your main problem. I support your solution of explaining what is going on via open text or tooltip text being added to {{talk header}} and {{archives}}.
But that is not my main problem. My main problem is the need to set the default for minthreadstoarchive to 1. Especially since it is so easy to implement: Changing from 2 to 1 in the template code. --Timeshifter (talk) 11:18, 12 August 2025 (UTC)
- Capn, you said:
I don't understand why you insist on avoiding the core issue, and the obvious solution.
- I'm not insisting on anything, I'm trying to see if there is consensus to bring a proposal forward to fix a problem, which I see as two-pronged:
- the waste of time on the part of senior editors who have to continually answer the same questions about how archiving works (e.g., 'Why isn't the bot archiving this page?'), caused by
- an archiving parameter, namely minthreadstoarchive, which is a) implemented with the wrong default value, and b) poorly understood.
- If you improve the doc that that might decrease some of the confusion, and you don't have to wait for a proposal or consensus to do it; just go for it; no need to wait for anybody's green light. But fixing the doc won't solve the underlying problem, because most users won't read the doc (or won't understand it). On the other hand, fixing the bot default value will fix all of the problems: no more confusion on the part of new editors, therefore fewer more repetitive questions at the Help boards and less time-wasting answering them. Best of all, it is trivial to implement.
- You said,
And oh, "bot archiving twice a day" has nothing to do with minthreadstoarchive; that would be the algo parameter being set to
|algo=old(12h)If you don't understand why minthreadstoarchive sees usage, please do not discuss removing the parameter.
I understand exactly how the parameters work, but maybe the reason we are having all this confusing back-and-forth is because you misunderstand what the archiving params do.I have lost track in all the back-and-forth and indenting and talk quoting who you are responding to, so let me just reiterate my understanding of param algo: The parameter|algo=has nothing to do with how often the bot runs or how often it is active at a given page. Param algo is the aging parameter that determines when a discussion is defined as stale, namely when the most recent comment is older than algo. You can run the bot once a week, once a day, or once a mimute, and it will not archive a discussion until it is stale. Params minthreadsleft and minthreadstoarchive are throttling params; they stop the bot from archiving a thread even when it is stale under specified conditions.- If you see me as avoiding the core issue, please lay out for me what it is. I see clearly what your proposed solution is, you've laid it out several times,most recently in the lettered points above. But I don't see what issue that solves. So, what is your core issue; can you spell it out?
- The advantages to my proposed solution are: solves all the problems in one stroke; trivial (one-line change in bot to change the default from 2 to 1); requires little or no explanation in the doc; very few people will even notice anything changed. Disadvantages: breaking change, requires wider consensus. Afaict, your proposed solution is complex: design and run new script, adjust archiving templates, update the doc, change {{Talk header}} and {{Archives}}, change the bot default. That is a long list, and none of it is necessary, except for the last item. But if I am missing the core issue, then obviously my solution would be worthless; so please define it. (Ts, sorry about the indent; I had already written this; may fix later.) Thanks, Mathglot (talk) 18:46, 12 August 2025 (UTC)
- Timeshifter, I think Capn might've been responding to you, not me, about the algo param, in which case my comment above is misdirected. You said,
Mathglot wrote: "I've never seen it more than twice a day on the fastest moving page I am aware of, and there only rarely."
Maybe that is because of algo parameter settings alone, and few people picking less than the default: 24h.
- If Capn's comment was directed at you and not me, then that would explain things. Repeating: algo has nothing to do with how often the bot appears on a page. The algo param is strictly about defining staleness, whether you set algo to 24h or 12h or 6h, won't change how often the bot appears. My comment about the bot rarely appearing more than 1x/day was strictly about seeing whether setting param minthreadstoarchive to a value higher than 1 would have any effect at all on busy talk pages like ANI. As every bot visit to ANI almost invariably nets more than two discussions (because there are so many that several go stale very day, on average) upping the param value to 2 at ANI would not change anything, except for the rare cases when a bot visit nets only one, but even those would not be noticed. That is what that was referring to. On non-busy pages, the throttling effect of the default value of 2 for minthreadstoarchive may prevent a stale discussion from being archived when expected, and make editors wonder why and ask questions about it at Help, and I think you and I are in agreement about this, and that defaulting to 1 will fix that problem. Mathglot (talk) 20:35, 12 August 2025 (UTC)
- Timeshifter, I think Capn might've been responding to you, not me, about the algo param, in which case my comment above is misdirected. You said,
- Capn, you said:
This section makes me start lose good faith in this discussion. You clearly aren't reading my posts closely enough when you write:
| “ | If you improve the doc that that might decrease some of the confusion, and you don't have to wait for a proposal or consensus to do it; just go for it; no need to wait for anybody's green light. But fixing the doc won't solve the underlying problem, because most users won't read the doc (or won't understand it). On the other hand, fixing the bot default value will fix all of the problems: no more confusion on the part of new editors, therefore fewer more repetitive questions at the Help boards and less time-wasting answering them. Best of all, it is trivial to implement. | ” |
- No, I have quite clearly stated that I'm not overly interested in improving the documentation, exactly for the reason you're telling me as if I haven't mentioned it already. I want the template bot notices to be improved since those are the only messages with any hope of being read.
- Fixing the bot defaults will not, I repeat not, I repeat not, I repeat not, I repeat not fix all of the problems. There's over 1800 pages where minthreadstoarchive is intentionally set up with a value of 2 or larger. Changing defaults does nothing when a parameter is explicitly set in config. There's nothing wrong with those pages. Nothing should change or be fixed on those pages. The only wrong is that the template bot notices fail to explain minthreadstoarchive.
Since this is the third or fifth time I'm repeating this message, I am leaving this discussion before I say something I regret. Don't reply or ping me further on this subject.
I strongly oppose removing the minthreadstoarchive parameter and I oppose working on the defaults before the templates has been fixed.
CapnZapp (talk) 23:42, 12 August 2025 (UTC)
- I won't ping you anymore, but it seems we are talking at cross purposes. In your letter C) paragraph above (@09:17), you go into considerable detail explaining what is wrong with the documentation on this page, and how to fix it. But now you say, "I have quite clearly stated that I'm not overly interested in improving the documentation". Sure, no problem; it's a volunteer project. I only mentioned it, because among the multiple solutions you mentioned, that is the only one that can be done without discussion, and it sounded from C) like you had given it a lot of thought and that you might like to see some progress made right away, if only in this one area.
- I am disappointed in how this discussion has proceeded. If it cannot be discussed calmly and without confusion among a small number of editors all of whom are technically competent and who have previous experience with archiving and with some of the issues surrounding its parameters, then I don't see how we are going to craft a proposal about archiving that would be sufficiently comprehensible to a general audience, that it might have a reasonable chance of resulting in a consensus. I think we should table the idea of changing archiving for now, and wait for some future opportunity.
- I am afraid that given the unchanging status quo, some volunteers will continue to be burdened by the same ol' archiving questions at Help boards, and if your cup runneth over, feel free to ping me if you need a break from answering them. In fact, maybe I will think about adding something to a FAQ, essay, or info template, so that we can just paste a link, instead of reinventing the wheel every time. Thanks, Mathglot (talk) 01:00, 13 August 2025 (UTC)
I had a brain fart about the algo parameter. I was thinking there was another parameter for aging out talk sections. Like "age" in ClueBot III. "Algo" isn't exactly a common meaningful word. I just discovered it is short for algorithm. I struck out my algo comments.
There are so many parameters between ClueBot III and User:Lowercase sigmabot III. I tend to copy sets of parameters from one talk page to another when I set up the archiving bot on a page. I don't have all the parameters memorized. I have to look them up sometimes.
I don't know how we expect average editors to make good choices for all the parameters, when editors with 52,000 Wikipedia edits (me) have to go back to the documentation so often.
That is why I want good defaults that work for the majority of pages. Starting with minthreadstoarchive set to 1. I don't think we need to send repair bots out to fix anything either after changing the default. Most people on talk pages with the parameter missing will probably not notice anything. --Timeshifter (talk) 03:40, 13 August 2025 (UTC)
Note about updated values: the values in the collapsed table above have been updated per this comment by User:Jacobolus. In lieu of obtrusive strike and underline decoration per the letter of WP:REDACT, this before-after diff serves to highlight the redactions. Thanks, Mathglot (talk) 00:05, 19 August 2025 (UTC)
Broader discussion
edit- No worries, believe me, I get it; it is confusing, as your paragraph three attests. Couldn't agree more with your points, and that is why I think this proposal and discussion aren't going anywhere, but I would love to see an influx of fresh views and be proved wrong. Mathglot (talk) 09:55, 13 August 2025 (UTC)
2 threads as a minimum to archive is a pretty good default, but it's also fine for people to increase this value (a value of 3–5 is probably the most useful setting, frankly). It primarily affects very low-discussion pages (or low-discussion time periods). I recommend against setting this to 1 on any page, and would recommend changing 1 to 2 whenever anyone comes across that configuration. The reason to avoid the setting 1 is that then every new thread on a low-traffic talk page will immediately cause the bot to archive the oldest remaining topic, which is distracting and annoying. There's really no need for bots to try to make talk pages strictly keep to a particular number or age of threads, and no hurry about when or how many threads to archive when discussions are rare. The point of archiving talk pages is to make sure that they don't grow without bound to unwieldy distracting size or get cluttered up with 10+ year old stale discussions no longer relevant to current versions of the article, not to enforce a rigid rule about how many threads are visible. Precisely when and under what circumstances a bot will archive a talk page is bit of housekeeping trivia not worth thinking about unless the bot is significantly misconfigured. –jacobolus (t) 01:24, 14 August 2025 (UTC)
- If you, jacobolus, and Mathglot, stopped blocking CapnZapp's proposal at Template talk:Talk header, then all of this discussion here would be unnecessary.
- Because talk page readers would see exactly what is going on concerning when sections are archived (via {{talk header}} info). It wouldn't matter what minthreadstoarchive was set to. At least as concerns confusion about bot actions. People would understand what is happening.
- And Redrose64 (see his comment higher up concerning this) would be fielding less questions at User talk:Σ due to people misunderstanding the bot's actions. Pinging FaviFake too since FaviFake supports CapnZapp's proposal.
- See: User talk:Timeshifter/Sandbox291.
- A suggested box below for {{archives|banner=yes}} or for the bottom of {{talk header}} when there is no archive yet. So a search form would not yet be needed. It is simple to understand, and takes only 2 lines in my PC monitor.
 | Sections older than 90 days will be auto-archived by User:ClueBot III if there are more than 4, but only if there are a minimum of 2 sections to archive. |
- If there actually are archives, then the text can be put in the tooltip: "Auto-archiving period" of {{talk header}}. See the talk header at the top of this page to see what I am talking about. This could easily be incorporated into {{talk header}}. The above long discussion gives more reasons to do so. --Timeshifter (talk) 03:13, 14 August 2025 (UTC)
- All of this discussion is unnecessary. The current talk header works fine, as does the default bot config. –jacobolus (t) 03:13, 14 August 2025 (UTC)
So you acknowledge none of these points. That is your right. Others disagree with you.
To clarify for new readers here, we are talking about |minarchthreads= for User:ClueBot III, and |minthreadstoarchive= for User:Lowercase sigmabot III. They do the same thing. --Timeshifter (talk) 03:22, 14 August 2025 (UTC)
- No, I just disagree with you. I think you are making a whole lot of unjustified noise and bluster about something that isn't a problem, and your proposed solutions will make Wikipedia worse. –jacobolus (t) 03:47, 14 August 2025 (UTC)
- Others disagree with you. As I said you acknowledge none of our points. And you are making Wikipedia worse by doing so. And you are not offering other solutions. --Timeshifter (talk) 03:58, 14 August 2025 (UTC)
- Okay, here is something that would help: we should propose better config options in the documentation pages. The best bot config for the vast majority of Wikipedia articles, which have relatively low traffic, would probably be something like archiving topics only after 3 years, keeping a minimum of 5 or 6 topics on the page, and only archiving when there are 3 topics to archive at a time. The documentation could recommend that when this archive schedule becomes to infrequent to keep up with the discussion on a particular page, the bot can instead by reconfigured to be (moderately) more aggressive, e.g. archiving every 6 months.
- The recommended copy/paste at User:MiszaBot/Archive HowTo:
{{User:MiszaBot/config | algo = old(90d) | archive = User talk:Example/Archive %(counter)d | counter = 1 | maxarchivesize = 150K | archiveheader = {{Archive}}} | minthreadstoarchive = 1 | minthreadsleft = 3 }}
- are terrible defaults for basically any talk page on the site, and the one at User:MiszaBot/config and User:Lowercase sigmabot III/Archive HowTo:
{{User:MiszaBot/config | algo = old(60d) | archive = User talk:Example/Archive %(counter)d | counter = 1 | maxarchivesize = 200K | archiveheader = {{Archive}} | minthreadstoarchive = 1 | minthreadsleft = 2 }}
- is even worse in every way, but people use these config parameters all of the time because it's easier to copy/paste without considering what the options mean. The archive size is unpleasantly big, the time frame is much too short, the minimum number of threads to leave is ludicrously few, and the minimum number of threads to archive is also too few. Instead the recommended config to copy/paste should be near the top of every bot documentation page, and should be something along the lines of:
{{User:MiszaBot/config | algo = old(730d) | archive = User talk:Example/Archive %(counter)d | counter = 1 | maxarchivesize = 80K | archiveheader = {{archive}}} | minthreadstoarchive = 3 | minthreadsleft = 6 }}
- To do even better, someone could run a search for bot configurations across the site, and try to characterize talk pages by how many new topics are started each year. For any talk page averaging, say, 5 topics per year or less over the previous few years, the bot config could be changed to my proposal here, as a maximally aggressive setting (some pages might be better with an archive time of 4 years or whatever). That would end the vast majority of people's complaints with misconfigured bots. –jacobolus (t) 04:11, 14 August 2025 (UTC)
- Separately, in the discussion above you want to explicitly set the minthreadstoarchive parameter to 1 anywhere where it is currently unspecified, even though the current default is 2. This is an entirely unjustified and disruptive change. What would be justified is explicitly setting the parameter to 2 (to match existing behavior but make the parameter visible in the config); if you do that, carefully moderating the speed of whatever bot carries out the task so it doesn't flood watchlists (e.g. it could be done by the archive bot the next time it archives a page) I don't think anyone will complain. –jacobolus (t) 04:25, 14 August 2025 (UTC)
- No need to consider watchlists in your calculations; bots are parametrically excludable. The only reason to include them is when researching something involving a bot, as you propose here. As you can define multiple watchlist configs and easily context-switch among them, the best strategy for most people is probably to exclude them by default, and define a second watchlist config for your bot-related investigations. Mathglot (talk) 05:03, 14 August 2025 (UTC)
- Speak for yourself. I keep bots on my watchlist because there are a wide variety of bots on Wikipedia which routinely fuck stuff up. If nobody pays attention to them and reverts those mistakes they cause incredible amounts of damage. –jacobolus (t) 08:38, 14 August 2025 (UTC)
- No need to consider watchlists in your calculations; bots are parametrically excludable. The only reason to include them is when researching something involving a bot, as you propose here. As you can define multiple watchlist configs and easily context-switch among them, the best strategy for most people is probably to exclude them by default, and define a second watchlist config for your bot-related investigations. Mathglot (talk) 05:03, 14 August 2025 (UTC)
- Others disagree with you. As I said you acknowledge none of our points. And you are making Wikipedia worse by doing so. And you are not offering other solutions. --Timeshifter (talk) 03:58, 14 August 2025 (UTC)
jacobolus. I just reverted a recent change of settings that ended up with the ridiculously low setting of 2 for minthreadsleft. Here is the longer term list from "Example 2: Incremental archives". I myself prefer settings of 6 to 8 for minthreadsleft to start off with on talk pages.
{{User:MiszaBot/config
| algo = old(30d)
| archive = User talk:Example/Archive %(counter)d
| counter = 1
| maxarchivesize = 150K
| archiveheader = {{Archive}}
| minthreadstoarchive = 1
| minthreadsleft = 4
}}
If minthreadstoarchive was changed to a default of 1 I doubt hardly anybody would notice on those pages missing the parameter.
In any case what is more important is that talk page readers understand what is going on concerning minthreadstoarchive. Which many will not until {{talk header}} or {{archives}} tells them. You expect them to magically intuit it. Or expect most average editors to dive into the arcanery of looking at talk page wikitext, and then the doc page. You expect too much. --Timeshifter (talk) 05:23, 14 August 2025 (UTC)
- I made that change since that is the literal default and leaving 2 threads and archiving 1 is perfectly fine.
- I also removed the note about the legacy 4 threads thing.
- The reason why 4 was used for a long time was because the legacy Vector 2010 skin required 4 threads to create a TOC, and TOCs are of course useful.
- But that is no longer the case with Vector 2022, which is now the default on en-wiki and even just a single thread will have a TOC on the side.
- So due to that, I think we should go with the times and embrace the
minthreadstoarchive = 1andminthreadsleft=2. - There are plenty of discussions that are ginormous these days and having 4 of them on many pages just doesn't serve us anymore.
- For those few pages that do require nuance, experienced editors will adjust things.
- But for the bulk of small article-that-explains something, 1/2 is perfectly fine.
- Also the 150K for default archive page sizes is small and 200K is perfectly handle-able by people's browsers these days. Raladic (talk) 05:31, 14 August 2025 (UTC)
- Some people still use Vector 2010. And many people prefer not harvesting all or nearly all the talk threads into archives. It stifles discussion.
- And defaults are often not what is recommended. And it all depends on various factors, and editor preferences. For example, how busy the talk page is. --Timeshifter (talk) 05:59, 14 August 2025 (UTC)
- Yes, a few do use Vector 2010, but we should work for the norm, not the exception. We can make an
{{efn}}for those that may still use 2010, but it doesn't need to be prominently mentioned anymore. - Ideally the defaults are what is recommended for most pages when users don't have to think hard.
- Let's use this talk page here as an example, it's currently 80k long already and the scrollbar is getting pretty darn tiny, I really don't think anyone will be upset if that #"Special" user talk subpages finished discussion from April would be gone, but because it's set to 1/4 right now, it's still here. Same for that #Question about "minthreadsleft"... thread, it's from May and was asked and answered.
- So I do really think that for most run-off-the-mill pages 1/2 is the better default nowadays Raladic (talk) 06:08, 14 August 2025 (UTC)
- Well, this thread is an exception. :)
- And if you read it you will see that almost all of us do not like talk pages to be harvested down to 1 or 2 threads. As you said modern browsers have no problem handling a 200K archive. Same is true for an 80K talk page.
- I agree the first 2 topics can go. But they can be done manually. I don't want #Question about "minthreadsleft"... thread archived yet. It is relevant to this discussion.
- Basically I don't want the last 2 threads deleted for awhile. If "minthreadsleft" was set to 2 they would disappear too soon.
- Auto-archiving period should be set to 4 months. Instead of the current 2 months. Related discussions at Template talk:Talk header have been going on for months. Its auto-archiving period is 4 months. It is also set to 4 threads, and is a very long talk page.
- So some talk pages are long. --Timeshifter (talk) 06:39, 14 August 2025 (UTC)
- 4 months is a very long time. I'd say most articles are perfectly fine with 60d or max 90d timeframes. Given that the clock only starts from the last comment, not the first. Raladic (talk) 07:01, 14 August 2025 (UTC)
- Many article talk pages I have seen are slow moving with short threads. When I set up archiving I often set it for 6 or 8 threads. A common setting. I have seen many article talk pages with 6 to 9 month timeframes. It all depends on the relevance of past threads. Oftentimes they are still relevant to people with similar questions. --Timeshifter (talk) 07:11, 14 August 2025 (UTC)
- 4 months is a very long time. I'd say most articles are perfectly fine with 60d or max 90d timeframes. Given that the clock only starts from the last comment, not the first. Raladic (talk) 07:01, 14 August 2025 (UTC)
- For most run of the mill pages, traffic is extremely low, and meaningful talk page responses can be years apart. Setting a bot to archive after only a few months with a low number of threads basically destroys the value of the talk page, sweeping all problems under the rug and preventing readers from learning about it when long-standing problems are repeatedly complained about but not fixed. Yikes, I cannot overstress how bad this recommendation is. Please never configure archiving like this for ordinary pages! If this kind of thing is common, no wonder the bot authors get numerous complaints from confused editors. Anyone configuring pages like this fundamentally misunderstands the purpose of the archive bot, which is to prevent pages from getting overwhelmed by stale discussions, not to make talk pages appear empty. –jacobolus (t) 08:41, 14 August 2025 (UTC)
- No, thinking that users go and diligently read over the entirety of a page before starting a new thread is a fundamental misunderstanding of modern users. Typically when I land on a page and I see there are 4 threads there and two of them are from 2005, I know this talk page is basically used as much as Dodos are alive now. I can deduce that just as much from seeing there’s a min of 2 as I can from seeing a min of 4.
- Now secondly, modern users are impatient, they don’t spend time doing the diligence of carefully perusing a page. Either they just don’t check at all (common), or they follow WP:SEETALK and check the archives using the search. Especially so when there’s more than a single Archive page.
- The best story I have here is that reported several years ago, I had to check, it was 2021, that the next generation of users, namely Gen Z grew up as the first generation to have been fully in the digital age from childhood on, and indeed doesn’t even know what a folder is anymore, they don’t care, and for the most part, they don’t have to; They grew up in the age of Google and the search box. Why read carefully through something or prepare structure when you can be much more efficient just searching for it.
- Now of course, we do not just have GenZ users, though their fold is growing fast as indeed, as the youngest are now 13 and in middle school and about to head into high school, the oldest have already been working for 10 years and are turning 30 next year. Their older siblings, Millenials, grew up with part of their life with computing and while they’re not as zippy, they still also know their stuff and embrace new tools they’re between 30 and 49 years old and make up the largest segment at a third of the working force, most Boomers have already retired and Gen X is starting to. The advancement of AI and LLMs has only accelerated that adoption of search/prompt based usage of modern software. Reading through pages of references when you can instead just say “Hey Siri, when did LGBTQ overtake LGBT to refer to the queer community?” and she will quickly spit out that LGBT was a thing of the 1990s and LGBTQ came about in the early 2000s. - Why did I use that example? Well, over at LGBTQ we probably get 1-2 threads a month asking why we are using LGBTQ on pages instead of the nowadays more inclusive LGBTQIA+ term? Indeed, if you go there right now, you’ll see Talk:LGBTQ (term)#LGBTQ (term) should be moved to LGBTQIA+ (term) was asked just a week ago. But, as you can see on the talk page, it was also asked in January and in different variants twice in July. That is the entirety of that talk page right now. Four back-to-back threads asking different permutations of the same question. Now here’s the kicker that takes the cake, we have a giant WP:LGBTQFAQ FAQ up top on the page that answers why (as well as the half-mile long RM history below it) - and yet, most people don’t read the headers, much less so, the page. If they do check, it’s gonna be search. But the old RTFM adage of reading a manual have passed. Of course, right now we ask users to WP:READFIRST, but that will likely change to WP:ASKYOURFAVORITEAIFIRST to catch up on prior discussions.
- So just as the internet has moved on from flashing rainbow gif (pronounced GIVE, not JIFF) pages from the 90s and early 2000s, so has the way that most people have grown up with, and continuously adapted to change in how we use modern computers, or even more likely, phones and tablets/laptops.
- Now of course, we can lay ourselves across the floor and say - no, change is bad, but in doing so, we will do a disservice to our users. We adapt, just as our users do. Just as the Wikipedia skin changed from Vector 2010, which looks archaic to the modern UI of Vector 2022, and alongside it, have the usage patterns of people.
- TLDR: Most people use search nowadays, the days of reference pages is rapidly becoming a thing of the past. Given AI/LLMs speedy advancement over the past two years, indeed the user interfaces of all modern devices is changing so fast that we’re going to be in for an interesting ride over the next couple of years.
- I do apologize that I went a bit prosey, I think I’ll actually turn this into a User essay when I have a moment as I do think it’s worthwhile to remind ourselves that just as microchip sizes have shrunk to insanely small, so have the ways we use them and will continue to use them. Captain Kirk was dictating to his Computer in the stardate 1512.4, in what we envisioned (in 1966, that’s when Star Trek TOS came out) the modern future in the 23rd century to be when we’re zipping about the galaxy in the USS enterprise. Well we haven’t come quite as far yet on the space flight, though there’s obviously been some advancements there as well, but we have indeed been able to turn the idea of saying “Computer, captains log” into reality as of 2024, so the Hitchhikers Guide to the Galaxy can now give you most answers at a moments notice. Raladic (talk) 13:15, 14 August 2025 (UTC)
- I'm assuming "modern users are impatient" followed by this rambling wall of text is intended as an absurdist joke. In any event, please do not configure low-traffic talk pages to aggressively archive topics. It causes confusion and blocks collaboration. –jacobolus (t) 19:26, 14 August 2025 (UTC)
- Yes, a few do use Vector 2010, but we should work for the norm, not the exception. We can make an
"Different strokes for different folks". That'a an OG old-school expression by the way.
I use Google search all the time. AI is often at the top of the results, and is frequently wrong in my experience.
I, at least glance at previous threads on a talk page before starting a new thread. To see if what I intend to talk about has been covered in any way already. Just to be polite if for no other reason.
And by the way we have come far along with the Star Trek-style space flight. Anti-gravity was figured out around 1954. :) But Steven Greer and his vast sources are not considered reliable sources by Wikipedia. --Timeshifter (talk) 13:48, 14 August 2025 (UTC)
- I myself do check and search of course before I start a new thread, but we just have to remember that as power-users we are often very different behaviorally and not actually the majority of the people that use our articles.
- Decided to actually essay-ify the above with some small improvements for cohesion: WP:EMBRACECHANGE.
- Sure, AI still hallucinates sometimes and gets things wrong, but just the pace at which it has improved is honestly pretty wild. But even without AI, just search alone will yield things if users use good terms to look for.
- In any case, we should probably continue the actual change for the examples below so we don't bounce between the two threads. Raladic (talk) 16:10, 14 August 2025 (UTC)
- Serious unaddressed problems with an article should not be removed from the talk page before anyone has a chance to work on them. Expecting "impatient" readers to do a careful archive search to discover what problems other readers have had, and then preventing them from responding in a single place in an organized manner, is entirely unreasonable. Bad archiving configuration thwarts readers' attempts to fix problems they find on our articles, undermines discussion, which leaves potential contributors frustrated and less likely to stick around. This has nothing to do with "the modern age" or which skin people are using. –jacobolus (t) 21:00, 14 August 2025 (UTC)
maxarchivesize and minthreadsleft
editI noticed some recent edits by User:Raladic and User:Timeshifter and wanted to give my thoughts.
Regarding |maxarchivesize= this was 150K for a long long time, as far as I understand because of dial-up modems and slow wireless 2G/3G speeds. But do really a 50K difference still present difficulties to modern browsers? I genuinely and honestly believe an increase is in order in the lord's year of 2025, and that's why I'm mostly setting up new automatic archiving with greater values but I am definitely open to a consensus-forming discussion if there's disagreement over this, or perhaps other considerations I don't know about.
Regarding |minthreadsleft= I have what I believe are stronger arguments. I recently wrote this over at Wikipedia:One click archiving (and I note it appears to have met with consensus there, at least of the silent sort):
| “ | Also please consider not emptying out talk pages completely or reducing the number of topics below four (4). Some editors find a blanked-out talk page or even a page with no TOC[b] visually jarring/unfamiliar and significantly less welcoming to newbie editors (keeping some existing discussions - even if very old - is a very user-friendly way of saying "you are welcome to contribute here"). | ” |
I want to believe that any editor thinking a value for minthreadsleft smaller than 4 simply haven't thought about these considerations. I can certainly see how you could think a value of 0, 1, 2 or 3 would be useful... before you take the above into account.
Hopefully this helps. CapnZapp (talk) 10:27, 14 August 2025 (UTC)
- Archive pages are much easier to skim through when they are not so long. It has nothing to do with dial-up modems, but with just looking through the table of contents and scrolling through the text.
- Something like 75–80K is about right for length in my opinion, though 100K is okay. Much shorter than that and sometimes individual discussions with excessively prolific participants suck up a large part of the page. 200K is much too big. There's no harm whatsoever in having a few extra archive pages. Most pages on the site only end up with a few topics per year / a few archive pages per decade. –jacobolus (t) 10:33, 14 August 2025 (UTC)
- Whereas I find talk pages with dozens of minuscule archive pages mostly annoying. I rather use regular browser text search (which only works on one page at a time) than the slow and clumsy Wikipedia-search-through-the-archives and see little reason to have to switch archive subpages. On pages where you remain on archive two or five even after two decades' worth of discussion with a 75K setting, that setting is obviously fine. But on talk pages where a 200K setting saves you twenty archives or so; there I am grateful for the larger setting. Though thanks for your input; interesting you don't think technical considerations come into play. CapnZapp (talk) 10:55, 14 August 2025 (UTC)
- On archive size - yes exactly, which is why I raised it to 200k, it results in less pages generated and no one goes to scroll through archive pages casually. People will typically search instead. Especially so when there’s more than one Archive page as I’m not going to click through 20 Archive pages trying to find if something was discussed, I’m going to use the search instead.
- On
minthreadsleft- the argument about missing TOCs is indeed an archaic one too. @Timeshifter brought this up themself many months ago here, as well as myself just earlier - it only applies to the old Vector 2010 skin. En-wiki however has switched to Vector 2022 years ago, which produces a TOC for as low as a single thread, which means this argument is moot. We should design for the norm, not the exception of some users who chose to manually set their skin back to the old one.
- Raladic (talk) 11:59, 14 August 2025 (UTC)
- That isn't the only reason to have 4 or more threads as has been pointed out by me and others.
- As for archive sizes, I like longer ones too. I reverted you because you changed multiple things at once in the example code without any discussion. --Timeshifter (talk) 13:56, 14 August 2025 (UTC)
- I know it's not the only reason, but I have a pretty good hunch it was a primary factor. We're creatures of habit and even though they say we're irrational beings, we are actually rather predictable in our irrationality (amazing book by the way if you like human behavioral study).
- No worries about the revert, since I totally understand the partial undo would have been harder. I'll leave the parameter sizes for now until we reach a consensus.
- I'll re-add the note about the Vector-related thing, as I also updated WP:TOC earlier which was similarly hopelessly outdated. Raladic (talk) 16:17, 14 August 2025 (UTC)
- A recent 200K-limit archive page I looked at had over 100 separate discussion topics. That makes it difficult to even read the table of contents, let alone read the archive. Archive pages work better when they have a moderate size, maybe 30–40 topics at most. The reasons for keeping their size in check are similar to the reasons for keeping main talk page size in check.
- Overall, it seems highly problematic that bot defaults affecting potentially thousands or millions of pages are being decided unilaterally by random Wikipedians without discussion. The default archive bot config should be established by consensus on some higher-traffic community forum like the Village Pump. –jacobolus (t) 21:09, 14 August 2025 (UTC)
- What page was that?
- Looking at some of the high volume notice boards like say WP:AE has theirs at 200k and has 350 archives. Each 200k archive page has about 3-4 cases since each thread is typically 50k+
- Luckily whoever did it, set it to 200k a long time ago, as the prior defaults of 75k would mean there would likely be one archive page per case at this point.
- The change up to 150 for the defaults wasn’t that long ago, but was well overdue and I think my increase from 150 to 200 should be pretty uncontroversial As that has been the limit that many busier pages have used for a while (like AE as I mentioned).
- It might be worth it to do an inventory however of how many pages still have tiny 75k limits and increase those.
- That is to say, the sword cuts both ways. Sure, if you somehow intended to manually browse an archive page and whatever article it is for only has tiny 2k discussions. But at the same time, that also has the benefit of not having hundreds or thousands of archive pages for those articles/boards. Raladic (talk) 21:46, 14 August 2025 (UTC)
- For most ordinary article talk pages, 150K or 200K is much too large. The prior default of 75k seems about right. Is there a discussion about that change somewhere? If not, that should be reverted and brought for discussion to a wider forum. Setting the recommendation for ordinary article talk pages based on a few editors' personal preference about extremely high traffic community meta-discussion pages is completely inappropriate in my opinion. –jacobolus (t) 23:19, 14 August 2025 (UTC)
- The default value for
|maxarchivesize=is neither 75K nor 150K; it is 1954K. The full list of default values is as follows:See User:Lowercase sigmabot III/Source.py and search forself.config = {'algo': 'old(24h)', 'archive': '', 'archiveheader': "{{Talk archive}}", 'maxarchivesize': '1954K', 'minthreadsleft': 5, 'minthreadstoarchive': 2, 'counter': 1, 'oldcounter': 1, # For internal use by the bot 'key': '', }
class Archiver:. --Redrose64 🌹 (talk) 18:33, 16 August 2025 (UTC)
- The default value for
- For most ordinary article talk pages, 150K or 200K is much too large. The prior default of 75k seems about right. Is there a discussion about that change somewhere? If not, that should be reverted and brought for discussion to a wider forum. Setting the recommendation for ordinary article talk pages based on a few editors' personal preference about extremely high traffic community meta-discussion pages is completely inappropriate in my opinion. –jacobolus (t) 23:19, 14 August 2025 (UTC)
Thanks. That's correct. And some of those defaults are wildly useless. However, we're discussing the How To recommendations, not the code defaults. After all, if you follow this How To, the defaults won't matter because they will never come into play. There's a good reason this How To doesn't recommend an "empty" config that relies on the code default.
Anyhow, just as an example, we're discussing whether "Example 2: Incremental archives" should suggest something like
{{User:MiszaBot/config
| algo = old(30d)
| archive = User talk:Example/Archive %(counter)d
| counter = 1
| maxarchivesize = 75K
| archiveheader = {{Archive}}
| minthreadstoarchive = 1
| minthreadsleft = 3
}}
or
| algo = old(90d)
| archive = User talk:Example/Archive %(counter)d
| counter = 1
| maxarchivesize = 200K
| archiveheader = {{Archive}}
| minthreadstoarchive = 2
| minthreadsleft = 4
}}
Again, just an illustration. CapnZapp (talk) 00:43, 17 August 2025 (UTC)
Is there a discussion about that change somewhere?
If there are any discussions, this one right here on this talk is probably it, user:jacobolus. Do note no discussions are actually required; if a value has been boldly changed, and nobody has objected for a while, consensus can be assumed once the page is considered stable again. Regards CapnZapp (talk) 00:54, 17 August 2025 (UTC)- I don't think we can assume any "consensus". This isn't the kind of thing very many editors are paying attention to, except occasionally when looking for an example to copy/paste when setting up new archives. I think it would probably be worth having a discussion about it somewhere like the village pump, since this actually ends up affecting a lot more people than might be watching these pages. –jacobolus (t) 03:28, 17 August 2025 (UTC)
- You come across as not understanding, or wanting to understand, that a consensus can have existed at the same time a new discussion makes it clear consensus no longer exists. Both the following points can be true:
- Before the start of August no editors objected for weeks, so there was definite consensus regarding something like (for example) the
|maxarchivesize=150Krecommendation of Example 2: Incremental archives. (I say "weeks" here, but I'm not trying to pretend there's a given standard; instead I'm going with what I perceive to be how Wikipedia works; that is editors are willing to consider any length of time from "a couple of days" up to "a month" to be reasonable demands on page stability, depending on circumstances) - After the start of August editors (that'd be you) object to this setting. Since consensus no longer exists, we are (trying to) have a constructive discussion with the aim to, once more, establish consensus.
- When you say
I don't think we can assume any "consensus"
you come across as someone believing me saying "since consensus exists, I deny your right to discuss and possibly change consensus". That is simply not my meaning. When I assume that consensus was reached over this setting, I am acting exactly in accordance with proper discussion practice. Two different things. We can definitely assume a consensus was reached, since we could not move discussions ever towards a constructive conclusion if we didn't assume the (many) editors staying silent didn't accept the stable version (even if only to a minimal degree). We can, we should, and we must. - Now then, you are perfectly within your right to bring up this subject, suggesting changes, and even starting discussions about these settings elsewhere. (Please do post a courtesy link here if you do) But I need you to cut out the conspiracy crap. This stuff was discussed and edited here without your knowledge not because I'm the shady leader of a cabal, but because you did not watch or visit this page. There are literally thousands of small changes made daily without my knowledge all over Wikipedia; demanding they all be discussed at some central venue (that I happen to monitor) is utterly unreasonable. If you happen to believe this How To really is part of the (very) small subset of actually crucial settings that must be discussed centrally, you need to make that happen. Preferably without unfounded and personal accusations. Until then I'm asking you to avoid crap like
highly problematic that bot defaults affecting potentially thousands or millions of pages are being decided unilaterally by random Wikipedians without discussion
. This very Talk page is irrefutable proof that you are wrong. In fact, have a look. You'll find I have personally spent a considerable amount of personal energy trying to talk my fellow editors into not changing the bot code defaults. I'm telling you there is nothing nefarious about this stuff being discussed here and only here, and there is zero attempt at subterfuge when I have abstained from advertising the (checking...) 16 edits, tweaks and improvements I have made since I first changed this page back in October 2020. CapnZapp (talk) 12:47, 17 August 2025 (UTC)- Please stop making claims along the lines that I "[don't want] to understand" you. These come across as patronizing and rude. I understand you perfectly well, I just think you are wrong.
- I disagree profoundly with "there was definite consensus". This is a misunderstanding of the meaning of the word "consensus". What is true is that there was a relatively static version of the page without any explicit discussion, because most of the people affected have never been asked about the topic or perhaps even realized they were affected. Remember, "a lack of response to an edit does not necessarily imply community consent" and [...] template documentation pages [...] have not gone through the policy and guideline proposal process and may or may not represent a broad community consensus."
- Also, nobody said that everyone must be consulted about every small change anywhere on the site; as you point out, that would be absurd. What I said is that the recommended archive config settings have a significant impact on a large proportion of Wikipedia editors, so it is probably worth asking about them in a venue with more eyeballs than this extremely obscure talk page, since the people here are unlikely to fairly represent the broader community. –jacobolus (t) 18:54, 18 August 2025 (UTC)
- I don't think we can assume any "consensus". This isn't the kind of thing very many editors are paying attention to, except occasionally when looking for an example to copy/paste when setting up new archives. I think it would probably be worth having a discussion about it somewhere like the village pump, since this actually ends up affecting a lot more people than might be watching these pages. –jacobolus (t) 03:28, 17 August 2025 (UTC)
You are invited to join the discussion at Template talk:Talk header § RfC: tooltip wording, minthreadstoarchive. Mathglot (talk) 05:37, 26 August 2025 (UTC)