I smell a Task Reaper (cc @btrahan).

Haha, yeah, I thought of that too. In short, it was this little robot at Facebook built by @jeg that would ping tasks - "you haven't touched this in X. do something or we reap it at Y" - and then reap 'em. (@jeg - feel free to embellish...! =D )

See also T402, which I'm just going to close and point here since it's ancient.

Generally, T5207 is an accurate technical blocker. There are various time-based things we'd like to do in the future (warn you before a meeting in Calendar, bill a subscription in Phortune) that we'll need time-aware, cron-like infrastructure for. This will also potentially enable age-based Herald rules and periodic Harbormaster builds (and whatever else we come up with).

Philosophically, I'm not really convinced that nagging users is very effective or that making tasks automatically expire if left unattended for some time is a desirable behavior, but there are plenty of unambiguous uses that don't stray into this grey area (e.g., escalate high-priority issues if left untouched for an hour), and @qgil's examples are generally reasonable and less severe than the task reaper was. I'd generally want to at least structure this with those sorts of use cases in mind and only incidentally enable the nag/reaper cases, though.

T436 was another related task which rolled into T402, but roughly was a request for the ability to set reminders. I haven't seen other requests for that since then, but Calendar + time infrastructure should give us reminders for free/cheap.

I guess this request is more relevant for the open source community case than for the corporate intranet case:

• More people might come and go for short periods of time and leave unfinished / unattended work still assigned to them.
• Even when they leave, they might come back, so you don't want to be too harsh either.
• Cleaning manually is boring, and frequently people take things personally so you might get in extra trouble just for cleaning.
• However, bots don't get bored, they have time, and as long as they follow community agreed processes, nobody attempts to pick a fight with them.

Not urgent at all. Looking forward to Chronicle.

Interesting update (even if [perhaps not good news for this task):

In D11419#107322, @epriestley wrote:

One other possible weakness is that this doesn't give us any direct tools to attack the "task reaper" use case, but I'm not really sold on the usefulness of it in the general case and I'm not sure if, e.g., Herald rules with timer conditions are the right approach anyway, since I think they're not expressive enough.

In particular, with special cases like T6821/T6491 (where the desire is to trigger, e.g., after no change in assignee status, specifically, for X days), I'm hard-pressed to imagine us ever building a system which can express those rules in a generic way. Pager escalation rules ("text everyone if no one touches this for 15 minutes") seem somewhat more practical, but just building that into a pager/monitoring tool probably makes more sense than doing it via Herald or some Chrono-Herald.

If T4434 ends up somewhat-generic-ish, the "Task Reaper" becomes easy to write as an external script, although it will have to be pretty generic to satisfy all the use cases in T6491.

Not sure if related to this task or not, but I'd love the ability to have Herald rules act on countdowns. Sometimes we have tasks that fan out to many teams and we'd like the ability to assign it to the team, but add a project or change assignee once a countdown expires.

Another example use case: the ability to perform advanced searches based on report history criteria and to send "whines" (as on bugzilla) is needed for any project that wishes to join https://bestpractices.coreinfrastructure.org/ , namely the criteria:

The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
The project SHOULD respond to most enhancement requests in the last 2-12 months (inclusive). The project MAY choose not to respond.

Because these are common needs for software projects (even a "mandatory" best practice), it would be inappropriate to address them with a custom solution.

I don't see how Herald rules are related to the provided "example use case" (maybe because it's unclear to me what "MUST acknowledge" actually means). Maniphest's advanced search already allows to combine "Created Before" and "Updated After" to address that "common need" - no Herald needed.

I don't see how Herald rules are related to the provided "example use case"

I'm sorry you have such a vision problem; luckily, the https://bestpractices.coreinfrastructure.org/ people acknowledged the issue with our issue tracker.

@nemobis, I previously warned you about the tone of your interactions with the upstream in T5908#84888.

Acting in a way that demeans and personally attacks others is not acceptable here.

This is your final warning.

With D11419 implemented, is it possible to now allow Herald rules to be triggered on a cron (even a very simple 'daily' option would be good)?

My use case is sending out reminders to auditors that they have audits waiting for them to review. Some of our users don't use phabricator regularly and they forget to come back and review code they have waiting.

I could implement an external API call and script per T7171 but having this contained and managed inside phabricator would be a lot simpler. As I see it, the parts might be:

1. cron style triggers for herald
2. filter based on age (this task)
3. create events which might then be consumed by another herald trigger

Other people might also want to send out a single reminder email with all the aged objects grouped, but the above ideas might be a first step and would be useful for at least my particular use-case.

Thanks for considering this.

See PHI1107, which requests Auto-Abandon for old changes and also has a technical outline for this great and wholesome feature.