This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Hello, my talk page is not being archived although I have tried several times. Could you tell me what is wrong or you yourself can fix it. I have no problem. I want it to be archived after the talks have been there for more than three months according to the dates. Please help me. Archiving can be done in 1 2 3 way. It would be great if I get it sorted out. Hoping for you reply. Cheers!!! Sammanhumagaint@lk03:28, 4 July 2015 (UTC)[reply]
Hello! Regarding this recent edit, could there be any potential issues associated with round numbers, i.e. 30 instead of 31, or 60 instead of 61? Are there, maybe, some unforeseen issues related to certain previosly made decisions on how the bots should interpret those values? Various talk pages I've seen mainly had values such as 31 or 61. Voidxor and I have already discussed this briefly, and we'd need more input from other editors. — Dsimic (talk | contribs) 10:22, 21 July 2015 (UTC)[reply]
(talk page stalker)@Dsimic: Please note that Misza13 (talk·contribs) hasn't edited in months. The archiving is actually performed by lowercase sigmabot III (talk·contribs). But I'm pretty sure that the value fed through the |algo=old(...) parameter isn't critical - so long as it's an integer followed by the letter "d". Thus, |algo=old(30d) and |algo=old(31d) are equally valid - as are |algo=old(29d) and |algo=old(32d). Personally I have used |algo=old(122d), |algo=old(91d) and |algo=old(73d) - it's never complained about any of them. --Redrose64 (talk) 17:39, 21 July 2015 (UTC)[reply]
@Dsimic and Redrose64: Does anybody know what the default algo is for lowercase sigmabot III? I created a column of default values in the table at User:MiszaBot/Archive HowTo#Parameters explained. It would be great if the defaults were safe assumptions to use for the vast majority of talk pages. If so, it would only take a couple arguments to configure automatic archiving, instead of seven. – voidxor(talk | contrib)21:01, 21 July 2015 (UTC)[reply]
Based on the source code, this fragment seems to be what defines the default values:
self.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':'',}
@Dsimic: Is that maybe where the 31-day example came from? Might it have had nothing to do with how many days are in a month and everything to do with being a day longer than the nominal proposal waiting period? As such, should I change bothexamples from 30d to 31d?
@Σ: What is your take on the impact of changing the defaults? Do you think many talk pages rely on the default values? I gather the default |maxarchivesize=1954K is large so that folks wanting only a single archive page don't have to explicitly set a limit. The default value that's most unusual (the one that we might consider changing) is |algo=old(24h). I have to wonder if it would impact much to change it, since so few talk pages archive that rapidly, and those talk pages probably explicitly set their algo. – voidxor19:34, 23 July 2015 (UTC)[reply]
I don't know. I'm using the same defaults that the original MiszaBot has been using for years. It's possible to make a census on the bot's next run if we're trying to decide whether the defaults are safe to change, but it would also be trivial to make a template that could be subst'd with more sane default parameters. →Σσς. (Sigma)20:13, 23 July 2015 (UTC)[reply]
@Voidxor: It could be the reason, as the merger proposals need to stay open for at least 30 days. Quite frankly, I'd go with 60 days for the "old" value in examples, at least because it's quite unreasonable to expect that commentless merger proposals are going to be handled on exactly the 31st day of their existence. Maybe even 120 days, but 60 should be a reasonable compromise that allows more people to see various talk page discussions. — Dsimic (talk | contribs) 02:10, 24 July 2015 (UTC)[reply]
@Dsimic: I'm sure it depends on how busy a given talk page is. For high-traffic talk pages, by all means get those 45-day old threads archived! I guess that's why I put more stock in |maxthreadsleft= than |algo=old(...) for serving the purpose that you describe.
@Σ: So an archive-configuring template would have to be substituted instead of transcluded because your bot has to update the |counter= argument, right?
@Everybody: I guess where I'm going with all this is to see how simple we can make archive configuring for 99% of talk pages. I'm dreaming of creating {{Archive automatically}}, {{Archive monthly}}, and {{Archive annually}} templates where that's literally all that you'd have to place on the talk page, and it would include three things: the Miszabot config statements with rational values, an {{Auto archiving notice}}, and a navigation and search box such as {{Archives}}. Ideally, these new templates would be transcluded, though it appears lowercase sigmabot III would need them substituted for counter purposes. – voidxor02:39, 24 July 2015 (UTC)[reply]
Could, maybe, Wikidata be used for storing the archiving counter values? It would even be better to have them stowed away. Those all-in-one templates would be really neat, but they might take away some of the flexibility that creates variety. — Dsimic (talk | contribs) 02:47, 24 July 2015 (UTC)[reply]
Wikidata is for storing data that is useful to more than one Wikimedia project. It is conceivable that the same archiving bot runs on more than one project, and maybe even archives the corresponding talk pages on each; but the current archive number will be different for each project. If two talk pages on two different projects have the same archive number, it is coincidental. --Redrose64 (talk) 15:35, 24 July 2015 (UTC)[reply]
@Dsimic:Variety?! I'm looking for consistency among 99% of archive-ready talk pages. Only very high-volume talk pages should need to deviate from reasonable default values, I would think. – voidxor22:21, 24 July 2015 (UTC)[reply]
@Redrose64: Ah, yes, I totally forgot about that. Sorry.
@Voidxor: Perhaps I haven't explained myself clearly enough, please let me retry. The strength of our talk pages comes from the fact that they have pretty much no formal layout, no "workflows", no technical rules about who replies to whom, why and when, etc. I had a look at the Wikimedia's proposed successor of talk pages, whose name I unfortunately can't recall, and I really couldn't see how is that going to efficiently replace current talk pages. Talk page archiving probably isn't a good example, but I'd say that the variety is what creates strength. Though, I'd love to see more streamlined automated archiving configurations. — Dsimic (talk | contribs) 05:42, 25 July 2015 (UTC)[reply]
As I understand it, Flow won't have archiving that resembles the present system, since each thread (or "topic" as they're called) is held on a different page (e.g. Topic:Skv400v2q1154yxv or Topic:Sl0n5xte881pqpz9), the actual talk page being built up from one or more of these, and the undisplayed ones can be considered as "archived". So to "archive" a topic, they simply cease to display it on the main page. --Redrose64 (talk) 14:14, 25 July 2015 (UTC)[reply]
Ah, yes, it's called Flow. :) As some kind of a hybrid between the traditional forums and Google Groups, with a touch of Stack Exchange, I'd say that it looks pretty weird. At least compared with standard talk pages. — Dsimic (talk | contribs) 14:22, 25 July 2015 (UTC)[reply]
So an archive-configuring template would have to be substituted instead of transcluded because your bot has to update the |counter= argument, right? That is correct. As well as the fact that the bot only archives pages that transclude {{MiszaBot/config}}. Having the bot parse templates that redirect to that would be unnecessary and annoying.
I agree, though, that Flow is an unnecessary piece of software that tries to solve problems that don't exist. Unfortunately, management has no clue about the outside world, hence LiquidFlowEchosV6. →Σσς. (Sigma)00:51, 26 July 2015 (UTC)[reply]
Totally agreed, the problem Wikipedia faces is obvious lack of competent editors, willing to spend their time on writing articles and reading a whole bunch of guidelines; "advanced features" like Flow or VisualEditor are IMHO total duds. For example, over 90% of edits I've seen tagged with "VisualEditor" were either vandalisms or totally messy. — Dsimic (talk | contribs) 05:51, 26 July 2015 (UTC)[reply]
Wikipedia editor count
@Dsimic: I agree, but for the sake of argument, I'll tell you what I've learned in my outreach work. The Wikimedia Foundation feels the initial buildup of editors was tech-savvy people (like all of us) gravitating toward editing, and that since 2007, we've failed to attract enough editors from non-STEM disciplines—many of whom are daunted by anything that looks like code, including wiki markup. This barrier to entry explains the systemic bias towards STEM topics, the gender bias (some 90% of editors are male), the cold-turkey stop to the exponential growth in editors (see chart), and the alarming number of registered user accounts that have only made an edit or two before disappearing for good. The Visual Editor is one of the projects on the Foundation's road map to address these issues. Flow is another project on the same road map, meant to address the same problems.
So yes, I'd like all editors to be competent too, but unfortunately we're losing editors when we should be gaining more. Thus, lowering the bar a little is a good-faith move to fix a widespread issue. Also, don't forget that most of us were incompetent back in 2006, and have grown to become good editors.
As far as your observation that most visual edits are vandalism, that's my experience too. I hope that improves once the Visual Editor gets out of beta and is (probably) turned on by default for new editors. – voidxor21:18, 27 July 2015 (UTC)[reply]
Yes, you're right as my perception is quite skewed toward computing-related articles... Writing articles about Linux kernel features, for example, and about things like dolphins, forrests or fine art are two significantly different things. Perhaps making things easier doesn't make much sense for STEM-related articles because they're inherently complex, but could result in a world of difference for the other article categories.
I'd say that, at least for computing-related articles, everything boils down to how much a new editor is persistent and willing to learn. As you've described it, nobody is perfectly competent and will never be, but IMHO the key is in the willingness to learn. For example, my writing skills and knowledge of English were much worse two years ago or so, but they wouldn't have improved without a lot of hard work from my side. — Dsimic (talk | contribs) 09:56, 28 July 2015 (UTC)[reply]
@Dsimic: I've been working along side you for months, and didn't know until now that English isn't your native language. In fact, on the RAID articles, I've seen you correct the grammar of probable English speakers much to the benefit of those articles. Your English skills are very, very good, overall! – voidxor19:24, 28 July 2015 (UTC)[reply]
