PR #1157 review surfaced that the drift-check job was failing on
outsider PRs that touched README.md for unrelated reasons (citation
tweaks, link fixes). The path filter caught any README edit even when
the recent-updates block wasn't touched, and the failure couldn't be
fixed by the PR author since they didn't have push access to commit
a regen.
Real-world reasoning: release notes can only legitimately go stale
when a release event occurs. PRs cannot introduce drift the workflow
needs to "catch" — and a drift-check that an outsider can't fix is
hostile to contributions.
Changes:
- Drop the `pull_request` trigger entirely (was only there to feed the
now-removed drift-check job).
- Drop the daily `schedule` cron. UI edits to release bodies are
caught by the `release.edited` event already; falling back to a
cron added mystery commits unattached to a release.
- Drop the `drift-check` job. Nothing left needs to gate on PRs.
- Keep `release.{published,edited,unpublished,deleted}` as the
canonical trigger, and `workflow_dispatch` as the manual hatch.
- Updated /contributing/docs page to match, with an explicit
paragraph on why PRs are NOT a trigger here.
Shutong Wu
7c553f195e