Configure Add Update Label Weekly for this repo

[ale210]

Configures the workflow installed by #184 for this repo. Part of #155.

#184 merged with the shipped example config still in place, so the values below were never adapted. Nothing has run yet, and this lands ahead of the first run — the next trigger is Wednesday 2026-09-09 at 22:00 UTC.

Changes

All in github-actions/workflow-configs/add-update-label-weekly-config.yml:

Change	Why
questionsStatus "Questions / In Review" → "Questions/Review"	The shipped default is not a column on our board. Board 73's option is Questions/Review, no spaces around the slash. This value is substituted into the reminder comment, so the old value would have told people to move their issue to a column that does not exist.
Added projectBoard.projectNumber: 73	Pins the board the status is read from. Without it the workflow reads whichever project item GitHub returns first, so an issue on more than one board can be skipped despite being in the target column. Supported as of automate-the-org v1.3.0.
Dropped "er" from labels.filtering	No such label in this repo, so it only produces a startup warning. draft, epic and dependency all exist and are kept.
Removed the # <-- confirm ... markers	The config file's own instruction: delete the comment to signal the value was reviewed.

And in .github/workflows/add-update-label-weekly.yml:

Change	Why
Cron '0 7 * 1-6,8-11 5' → '0 22 * 1-6,8-11 3'	Requested: Wednesdays at 3:00 PM Pacific, instead of the shipped Fridays 07:00 UTC. The July/December exclusion is unchanged.

On the Pacific time conversion. GitHub cron is always UTC and does not observe DST, so a fixed expression cannot be 3:00 PM Pacific year-round. 22:00 UTC is 3:00 PM PDT now and becomes 2:00 PM PST when daylight saving ends on 1 Nov 2026, returning to 3:00 PM on 8 Mar 2027. Given the July/December exclusion, that affects November only. If 3:00 PM PST matters more than 3:00 PM PDT, change it to '0 23 * 1-6,8-11 3' and the drift inverts. Noted in a comment in the workflow file.

The four required label names needed no change — they were normalised repo-side on 2026-09-05 to match. Timeframes are left at the defaults (3 / 7 / 14 / 21 / 35 days).

Verified before opening

• Config parses as YAML; projectNumber reads back as an int, not a string.
• All four required labels exist with exact casing — status: updated, status: to update!, status: 2 weeks inactive, status: help wanted. A mismatch here aborts the entire run, so this is the check that matters most.
• All three filtering labels exist.
• In progress (actively working) and Questions/Review are both literal option names on board 73.
• No <-- confirm markers left in the file.

Expected result of the first run

Computed from live data at the time of writing. Exactly two issues qualify — open, assigned, on board 73, status In progress (actively working), carrying no filtering label:

• Update reminder automation #155 — Update reminder automation
• Org/Devops Lead: Review all the AWS accounts that Bonnie has passwords for (in 1Pass) and determine next steps #158 — Org/Devops Lead: Review all the AWS accounts that Bonnie has passwords for (in 1Pass) and determine next steps

Anything outside that set turning up in the run log means the config is wrong. Worth recomputing just before the run, since it drifts as people comment.

After this merges

Run the workflow manually once from the Actions tab with dry-run left checked, and confirm the log:

• says Loaded configuration from: github-actions/workflow-configs/add-update-label-weekly-config.yml — not Configuration file not found ... using defaults only, which is the failure most easily mistaken for success
• reports no missing required labels
• lists the two issues above and no others
• prefixes every write with Would

Only then let the Wednesday cron take it live.