I would also welcome such a change, along with T119791. I think archivebot.py should be working more like SpBot, which allows different leveling of archives and early archival of threads marked with certain template. Thanks.

I wonder if @Euku (developer of SpBot) can contribute to archivebot.py, or at least publish SpBot's source code so that we can reuse/learn from it.

Hungarian Wikipedia uses this template to prevent the section being archived even if expired:
https://hu.wikipedia.org/wiki/Sablon:F%C3%BCgg%C5%91ben
It may have a parameter.
Currently we use an individual workaround for that, but we woluld like to do this with the framework.

The modified Hungarian script's code is available on Tool Labs: https://tools.wmflabs.org/ato/archivebot_hu.py.txt

@Tacsipacsi, you can submit a patch.
Ideally, the template should be generic and configurable somehow.

This will be useful for noticeboards that records requests that ought not be archived until it have been actioned. That is, do not archive this section until {{done}} or {{not done}} is there. I wonder if we can raise the priority on this one or have another group of people (Community-Tech?) giving a hand here. Thanks.

@Xqt @valhallasw Is this task eligible for Google-Code-in-2017? If so, would you like to mentor it?

Ping also @jayvdb and @Legoktm as they're registered in the MediaWiki GCI page.

Being bold and proposing this for GCI.

[ removing Google-Code-in-2017 as this is not under good first task either and as nobody volunteered for mentoring ]

I added some details into the description which might help people implement this idea.

Please consider that

• {{done}} or any similar template may have parameters (at least |~~~~)
• some delay may be neccessary and should be implemented (we don't want people to mark sections as done at 2:00 am and the bot to archive them at 3:00 am before anybody could have seen the changes). I think it So "algo = old(30d) OR marked(done|2d) would be better (where | is not neccessarily the best choice for separator character)
• {{done}} or any similar template also may appear in an inactive position (HTML comment, nowiki, quoting template etc.).

In T72249#4114632, @binbot wrote:

• some delay may be neccessary and should be implemented (we don't want people to mark sections as done at 2:00 am and the bot to archive them at 3:00 am before anybody could have seen the changes). I think it So "algo = old(30d) OR marked(done|2d) would be better (where | is not neccessarily the best choice for separator character)

One way to do that might be "algo = old(30d) OR (old(2d) AND (marked(done) OR marked(not done)))", if a parser is adequately implemented.

Allowing such a flexible syntax might be an overkill for the purpose of archivebot.py, though. It might be sufficient (and easier to implement) to support a more limited one.

The current huwiki system takes {{függőben}} into account on every talk page; I think this system should be kept (by storing a wiki default in the archivebot config).
@binbot The current code takes also “inactive” positions into account. (I don’t know whether it’s good or bad.)

@Tacsipacsi Do you think T191901 addresses that? Allowing to set a wiki-wide default setting sounds like a good idea, but a separate one.

If this task will mean that any local config replaces the defaults (which seems very likely for me), than not: most talk pages have the algo parameter set, which would override this setting. Maybe we shouldn’t store the config, but simply pass it using a command line argument, as the current method for getting the archive config page.

Hello. Was already a path for this task decided? Best regards.

In https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels:

High – Someone is working or planning to work on this task soon.

I don’t think this is the case here.

Does Pywikibot team have to follow this? We usually prioritize tasks by triaging them by priority. We could have High, Medium, Low and Lowest columns on Pywikibot dashboard I suppose, but this is much easier.

This document has “Phabricator” in its title, and no other product name. It seems pretty obvious for me that it therefore applies to all projects tracked on Phabricator. Pywikibot can ignore it of course, but don’t be surprised if people still follow its instructions even for Pywikibot tasks.