Rewrite goals ping job

[nxsaken]

Run the job every week, allow goals to be on custom reporting schedules (weekly, biweekly, 4-weekly deadlines), DM owners with an aggregate of all their goals that need updates (instead of sending to goal topics), and report any errors to a dedicated topic.

Solves part of #2454

Examples

Direct message

Hi @Ferris Rustoevsky!

This is your reminder to post updates for the following goals:

• Improve everything ever (goals#123)

  • latest update: 2026-07-28, 17:34
  • next weekly cycle starts 2026-08-06, 14:00

• Allow safely thinking about unsafe code (goals#231)

  • latest update: 2026-07-27, 12:25
  • next biweekly cycle starts 2026-08-13, 14:00

• Save turbofish from extinction (goals#312)

  • goal started: 2026-06-01, 21:12 (no updates so far)
  • next 4-week cycle starts 2026-08-27, 14:00

Some questions to guide you (you don't have to follow this):

• What has happened since your last update?
• Are there any relevant PRs, issues, docs, or discussions to link?
• Are you blocked on any issue, PR, or team?
• Do you need help or feedback? Where should people look?
• What do you plan to work on before the next update?

Even if there's little to say, a brief message provides reassurance that the goal is still alive.

Please leave your updates as comments on the tracking issues. Thanks! <3

---

Note: Two- and four-week goals are pinged weekly until an update is posted for the current reporting period.

By default, the reporting period is 4 weeks. If you'd like to post updates more often, you can override the period per goal by labeling the issue with R-every-week, R-every-2-weeks, or R-every-4-weeks.

Report (topic)

Hi @T-goals!

Weekly run finished.

2 owners were notified about 3 goals:

• Weekly reports: 1 (next cycle: 2026-08-06, 14:00)
• Biweekly reports: 1 (next cycle: 2026-08-13, 14:00)
• Four-week reports: 1 (next cycle: 2026-08-27, 14:00)

5 errors happened in the process.

---

The following goals have no owner assigned:

• Unify the target specification (goals#501)

Please assign an owner and reach out to them!

---

The following goals have more than one owner assigned:

• goals#502: @Bob and @NotBob

A goal should have exactly one owner. All owners with a Zulip account were still notified separately.

---

The following goal owners were not pinged because they don't have a Zulip account specified in the team repo:

• goals#503: @_Bob
  • @_NotBob got notified on Zulip.

Please make sure to register their zulip-id and reach out to them!

---

The following assignees could not be found in the team repo, so Triagebot could not look up their Zulip accounts:

• goals#504: @unknown-user
  • Nobody was notified on Zulip.

Please check the assignee usernames and their entries in the team repo.

---

The following goals have conflicting reporting period labels:

• goals#505: R-every-week, R-every-4-weeks (R-every-week was used)

Unlabeled goals use the default period of 4 weeks.

Until next week! <3

Goal accepted

Goal Allow safely thinking about unsafe code (goals#231) has been accepted. It's owned by @Ferris Rustoevsky.

[nxsaken]

Actually, there's probably a more intuitive way to deal with scheduling. I'll try that tomorrow

[Kobzol]

I like using labels to set the notification frequency 👍 That's a good idea.

[nxsaken]

I removed the binary and zulip command because it doesn't make sense to run them outside of the job cadence (at least for now).

[nxsaken]

Found out that the current pings are being triggered by @tomassedovic's scheduled messages invoking the zulip command.

[Urgau]

Drive-by: there seems to be a mix of logic, messages, utils in this file. would it be possible to separate such "area" in submodules? I'm thinking of project_goals/messages.rs and project_goals/utils.rs (with Period and maybe Schedule).

Period and Schedule also seems like good candidate for unit-tests.

View changes since the review

[Kobzol]

This is a bit.. involved :) But I guess it's better to see errors on Zulip than have to go through triagebot logs. Left some comments, but in general it makes sense to me.

Regarding the split, I don't mind keeping everything in one file for now, at least it is easier to access and search stuff. But if we do split it, I would split it by functionality, so essentially the code for the job vs code for handle would be separately, plus maybe a separate file for the shared data structures or fnctions.

View changes since this review

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Kobzol]

Thanks! Let's try this. Well, next week :)

View changes since this review